NIS2 Non-Conformance Report: 7 Fields That Close an Audit Finding — Including the One That Lets You Accept the Risk Instead of Fixing It

Search the full text of the NIS2 Directive and its implementing regulation for the words “non-conformance” or “non-conformity” and you get nothing. Zero hits in either instrument. “Deviation” is also zero. “Corrective” appears once in the Directive and twice in the Implementing Regulation. The document a large part of the compliance market sells you has no legal name in the law it claims to serve[1][3].

It does have a legal job, and one sentence defines it. Point 2.3.3 of the Annex to Commission Implementing Regulation (EU) 2024/2690 says that once an independent review reports its results to the management bodies, “Corrective actions shall be taken or residual risk accepted according to the relevant entities’ risk acceptance criteria”[1].

Fix it, or accept it — on the record, against criteria written in advance, with your management body’s name against the acceptance. Every field a NIS2 finding record needs follows from that sentence. Below are the seven fields that discharge it, what changes versus the manufacturing-style report most templates copy, and what an open finding looks like from the supervisor’s side of the table.

The Report Has No Legal Name, But It Has a Legal Job

In plain terms: nothing in NIS2 obliges you to produce a document called a non-conformance report. What obliges you is the chain around it — you must review independently, report the results upward, and end each result in one of exactly two ways. The report is simply the artefact that proves you did.

The vocabulary is borrowed from quality management, and it is borrowed slightly wrong. ISO defines an audit finding as the “results of the evaluation of the collected audit evidence against audit criteria”, and adds a note that matters here: “In English, if the audit criteria are selected from statutory requirements or regulatory requirements, the audit finding can be called compliance or non-compliance”[9]. On a NIS2 review your criteria are regulatory. Strictly, you are recording compliance findings; “non-conformance report” is the container the quality world lends you. ENISA uses the same wording, describing the detailed section of a review report as covering “gaps identified and non-compliance issues”[2].

Whether point 2.3.3 binds you directly depends on what kind of entity you are.

Your entity	Does the Implementing Regulation bind you?	What the finding record has to satisfy
DNS providers, TLD name registries, cloud computing, data centre and CDN providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, trust service providers	Yes — the Annex is binding law for these categories	Annex point 2.3.3 directly, plus 2.1.1 and 2.1.2 on how risk is accepted
Any other essential or important entity	No — but Article 21 applies to you directly, and the Annex is the closest available benchmark your auditor will reach for	Article 21(4), which requires corrective measures from any entity that finds it does not comply with the Article 21(2) measures
German KRITIS operator	Also subject to the evidence duty under § 39 BSIG	The BSI’s own Mängelliste columns, submitted to the BSI as an annex to the evidence forms[6]

The review that produces these findings is not optional and not occasional. Point 2.3.4 requires independent reviews “at planned intervals and when significant incidents or significant changes to operations or risks occur”[1] — the same trigger pair that point 2.2.3 attaches to compliance monitoring[1]. If you have not yet set those intervals, start with the annual review cadence the CIR fixes and the ones it leaves to you, because a finding record with no scheduled review behind it is an orphan.

Who Is Allowed to Write the Finding — and Who Is Not

Point 2.3.2 sets a structural constraint most template packs never mention. Independent reviews must be “carried out by individuals with appropriate audit competence”, and where the reviewer is one of your own staff, “the persons conducting the reviews shall not be in the line of authority of the personnel of the area under review”[1].

That single clause rules out the most common arrangement in small security teams: the CISO who implemented the control also signing off that it works. It is visible from an org chart, which makes it one of the cheapest things for a supervisor to check.

The regulation then does something unusual — it gives smaller entities an explicit way out rather than a waiver. “If the size of the relevant entities does not allow such separation of line of authority, the relevant entities shall put in place alternative measures to guarantee the impartiality of the reviews”[1]. ENISA suggests three, and calls the list non-exhaustive: rotating review personnel, a review committee drawn from different departments, or an external third-party reviewer[2]. The obligation that survives is impartiality, not headcount — but you have to write down which alternative you chose and why.

Role	Owns	Must not own
Reviewer / internal auditor	The finding, its evidence, its severity, and the verdict on whether the proposed fix is adequate	The remediation plan itself
Control or area owner	The corrective action, the named owner, the completion date	The severity rating of a finding against their own area
Management body	Receiving the report, and approving any residual risk that is accepted rather than fixed	Delegating the acceptance decision without a documented reporting line back to it

The Seven Fields a NIS2 Finding Record Has to Carry

Each field below exists because a specific provision needs it to exist. Fields one to four are the reviewer’s; five and six belong to the business; seven closes the loop.

