CAPA for NIS2: The CIR Annex Names Corrective Action Twice and Preventive Action Never

CAPA is not a NIS2 concept. Count the binding text and the numbers are blunt: the Annex to Commission Implementing Regulation (EU) 2024/2690 uses the phrase “corrective action” in exactly two of its requirements, and the phrase “preventive action” in none of them[1][2]. ENISA’s 170-page implementation guidance never uses “preventive action” either. Ireland’s national competent authority published 65 pages of draft risk-management guidance in which the word “corrective” does not appear once[3].

That is not a hole in the law. Audit findings are routed somewhere the corrective-and-preventive-action habit does not look: into the risk treatment plan, into the post-incident review, and into a quarterly test most compliance teams have never run. Get the routing wrong and you can close every finding on schedule and still be non-compliant with the clause that actually governs closure.

Does This Apply to You?

If anything in your organisation produces a written security finding, this applies. Two layers decide how strictly.

Your entity	What binds you	What the CIR Annex is to you
DNS providers, TLD registries, cloud and data centre providers, CDNs, managed service and managed security providers, online marketplaces, search engines, social platforms, trust service providers	Article 21(2)(f) of Directive (EU) 2022/2555[4] and the CIR Annex, as directly applicable EU law[13]	Binding. The points quoted below are obligations.
Every other essential or important entity: energy, health, transport, water, manufacturing, public administration, and the rest	Article 21(2)(f) plus your member state’s transposing law	Not binding on you, but it is the Commission’s own reading of Article 21(2), and the closest thing to a published benchmark your auditor has.

The trigger is a finding, not a job title. Findings arrive from an internal audit programme, an independent review, a penetration test, a vulnerability scan, a failed backup restore, a post-incident review, or a regulator’s inspection. Each has its own closure rule, and they are not identical.

CAPA Is a Quality-Management Import, and NIS2 Never Asks for One

CAPA comes from quality management, where it is well defined: a collective process “to correct the immediate problem, to determine the cause or causes of the problem, and to develop and implement a plan to prevent the problem from recurring”[5]. Teams arriving at NIS2 from ISO 9001, GMP, or an FDA-regulated environment bring that vocabulary with them. It is just not the vocabulary the regulation uses.

Even the standards CAPA came from have moved on. The ISO 9001 Auditing Practices Group, a joint body of ISO/TC 176 and the IAF, records the change plainly: “Previous editions of ISO 9001 included a clause on preventive action, which aimed to prevent the occurrence of nonconformities”[6]. It was retired as a standalone clause and folded into risk-based thinking, because a separate preventive-action register tended to become an administrative exercise rather than a driver of change.

NIS2 landed on the far side of that shift. Counted across ENISA’s verbatim reproduction of the CIR Annex, “corrective action” appears twelve times in the document but only twice inside a binding requirement, at points 2.3.3 and 4.2.6[2]. The other ten sit in ENISA’s non-binding guidance and evidence examples. “Preventive action” and “nonconformity” appear zero times. Ireland’s NCSC frames the same duty without the word at all, requiring that “the risk treatments implemented must be regularly reviewed to ensure they are providing the expected mitigations”, and that where they fail to deliver, “the risk treatments must be adjusted”[3].

That makes this a build decision. A parallel CAPA register, maintained alongside the risk register and reconciled to nothing, creates a second source of truth an auditor will find and compare. What the regulation asks for is narrower: a documented decision on every finding, taken against your own risk acceptance criteria, visible to the people who carry the liability.

Point 2.3.3 Is a Binary, and the Board Is Told Either Way

One clause carries the weight, and it is not in Section 7 where most people look. It sits in Section 2, under risk management policy. Annex point 2.3.3 reads: “The results of the independent reviews, including the results from the compliance monitoring pursuant to point 2.2. and the monitoring and measurement pursuant to point 7, shall be reported to the management bodies. Corrective actions shall be taken or residual risk accepted according to the relevant entities’ risk acceptance criteria.”[2]

