Policy as Code for NIS2: What Your Pipeline Can Generate, and the 62 Clauses That Need a Written Reason

A CI/CD pipeline can produce most of the evidence a NIS2 regulator asks for. It cannot produce the policy document itself, and one field in particular — point (k) of the binding Annex — is drafted in a way no pipeline can satisfy.

That is the whole answer, and it is worth being precise about where the line falls, because the vendor literature is not. Commission Implementing Regulation (EU) 2024/2690 is the only EU-level text that says what NIS2 documentation must actually contain, and reading it field by field produces a cleaner split than any tooling comparison: of the eleven mandatory contents of your top-level security policy, three are lists a pipeline can generate and keep current, two are human acts a system can evidence, and six have to be written and owned by people.

A regulator makes two different requests, and only one of them is automatable

NIS2 Article 32(2) gives competent authorities a list of supervisory powers over essential entities. Two of them matter here, and they are deliberately separate.

Point (e) covers requests for information needed to assess the measures you have adopted, “including documented cybersecurity policies”. Point (g) covers “requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence” [2]. Article 33(2), points (d) and (f), gives competent authorities the same two powers over important entities, exercised after the fact rather than proactively.

So the regulator asks for a document, and separately asks you to prove the document is true. Policy as code is very good at the second request and structurally unable to answer the first. Every claim you will read about “automating NIS2 documentation” is really a claim about point (g) evidence, dressed up as a claim about point (e) documents.

What policy as code actually is, in one paragraph

Policy as code means expressing rules in a machine-evaluable language and running them against real system state. The Open Policy Agent project — a CNCF graduated project since January 2021 [6] — uses Rego, a language “purpose built for policy evaluation” that evaluates API requests, infrastructure-as-code files and configuration data, and returns decisions about “whether data violates the expected state of your system” [5]. A parallel effort exists on the documentation side: NIST’s Open Security Controls Assessment Language expresses control catalogues, baselines and assessment results in XML, JSON and YAML, with the explicit aim of moving security planning off “the legacy, document-based approach … (Word and Excel)” to a data-centric model [4].

Both are real and both are useful. Neither produces a sentence explaining why your organisation decided something. Hold that thought — it turns out to be the binding constraint.

First check whether the binding text even applies to you

In plain terms: CIR 2024/2690 is law for eleven named kinds of provider. For everyone else in NIS2 scope it is guidance, not obligation — but it is the most detailed guidance that exists, and national authorities are using it as the yardstick.

Article 1 of the Implementing Regulation lists the entities it binds: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, of online search engines and of social networking services platforms, and trust service providers [1]. If your organisation is a hospital, a water utility, a food manufacturer or a bank, the Annex does not bind you. Your obligations are the ten measures in NIS2 Article 21(2) as transposed into your national law, and your competent authority decides what detail looks like.

Read the Annex anyway. It is the Commission’s own answer to “what does Article 21(2) mean in practice”, and it is the basis of ENISA’s 170-page implementation guidance — which states that beyond the entities it binds, the material “may provide indications … which may be considered useful by other public or private bodies” [3]. The automation question resolves the same way whichever side of Article 1 you sit on.

The eleven fields, and the three a pipeline can generate

Annex point 1.1.1 says the policy on the security of network and information systems shall do eleven things, lettered (a) to (k) [1]. Sorting them by who can produce them is the most useful thing you can do with an afternoon:

Annex 1.1.1 point	What it requires	Who produces it
(a)	Set out the entity’s approach to managing security	Human-authored. An approach is a position, not a state
(b)	Be appropriate to and complementary with business strategy and objectives	Human-authored. Requires knowing the strategy
(c)	Set out security objectives	Human-authored. Objectives are chosen
(d)	Include a commitment to continual improvement	Human-authored. A commitment needs someone to make it
(e)	Include a commitment to provide resources — staff, budget, processes, tools	Human-authored. Only a budget holder can commit a budget
(f)	Be communicated to and acknowledged by employees and external parties	System-evidenced. The act is human; the acknowledgement record is machine-held
(g)	Lay down roles and responsibilities	System-evidenced. Assignment is human; current holders come from IAM/HR
(h)	List the documentation to be kept and its retention duration	Generated. A register with retention metadata
(i)	List the topic-specific policies	Generated. Emit it from the policy repository
(j)	Lay down indicators and measures to monitor implementation and maturity status	Generated, once a human has chosen the indicators
(k)	Indicate the date of the formal approval by the management bodies	Human act. See the next section