#	Field	What it must contain	Why
1	Finding ID	A unique reference that survives across audits. Findings still open from a previous review are carried forward, not renumbered	Traceability; the BSI requires carry-forward with an “ALT-[year]-” prefix, and findings from other audits in scope with prefixes such as “ISO27001-2021-1″[6]
2	The requirement not met	The exact Annex point or Article 21(2) limb — not the section heading. Where a point contains several duties, quote the specific one	A nonconformity is “non-fulfillment of a requirement”; “if the auditor cannot identify a requirement, then the auditor cannot raise a nonconformity”[8]
3	The evidence actually seen	Detailed enough for the audited team to find and confirm exactly what the reviewer observed — system, sample, date, configuration	“If there is no audit evidence — there is no nonconformity”[8]. Supervisors can request audit results “and the respective underlying evidence” under Article 32(2)(g)[3]
4	The finding statement and its severity	A self-explanatory, system-level statement that is not a restatement of the evidence, plus a severity from a fixed scale	The statement “drives the cause analysis, correction and corrective action”[8]; the CIR requires “assessment of criticality and mitigating actions for each finding” for security tests[1]
5	The disposition	Corrective action, or accepted residual risk. Nothing else	Annex 2.3.3 permits exactly two endings[1]
6	Owner and completion date	A named role and a real date — if you work in quarters, use the last day of the quarter	The CIR requires you to “identify who is responsible for implementing the risk treatment measures and when they should be implemented”[1]; the BSI form takes a role in one column and a DD.MM.YYYY date in the next[6]
7	Closure test	Evidence that the action worked, not that it happened — and the reviewer’s verdict on it	Point 7 requires policies to assess whether measures are “effectively implemented and maintained”[1]; the ISO form separates verification of implementation from verification of effectiveness[8]

Three of these fail most often. Field two fails when the record cites “Annex section 6” instead of the sub-point — the ISO guidance is blunt that clauses containing several requirements must be narrowed to the one actually breached[8]. Field three fails when evidence is summarised rather than recorded; the test is whether the team can walk back to the same screen. And field four fails when a real finding is softened into an “observation” or an “opportunity for improvement” — a habit ISO’s own auditing guidance warns against, because softer labels get “a lower priority for corrective action”[8]. If you want a worked example of what a finding statement looks like at the control level, our ISO 27001 internal audit checklist covers the tests that surface them.

Corrective Action or Accepted Residual Risk: The Fork Nobody Documents

This is the field that separates a NIS2 finding record from a quality one, and it is the reason a finding can legitimately be left unfixed.

Accepting the risk is a real, permitted ending. ENISA states it plainly in its guidance on 2.3.3: “Take corrective actions or justify, accept and document residual risks”[2]. But the acceptance branch carries four conditions, and skipping any of them turns a defensible decision into an undocumented gap:

• Criteria written in advance. Point 2.3.3 measures acceptance “according to the relevant entities’ risk acceptance criteria”, and point 2.1.2(c) obliges you to “establish and maintain relevant risk criteria”[1]. Criteria invented after the finding are not criteria.
• Reasons on the record. Point 2.1.2(j) requires you to document the chosen risk treatment measures and “the reasons justifying the acceptance of residual risks in a comprehensible manner”[1].
• The right signature. Under point 2.1.1, residual risks “shall be accepted by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks, provided that the relevant entities ensure adequate reporting to the management bodies”[1]. ENISA lists “approval of the residual risks by management bodies” among its examples of evidence for this point[2].
• It goes into the risk register. ENISA is explicit that review outcomes “should be systematically reflected in the risk assessment results and risk treatment plans”, and that where a review identifies or reassesses a risk, “the corresponding risk assessment should be updated accordingly”[2].

The branch also closes in places, and the most important closure sits in the Directive itself rather than the Implementing Regulation. Article 21(4) requires that “an entity that finds that it does not comply with the measures provided for in paragraph 2 takes, without undue delay, all necessary, appropriate and proportionate corrective measures”[3]. That duty binds every essential and important entity, it is triggered by the entity’s own discovery, and it contains no acceptance branch. Where a finding is that an Article 21(2) measure is not in place, the flexibility lives in what is “appropriate and proportionate” — not in a right to leave it unaddressed. Point 2.3.3’s fork governs how review results are dispositioned; it does not switch off Article 21(4). For security testing, point 6.5.2(d) is similarly closed: entities must “apply mitigating actions in case of critical findings”[1]. Germany’s supervisor draws the same line in its own severity definitions: a serious deviation means “akuter Handlungsbedarf” with immediate remediation, while a minor one must in principle be fixed promptly, and a medium-term timetable suffices only where appropriate risk treatment allows it[6]. Severity is not a label; it decides whether the fork is open at all.