Three things follow. First, closure is a binary with two legitimate outcomes: fix it, or accept the residual risk. An accepted risk is a compliant outcome, not a failure, provided the acceptance is measured against criteria you wrote down in advance. The non-compliant third option is the finding that quietly ages without either decision being recorded. Second, the reporting is not discretionary: results go to the management bodies, which under Article 20(1) “approve the cybersecurity risk-management measures”, “oversee its implementation” and “can be held liable for infringements”[7]. A risk acceptance that never reached the board is an acceptance nobody with the authority to make it actually made. Third, the clause pulls Section 7 into Section 2 by cross-reference, which is why the effectiveness assessment you run under Article 21(2)(f) has no closure rule of its own.

Different finding sources close differently. This is the map:

Where the finding came from	Governing binding point	What closure requires
Independent review, compliance monitoring, effectiveness assessment	Annex 2.3.3	Corrective action or residual-risk acceptance against your criteria, reported to the management bodies
Security test or penetration test	Annex 6.5.2(c) and (d)	Criticality assessment and mitigating actions documented for every finding; mitigating actions applied for critical findings
Vulnerability scan or vendor advisory	Annex 6.10.3	A mitigation plan where the potential impact justifies it; otherwise a documented and substantiated reason why no remediation is needed
Backup and recovery test	Annex 4.2.6	Test results documented and, where needed, corrective action taken
Post-incident review (required “where appropriate”)	Annex 3.6.1 and 3.6.2	Root cause where possible, documented lessons learned, and a demonstrable feed into risk treatment and incident procedures
Regulator’s own audit	Article 32(4)(f) or 33(4)(f)	Implement the recommendations within the deadline the authority sets

The pattern across all six: the regulation never asks for a ticket, it asks for a decision plus its justification. The security-test rule at 6.5.2 is the strictest, because it demands a criticality judgement on every finding, not only the ones you plan to fix.

Where the “Preventive” Half Lives: the Risk Treatment Plan

Prevention is in the regulation. It is simply not stored in a preventive-action column. It runs down three channels.

The risk treatment plan. Annex point 2.1.3 requires that when identifying and prioritising risk treatment options, entities “take into account the risk assessment results, the results of the procedure to assess the effectiveness of cybersecurity risk-management measures, the cost of implementation in relation to the expected benefit, the asset classification… and the business impact analysis”[2]. Effectiveness findings are a named input to treatment prioritisation. If your findings sit in a register that never reaches the risk treatment plan, you have broken the one link the Annex draws explicitly.

The post-incident review. Point 3.6.1 requires entities to carry out post-incident reviews “where appropriate”, and those reviews must identify root cause where possible and produce documented lessons learned; 3.6.2 then requires them to “contribute to improving” the security approach, risk treatment measures, and incident procedures[2]. The trigger is hedged, but once a review happens its output is not: prevention here is an output obligation, not a filing obligation.

The quarterly recurring-incident test. This is the one that surprises people. Annex point 3.4.2(b) requires entities to “assess the existence of recurring incidents as referred to in Article 4 of this Regulation on a quarterly basis”[2]. Article 4 then converts a pattern into a reportable event: incidents that are individually insignificant “shall be considered collectively as one significant incident” where they have occurred at least twice within six months, have the same apparent root cause, and collectively meet the Article 3(1)(a) financial threshold, which is direct financial loss exceeding EUR 500 000 or 5 % of annual turnover, whichever is lower[8][9].

Read together, the mechanism is sharp. A corrective action that treats a symptom rather than the root cause does not merely leave a risk open. It lets the same root cause fire again, and on the second occurrence within six months you are no longer managing an internal finding, you are assessing whether a notification obligation has been created. Failed remediation is the input to that test.

When an Open Finding Becomes an Enforcement Problem