Three generated, two system-evidenced, six human-authored. That ratio is the realistic ceiling on “automating your documentation”, and it is better than it looks: points (h), (i) and (j) are exactly the fields that rot fastest in a Word document, because they change every time a policy is added or an indicator moves. Generating them from the repository that already holds the policies is a genuine improvement in accuracy, not just in effort. The measurement side of (j) is where a compliance monitoring dashboard earns its place.

What you cannot do is let the generator write (a) through (e). Those five points ask the organisation to take positions, and a document that takes no position fails them however well formatted it is.

Point (k) is where the argument ends

Point (k) requires the policy to “indicate the date of the formal approval by the management bodies” [1]. A commit timestamp is not that date. A pipeline can record when a file changed; it cannot perform an approval, because approval is a legal act assigned to named people.

The mechanism sits one level up, in the Directive. Article 20(1) requires Member States to ensure that management bodies “approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements” [2]. Liability is the reason the approval cannot be delegated to a merge queue. The date in point (k) is the evidentiary anchor for that liability — it establishes when a specific board took responsibility for a specific version of the policy.

Annex 1.1.2 extends the same logic to maintenance: the policy “shall be reviewed and, where appropriate, updated by management bodies at least annually and when significant incidents or significant changes to operations or risks occur. The result of the reviews shall be documented.” [1] Note who does the reviewing. Not the security team, not the pipeline — the management bodies, at least once a year, and again whenever something significant happens.

Here the tooling does come back in. ENISA’s guidance lists, among the examples of evidence for 1.1.2, “review comments or change logs for the policy on the security of network and information systems and topic-specific policies” [3]. A version-controlled policy repository produces exactly that artefact, with better fidelity than a document properties pane. The human decides and signs; the repository proves what was decided and when.

The 62 clauses that turn a “no” into a written paragraph

This is the part no automation vendor mentions, and it is the single largest documentation duty the Implementing Regulation creates.

Article 2(2), second subparagraph, reads: where the Annex provides that a requirement applies “where appropriate”, “where applicable” or “to the extent feasible”, and the entity considers it not appropriate, not applicable or not feasible, “the relevant entity shall in a comprehensible manner document its reasoning to that effect” [1].

Counting those three phrases across the Annex text gives 48 instances of “where appropriate”, 10 of “where applicable” and 4 of “to the extent feasible” — 62 clauses, against 218 uses of “shall”. (That is our own word-boundary count over the EUR-Lex text of the Annex; it is reproducible in a few lines of script, and worth re-running against the consolidated version before you rely on it.) Every one of those 62 is a place where opting out is permitted and costs you a paragraph of written reasoning aimed at a human reader.

“In a comprehensible manner” is the operative constraint. A boolean flag set to false in a YAML file is not a reason. A Rego rule that skips a check is not a reason. The regulation asks for an explanation that a supervisor can read and evaluate, and the assessment underneath it — why this control is disproportionate for this entity, what compensates for its absence — is judgement work.

ENISA points at the same object from the evidence side. Among the examples of evidence for compliance monitoring it lists “logs of policy exceptions”, naming “the situations mentioned in the second paragraph of Article 2(2)” as an example, alongside “records of the exception request and approval, along with details of the compensatory controls implemented” [3]. Read those together and the design becomes obvious: an exception register, machine-maintained, each row carrying a human-written justification and a named approver. That is the correct hybrid, and it is the artefact most organisations are missing entirely.

Where policy as code is the regulation’s own answer

The Annex is not hostile to automation. It mandates it in places, and the places are specific.

• Configuration enforcement — Annex 6.3.2(b). Entities shall “lay down and implement processes and tools to enforce the laid down secure configurations for hardware, software, services and networks, for newly installed systems as well as for systems in operation over their lifetime” [1]. That is a binding requirement for enforcement tooling across the asset lifecycle, which is the textbook policy-as-code use case. ENISA’s guidance for the same point says plainly: “employ automated mechanisms to centrally manage, apply and verify configuration settings” [3].
• Monitoring — Annex 3.2.2. “To the extent feasible, monitoring shall be automated and carried out either continuously or in periodic intervals, subject to business capabilities” [1]. This is the broadest of the Annex’s two automation duties — the other, point 3.2.4, requires that an exceeded alarm threshold trigger an alarm “where appropriate, automatically” [1]. Both are conditional clauses, so declining either means writing the reasoning down.
• Change records — Annex 6.4.2 and 6.4.3. Changes must be documented, tested and assessed before implementation; where an emergency prevented the normal procedure, you document the result “and the explanation for why the procedures could not be followed” [1]. A merge request with a linked test run covers the first half natively. The emergency explanation is prose again.
• Compliance reporting — Annex 2.2.1 and 2.2.2. Management bodies “shall be informed of the status of network and information security on the basis of the compliance reviews by means of regular reporting”, via a reporting system capable of giving them “an informed view of the current state” [1]. The numbers should be generated. The interpretation put in front of the board should not be.