One more distinction, and it is the one auditors probe hardest. ISO separates correction — “action to eliminate a detected nonconformity” — from corrective action, which is “action to eliminate the cause of a nonconformity and to prevent recurrence”[9]. Re-enabling MFA on the four accounts the reviewer found is a correction. Finding out why the joiner process never enrolled them is the corrective action — a distinction we work through in full in our guide to CAPA under the CIR Annex, which counts how often each term actually appears. A record that shows only the first will produce the same finding next year — and when a supervisor comes to take an enforcement measure under Article 32(4) or (5), it must “take due account of” “any relevant previous infringements by the entity concerned” under Article 32(7)(c)[3].

What Changes When the Auditee Is a NIS2 Entity, Not a Factory

The generic non-conformance report most template libraries hand you is built for ISO 9001 manufacturing and organises around six blocks. Four of them survive contact with NIS2 unchanged. Two change meaning entirely, and one is missing.

Generic NCR block	What it becomes under NIS2
Identification, description, verification	Unchanged — fields 1, 3, 4 and 7 above
Reference (spec, drawing, standard)	The Annex point or Article 21(2) limb, narrowed to the specific duty[8]
Containment (“stop the bad parts shipping”)	The compensating control, stated inside the risk line. The BSI’s own worked example assesses a privileged-access deficiency net of an isolated admin network and SIEM detection — the residual risk, not the raw one[6]
Disposition (accept, repair, rework, scrap)	A risk decision, not a concession: corrective action or documented residual-risk acceptance, signed at management-body level[1][2]
— no equivalent —	Reporting to the management body. Point 2.3.3 makes the report itself an obligation, and ENISA expects it at least annually in a standard format: executive summary and scope, methodology, detailed findings, recommendations, conclusions[1][2]

Germany publishes the most fully specified regulator-issued version of this form we have found in the EU, and it is worth copying even outside German scope. The BSI’s Mängelliste splits into three ownership zones: the auditor records the finding, its topic, its severity, the affected asset and the risk; the operator then writes the measures, the responsible role, the target date and a completion percentage; the auditor returns to give a binary verdict on whether the measures are suitable, with written reasoning required only when they are not[6]. The blank template itself is published, free, on the BSI’s KRITIS download page[7]. Two details are worth stealing outright. Findings fixed during the audit still go on the list, with the fix recorded in the plan — the record is of what was found, not what remained. And a measure that closed a deficiency has to be shown at 100% at least once during monitoring, which makes closure an event rather than a quiet edit.

What an Open Finding Looks Like From the Regulator’s Side

The point of the record is that it survives someone else reading it. Article 32 gives supervisors of essential entities a graduated set of powers, and unresolved findings interact with almost all of them.

Provision	What it lets a supervisor do	What your record has to withstand
Article 32(2)(g)	Request “evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence”	The power reaches past the report to what the auditor looked at — field three, not field four
Article 32(2)(b) and its subparagraph	Order a targeted security audit by an independent body; “the costs of such targeted security audit … shall be paid by the audited entity, except in duly substantiated cases when the competent authority decides otherwise”	The first financial consequence of being examined unprepared is an invoice, with no fine involved
Article 32(4)(b) and (f)	Adopt binding instructions with “time-limits for the implementation of such measures and for reporting on their implementation”, or order you to implement audit recommendations “within a reasonable deadline”	Once this happens, the deadline is the supervisor’s, not yours
Article 32(7)(a)(iii) and (iv)	Treat “a failure to remedy deficiencies following binding instructions” and “the obstruction of audits or monitoring activities” as serious infringements in any event	The escalation is about the unremedied finding, not the original weakness
Article 32(8)	Must give detailed reasoning, notify “preliminary findings” before adopting measures, and allow “a reasonable time … to submit observations”	That window — before the measure, not after — is where a factual correction to a finding belongs

Important entities sit under Article 33, which is narrower in one respect worth knowing: 33(2)(b) provides for “targeted security audits carried out by an independent body” without the “regular” audits available against essential entities under 32(2)(b). But Article 33(5) applies 32(6), (7) and (8) “mutatis mutandis”, so the serious-infringement list and the observation window apply to important entities too[3].

What none of this supports is a fine estimate. As of this writing, no EU competent authority has published a NIS2 penalty decision that can be verified against an official source, so treat the fine as an unknown bounded by Article 34 rather than a number in a business case — our guide to NIS2 penalties and the factors that reduce exposure works through what is and is not evidenced. The consequences that are evidenced sit in the table above: an ordered audit you pay for, a remediation timetable you did not set, and a first infringement that prices the second.

