Back to blog
Platform

Internal Audit Findings: How to Make Sure They Actually Get Fixed

One team told us a finding from their internal audit had stayed open for three years. The explanation was three words: "I didn't know." Here's what a finding needs to get closed, what ISO 27001, NIS2, and DORA expect after an audit, and how the new Audit module in Formalize follows every finding through to sign-off.

Maurice Müller

Maurice Müller

Senior Content Manager

Maurice Müller is a journalist and content strategist with experience across print and digital media. At Formalize, he translates complex compliance and regulatory topics into clear, practical content for compliance, risk, and security professionals across Europe.

Key takeaways:

  • In our conversations with compliance teams, internal audits most often stall in follow-up, when nobody clearly owns the fix.

  • A finding gets closed when it's clearly described, has an owner and a target date, and needs independent sign-off before it counts as resolved.

  • The new Audit module in Formalize, available from October 2026, runs internal audits on the controls and evidence you already manage and follows every finding through to sign-off.

Logging a finding takes a few minutes. Getting it fixed can take months, because the real work only starts once the report goes out: someone has to own the fix, work toward a date, and have it checked before the finding counts as closed. ISO 27001, NIS2, and DORA all expect that follow-up to happen, and DORA spells it out. Closing the loop comes down to a few things every finding needs, and none of them depend on a particular tool.

Why findings stay open

When we ask compliance teams how a finding gets fixed today, the answers sound alike. Someone chases the owner by email. Status gets reported by hand before the next meeting. The finding lives in the audit file, and once the report goes out, it drops out of sight.

One question surfaces the gap quickly: when you track findings in a spreadsheet, how do you make sure someone signs off on the fix before it's marked as closed? In most setups, nothing does. Whoever updates the cell decides that the finding is done.

None of this means the audit was done badly. Fieldwork tends to get done, because it has a deadline and a team. Follow-up often has neither.

What a finding needs to get closed

It starts with how the finding is written. "Access reviews need improvement" doesn't tell anyone what went wrong, why, or what's at stake. The IIA Global Internal Audit Standards ask for more: auditors compare what should happen with what actually happens, then work out the cause and effect of the gap. That gives every finding four parts:

Part

Question it answers

Example

Criterion

What should happen?

Access rights to production systems are reviewed every quarter, as the access control policy requires.

Condition

What happens in practice?

Two of the last four quarterly reviews weren't documented.

Cause

Why is there a gap?

The review owner changed roles, and the task wasn't reassigned.

Effect

Why does it matter?

Access for people who changed roles or left may have stayed active longer than the policy allows.

Written this way, a finding already points to its fix. Here the cause is a task with no owner, and that's also where follow-up tends to break.

From there, five checks decide whether the finding gets closed:

  • One named owner: A person who knows the finding is theirs. If they change roles, the finding moves with the responsibility.

  • A target date that matches the severity: A critical finding shouldn't share a deadline with a minor one.

  • A recorded decision: Not every finding gets remediated. Some risks are accepted, and some findings are disputed. Write down which, who decided, and why.

  • Independent sign-off: The person who fixes a finding shouldn't be the one who closes it.

  • Visibility after the audit: The finding stays tied to whatever it affects, from a control to a supplier, so it's still in view after the report is filed.

The IIA Standards make the same point from the auditor's side. Standard 15.2 expects internal auditors to confirm that recommendations or action plans have been implemented.

See how your next audit would run in Formalize

Book a demo, and we'll walk you through the Audit module with the audit you have coming up, from planning to the last signed-off finding.

Why it matters now: ISO 27001, NIS2, and DORA

Most frameworks our customers work with expect internal audits. They differ in how much they say about what comes after.

ISO 27001

ISO/IEC 27001:2022 requires internal audits at planned intervals (clause 9.2). When an audit finds a nonconformity, clause 10.2 asks for corrective action and a check that the action worked.

NIS2

Article 21(2)(f) of the NIS2 Directive requires essential and important entities to have policies and procedures for assessing whether their cybersecurity risk-management measures are effective. An internal audit with documented follow-up is one way to show that. National implementations differ, so check what your authority expects.

DORA

DORA is the most explicit. Article 6(6) requires financial entities, other than microenterprises, to have their ICT risk management framework internally audited on a regular basis. The auditors need the right ICT expertise and appropriate independence. Article 6(7) goes a step further: based on the audit's conclusions, there has to be a formal follow-up process with rules for verifying and remediating critical findings in good time.

How it works in Formalize: one finding, start to finish

Take the access review finding from above and follow it through the new Audit module.

During fieldwork, the Field Auditor assessing your access control raises the finding right there, on the control itself. The criterion, condition, cause, and effect each get their own field, so the finding is complete before anyone else reads it.

The finding gets a severity rating on your own scale and a recorded decision: remediate. An action plan follows directly from it, with a named owner and a target date. Follow-up doesn't have to wait for the audit report. It can start while the audit is still running.

When the owner has reassigned the quarterly review and documented the next one, the fix goes through an approval workflow. The finding only counts as resolved once someone independent signs it off. Until then, it stays on the access control, visible to anyone who looks at that control. It doesn't disappear into a closed audit file, which is exactly how a finding ends up open for three years.

The rest of the audit works the same way. You start by turning your team's existing process into a reusable audit template, with the questions to answer and how findings are handled. From there, an audit can start from a framework, a set of risks, or the assets and suppliers you manage. It follows your usual steps, from planning and scoping through fieldwork and conclusions to follow-up, structured to the IIA Global Internal Audit Standards.

Audit Organizers plan the audit, Lead Auditors own the process and sign off on conclusions, and Field Auditors carry out the assessments, so everyone knows their part. Evidence links to the controls, risks, suppliers, and almost any other record you manage in Formalize, so what you've already documented doesn't have to be collected again. Your own team can run the audit, or an outsourced auditor can run it for you.

The Audit module makes it easy for us to trace the links between audit subjects, requirements, controls, and evidence, all the way to the final audit report.

Erhard Christelbauer, Senior GRC Advisor, Bonafide

The first version is built for internal audits, not certification audits such as ISO 27001 certification or a SOC 2 attestation. Requesting evidence from colleagues inside the module is next on our roadmap.

From October 2026, the Audit module is included in the Standard Infrastructure and Advanced Infrastructure plans. On other plans, it's available as an add-on.

Frequently asked questions

Book a demo