Notice the pattern across all four: the regulation automates state and reserves reasoning for people. That is a more useful design principle than any product category, and it survives whichever tools you buy. If you are evaluating platforms against it, our comparison of ten NIS2 compliance tools scores them on Article 21 evidence handling specifically.

A working split, by role

The same article lands differently depending on who is reading it, so here is the split three ways.

Role	Owns	First thing to do
CISO / platform engineering	Annex 6.3.2(b) enforcement, 3.2.2 monitoring, the generators behind points (h), (i) and (j)	Emit the topic-specific policy register and the retention register from the policy repository, and stop maintaining them by hand
Compliance officer	The exception register behind the 62 Article 2(2) clauses, and the 1.1.2 review record	Build the register with a mandatory free-text justification field and a named approver per row — before an auditor asks which controls you skipped
Management body	Points (a) to (e) and (k); the annual 1.1.2 review; Article 20(1) approval and liability	Put the policy approval on a calendared agenda item with a recorded date, and keep the minute

One practical warning from building these: the failure mode is not the pipeline, it is the seam. Organisations that generate points (h) to (j) successfully often let the generated artefact drift out of the approved document, so the policy the board signed and the register the system produces disagree. Reference the generated registers from the approved policy as named annexes with their own version identifiers, rather than pasting their contents into the document body. Then the board approves the policy and the pointer, and the annex can update on its own cadence without invalidating the approval date in point (k).

Frequently asked questions

Can we store our NIS2 policies in Git instead of a document management system?
Yes, and for point 1.1.2 it helps: ENISA lists change logs as an example of acceptable evidence [3]. What matters is that the approved version is identifiable and that the approval date required by point (k) is recorded in the policy itself, not inferred from commit metadata.

Does OSCAL satisfy NIS2 documentation requirements?
OSCAL is a format, not a compliance state. It can carry your control implementations and assessment results in a machine-readable structure [4], which serves the Article 32(2)(g) evidence side well. It does not supply the eleven contents required by Annex 1.1.1, and neither the Directive nor the Implementing Regulation names it.

We are not one of the eleven entity types in CIR Article 1. Do these rules bind us?
No. Your binding obligations are Article 21(2) as transposed nationally [2]. The Annex remains the most detailed available interpretation of those obligations, and using it as a benchmark is a defensible position rather than a required one.

Can an automated tool sign off the annual policy review?
Annex 1.1.2 assigns the review to the management bodies [1], and Article 20(1) attaches liability to them [2]. A tool can schedule the review, assemble the pack and record the outcome. The review itself is theirs.

How much of a NIS2 documentation set can realistically be generated?
On the top-level policy, three of eleven fields outright and two more as supporting evidence. Across the wider Annex the generated share is higher for technical records — configuration baselines, change records, monitoring output — and close to zero for the 62 justification clauses and anything requiring an approval.

What to do next

Open the Annex, search it for the three conditional phrases, and list every clause your organisation intends to decline. That list is your exception register, and it is almost certainly longer than your current documentation admits. Generate the registers in points (h), (i) and (j) from the systems that already hold the truth. Then put the policy in front of your management body, get the date in point (k), and keep the minute.

The honest version of the vendor pitch is this: policy as code can make your evidence continuously true, which is a real and substantial benefit. It cannot make a decision on your behalf, and NIS2 documentation is mostly a record of decisions.

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 — EUR-Lex (Articles 1 and 2; Annex points 1.1.1, 1.1.2, 2.2, 3.2.2, 6.3 and 6.4)
2. Directive (EU) 2022/2555 (NIS2) — EUR-Lex (Articles 20, 21, 32 and 33)
3. Technical Implementation Guidance on cybersecurity risk-management measures, v1.0 (June 2025) — ENISA
4. Open Security Controls Assessment Language (OSCAL) — NIST Computer Security Resource Center
5. Policy Language (Rego) — Open Policy Agent documentation
6. Open Policy Agent (OPA) — Cloud Native Computing Foundation
7. NIS2 Compliance Guide — Puppet