Frequently Asked Questions

Does NIS2 require a non-conformance report? Not by that name, and not as a named document. It requires independent reviews, results reported to the management bodies, and each result ending in corrective action or accepted residual risk (Annex 2.3.3)[1]. A finding record is how you evidence that; the format is yours.

Can we accept a finding instead of fixing it? Yes, and this is the most misunderstood point in the whole chain. Acceptance is a permitted ending, provided it is measured against pre-existing risk acceptance criteria, justified “in a comprehensible manner”, accepted by the management body or an accountable delegate who reports to it, and reflected in the risk assessment and treatment plan[1][2]. Two documented exceptions close the branch: point 6.5.2(d) requires mitigating action for critical security-test findings[1], and Article 21(4) requires corrective measures “without undue delay” from any entity that finds it does not comply with an Article 21(2) measure[3].

Who signs the record? The reviewer signs the finding, and on the German model returns to sign a verdict on whether the proposed measures are adequate[6]. The control owner signs the action and the date. The management body signs any residual risk that is accepted rather than fixed — that signature is one of ENISA’s own evidence examples[2].

How long do we keep them? Neither the Directive nor the Implementing Regulation sets a retention period. What the CIR does require, at point 1.1.1(h), is that your own security policy “list the documentation to be kept and the duration of retention of the documentation”[1]. The auditable failure is having no stated period, not having a short one.

Is an internal audit finding a reportable incident? No. Article 6(6) defines an incident as “an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems”[3]. A missing or weak control is not, by itself, such an event, and the Article 23 notification clocks are not triggered by finding one. If the review uncovers evidence that something already happened, that is a separate assessment under Article 23.

Key Takeaways

• “Non-conformance”, “non-conformity” and “deviation” appear zero times across NIS2 and Implementing Regulation 2024/2690. The duties live in Annex point 2.3.3 and Article 21(4)[1][3].
• Where audit criteria are regulatory, ISO’s own vocabulary calls the result a compliance or non-compliance finding — the QMS label is borrowed[9].
• Seven fields discharge the duty: ID, requirement, evidence, statement and severity, disposition, owner and date, closure test.
• Point 2.3.3 permits two endings for a review result, and accepted residual risk needs pre-written criteria, documented reasons, a management-body signature and a risk-register update[1][2].
• The acceptance branch is not universal. Article 21(4) requires corrective measures without undue delay from any entity that finds it does not comply with an Article 21(2) measure, and has no acceptance option[3].
• Correction fixes the instance; corrective action removes the cause. Only the second stops the finding recurring, and previous infringements are among the circumstances a supervisor must “take due account of” under Article 32(7)(c)[3].
• Supervisory powers reach past the report to the underlying evidence, and the pre-measure observation window under Article 32(8) is where a disputed finding gets corrected[3].

A finding record is not paperwork about a weakness. It is the document that proves the weakness was seen, priced, decided on by someone with the authority to decide, and either closed or knowingly carried. If you want to know how many of these your programme is about to generate before you build the process, an ISO 27001 gap analysis with 0–5 maturity scoring gives you the count in advance.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — Annex points 1.1.1(h), 2.1.1, 2.1.2, 2.3.1–2.3.4, 6.5.2 and 7: official text on EUR-Lex.
2. ENISA, Technical Implementation Guidance on cybersecurity risk management measures, version 1.0, June 2025 (PDF). Non-binding guidance; the document states this itself.
3. Directive (EU) 2022/2555 (NIS2) — Articles 6(6), 21(4), 32 and 33: official text on EUR-Lex. Every passage quoted above was checked word for word against the consolidated text served by the EU Publications Office.
4. Directive (EU) 2022/2555, Article 32 — Supervisory and enforcement measures in relation to essential entities (article-level reproduction used to verify the wording quoted above).
5. Directive (EU) 2022/2555, Article 32 (second independent reproduction used to cross-check the same wording).
6. Bundesamt für Sicherheit in der Informationstechnik, Anleitung zur Mängel-Dokumentation in der Mängelliste, version 2.1, 5 December 2025 (PDF, German).
7. BSI, KRITIS-Downloads — Downloads und Links für Betreiber und Prüfende, the page hosting the Muster-Mängelliste template.
8. ISO and IAF, ISO 9001 Auditing Practices Group, Guidance on: Nonconformity — Documenting, 13 January 2016 (PDF). The paper carries its own note that it has not been through an ISO, ISO/TC 176 or IAF endorsement process.
9. ISO/TC 176/SC 1, Terms in TC 176 Standards — Alphabetical Listing, V1, 29 September 2022 (PDF), for the ISO 9000:2015 definitions of audit finding, correction and corrective action.