An open finding is not, by itself, an infringement. Neither the Directive nor the CIR Annex sets a closure deadline or a maximum age for a remediation item you raised yourself, though your member state’s transposing law may. What creates exposure is a sequence, and the sequence is written into Articles 32 and 33.

Competent authorities may “order the entities concerned to implement the recommendations provided as a result of a security audit within a reasonable deadline”. That wording is identical in Article 32(4)(f) for essential entities and Article 33(4)(f) for important entities[10][11]. The two regimes differ in what triggers supervision in the first place, ex ante for essential entities and ex post for important ones, but once a finding exists the order power is the same. Authorities may also adopt binding instructions that carry “time-limits for the implementation of such measures and for reporting on their implementation”[10].

The step after that is where the cost lands. Article 32(7) lists what authorities must take due account of when taking enforcement measures, and paragraph (a) names circumstances “constituting serious infringement in any event”. Point (iii) is “a failure to remedy deficiencies following binding instructions from competent authorities”[10]. Ignoring a finding is a judgement call an authority weighs; ignoring one after being told to fix it is classified as serious by the text itself. Two further factors cut both ways: (b) “the duration of the infringement”, which puts a direct price on elapsed time, and (f) “any measures taken by the entity to prevent or mitigate the material or non-material damage”, which is where a documented, dated remediation record earns its keep as mitigation evidence.

So your remediation record is more than an internal management tool. It is the artefact that distinguishes an entity working the problem from one that was not, at the moment an authority decides how hard to press.

Germany’s Mängelliste: the Only Closure Format a Regulator Has Published

The CIR prescribes no template for recording findings and their closure. One national authority has published one. Under § 39 BSIG, German operators of critical facilities submit evidence of their security measures to the BSI, and where the underlying audit found deficiencies they submit a Mängelliste, a deficiency list, alongside a plan for remedying them.

The BSI’s FAQ is unusually specific. The list “must be produced using the BSI’s current Excel template and sent to the BSI in xls format”, and may not be converted to another format such as PDF. The submission must list all security deficiencies uncovered in the underlying audit, not the subset still open. And on the question every compliance officer actually asks, the BSI is explicit: “Eine Nachbesserung und Abstellung der Sicherheitsmängel ist jederzeit zulässig und im Sinne der Steigerung der IT-Sicherheit in KRITIS sogar erwünscht” — subsequent remediation is permitted at any time and is expressly welcome. Deficiencies already fixed may be reported voluntarily[12].

Two caveats. This binds KRITIS operators in Germany under § 39 BSIG; it is not an EU-wide requirement, and the full deficiency list is required by that evidence regime, not by the CIR. Treated as what it is, though, it is the clearest published signal of what a supervising authority wants a closure record to contain: every finding, the plan, and a format it can read.

What Each Role Owns

Role	What you own in finding closure
Compliance officer	The risk acceptance criteria, written before the findings arrive. Without them, 2.3.3’s second branch is unusable and every finding defaults to a fix you may not be able to fund.
CISO / IT security manager	The criticality judgement on every test and scan finding under 6.5.2(c) and 6.10.3, the root-cause work that decides whether a fix is real, and the quarterly recurring-incident assessment under 3.4.2(b).
Internal auditor	Independence under 2.3.2: reviewers must sit outside the line of authority of the area under review, and where the organisation is too small for that separation, alternative impartiality measures must be documented.
Management body	Receiving the results and making the accept-or-fix call. Under Article 20(1) this is an approval and oversight duty attached to personal liability, not a briefing.

Five Ways a Closed Finding Reopens

Mistake	Why it fails
Closing on “action implemented” rather than on effectiveness	Point 7.1 requires assessing whether measures are “effectively implemented and maintained“[2]. A deployed control that was never re-tested is an unverified claim. Track closure with metrics that measure the outcome, not the ticket status.
Accepting risk with no criteria and no record	Point 2.3.3 permits acceptance only “according to the relevant entities’ risk acceptance criteria”. No criteria, no valid acceptance.
Keeping findings in a register the risk treatment plan never sees	Points 2.1.3 and 3.6.2 both require findings to feed treatment decisions. Two divergent lists is the first thing an auditor reconciles.
Skipping the quarterly recurring-incident assessment	3.4.2(b) fixes the cadence at quarterly. A missed test does not stop Article 4 from aggregating the incidents; it only stops you from knowing.
Treating an authority’s deadline as a target	Failure to remedy after binding instructions is named a serious infringement in Article 32(7)(a)(iii)[10]. This is the single most expensive item on the list.

Frequently Asked Questions

Does NIS2 require a CAPA register? No. Neither the Directive nor the CIR Annex requires one, and the Annex never uses the phrase “preventive action”. What is required is that findings reach the management bodies and result in either corrective action or a documented residual-risk acceptance under point 2.3.3, and that they inform risk treatment under 2.1.3.

How long do we have to close a finding? Neither the Directive nor the CIR Annex sets a fixed period for findings you raise yourself, though national transposing law may. Deadlines otherwise appear only when an authority imposes one under Article 32(4)(b) or (f), or the equivalent points in Article 33(4). But Article 32(7)(b) makes “the duration of the infringement” an explicit enforcement factor, so elapsed time is priced even without a stated deadline.

Can we simply accept a finding instead of fixing it? Yes, if you accept it properly. Point 2.3.3 makes residual-risk acceptance a legitimate outcome, but only against criteria the organisation has already defined, and only with the result reported to the management bodies who carry Article 20(1) liability.

Is an ISO 27001 corrective-action process enough for NIS2? It is a strong starting point and shares the same root-cause and effectiveness-review logic, but it does not cover everything. NIS2 adds the management-body reporting duty, the quarterly recurring-incident assessment at 3.4.2(b), and the substantiated no-remediation decision at 6.10.3. Map those onto the process rather than assuming the certificate covers them.

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, laying down rules for the application of Directive (EU) 2022/2555 — Articles 3 and 4 and the Annex, EUR-Lex
2. ENISA. Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0, June 2025 — verbatim reproduction of the CIR Annex, with non-binding guidance and evidence examples. European Union Agency for Cybersecurity, enisa.europa.eu (PDF)
3. National Cyber Security Centre Ireland. NIS2 Draft Risk Management Measures Guidance, 24 June 2025 — RMM005, continuous improvement. Draft; the National Cyber Security Bill remains pending, ncsc.gov.ie (PDF)
4. Directive (EU) 2022/2555, Article 21 — cybersecurity risk-management measures, including point (2)(f), nis-2-directive.com
5. Indiana University, Office of Research Compliance. Corrective and Preventive Action (CAPA) Plans — definition and nine-step CAPA sequence, research.iu.edu
6. ISO 9001 Auditing Practices Group (ISO/TC 176 and IAF). Guidance on: Risk Based Thinking, Edition 1, 13 January 2016, committee.iso.org (PDF)
7. Directive (EU) 2022/2555, Article 20 — governance and management-body liability, nis-2-directive.com
8. Commission Implementing Regulation (EU) 2024/2690, Article 4 — recurring incidents, Springlex
9. Commission Implementing Regulation (EU) 2024/2690, Article 3(1)(a) — financial-loss criterion for significant incidents, Springlex
10. Directive (EU) 2022/2555, Article 32 — supervisory and enforcement measures in relation to essential entities, nis-2-directive.com
11. Directive (EU) 2022/2555, Article 33 — supervisory and enforcement measures in relation to important entities, nis-2-directive.com
12. Bundesamt für Sicherheit in der Informationstechnik. Fragen und Antworten zu Nachweisen gemäß § 39 BSIG — Mängelliste format and remediation after submission. BSI, Germany, bsi.bund.de
13. Commission Implementing Regulation (EU) 2024/2690, Article 1 — subject matter and the entity categories the Regulation binds directly, Springlex