NIS2 Change Management Policy: Article 21(2)(e), Not (a) — and the Annex 6.4 Gate Before You Deploy

NIS2 does not ask you for a change management policy. The binding text asks for change management procedures and the records they produce, and it files them under Article 21(2), point (e) — acquisition, development and maintenance — not under the risk-management measure in point (a) where most policy registers put them.

That distinction is not pedantry. It decides which measure your evidence is filed against in an audit, and it explains the one genuine cross-reference in the clause: your change procedures are gated by the risk assessment that point (a) produces. Below is what Commission Implementing Regulation (EU) 2024/2690 actually binds you to, in four sentences of legal text, and which of the familiar ITIL furniture around it — change advisory boards, rollback plans, separate test environments — is law and which is only ENISA’s advice.

Does point 6.4 bind you, or only Article 21(2)(e)?

In plain terms: one group of entities is bound by the detailed Annex text word for word. Everyone else in scope of NIS2 is bound by the Directive’s one-line measure, and can treat the Annex as the best available interpretation of it.

Your entity	What binds you	Practical reading
One of the 11 types named in CIR Article 1 — 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	Annex point 6.4, in full, as a directly applicable EU regulation [1]	6.4.1 to 6.4.4 are auditable requirements. Write your procedures against the clause numbers.
Any other essential or important entity	Article 21(2)(e) as transposed into your national law [2]	The Annex does not bind you. It is still the most detailed EU-level statement of what point (e) means, and following it is defensible rather than required.

Article 21(5) explains the split: the Commission had to adopt this implementing act for those 11 types by 17 October 2024, and may adopt further ones, including sectoral acts, for other entities [2]. “May” is the operative word, so writing a change procedure that already reads on 6.4 is a hedge rather than a deadline.

Change management is point (e), and the Directive never says the words

The Annex settles the mapping in its own section heading, which reads: “6. Security in network and information systems acquisition, development and maintenance (Article 21(2), point (e), of Directive (EU) 2022/2555)” [1]. Change management is point 6.4 inside that section, between configuration management at 6.3 and security testing at 6.5.

Point (a), by contrast, is “policies on risk analysis and information system security”, and the Annex gives it section 2 — the risk management framework at 2.1 [1][2]. A change management procedure filed under (a) is filed against the wrong measure.

There is a sharper way to see how little the Directive itself says here. Across the full English text of Directive (EU) 2022/2555 on EUR-Lex, the phrases change management, change control, emergency change, rollback, change advisory and test environment each appear zero times [2]. Its entire contribution to this topic is the word “maintenance” inside point (e). Every ITIL-shaped NIS2 change management policy on the market is therefore an interpretation of the implementing regulation plus ENISA’s non-binding guidance — never a reading of the Directive.

For a compliance officer, the practical consequence is a filing correction: move the change procedure, and its evidence, into the (e) folder alongside secure development and patching. For a CISO, it is a scoping correction — the same folder already contains vulnerability and patch management under CIR Annex 6, and 6.4 is the procedure those clauses defer to.

The four sentences that actually bind you

In plain terms: control changes with a documented procedure, apply it to software, hardware and configuration alike, assess each change against your risk assessment before it goes live, and write up the ones where the emergency beat the process.

Point	What it requires	What it does not say
6.4.1	Apply change management procedures to control changes of network and information systems. Where applicable, keep them consistent with your general policies on change management.	It does not require a standalone document called a change management policy. “Procedures” is the binding noun; the policy is referenced only conditionally.
6.4.2	Apply those procedures to releases, modifications and emergency changes of any software and hardware in operation, and to configuration changes. Document the changes and, based on the risk assessment carried out pursuant to point 2.1, test and assess them in view of potential impact before implementation.	It names no tooling, no approval body, no environment topology and no change categories.
6.4.3	Where an emergency meant the regular procedure could not be followed, document the result of the change and the explanation for why the procedure could not be followed.	It does not prohibit emergency changes or set a retrospective approval deadline.
6.4.4	Review and, where appropriate, update the procedures at planned intervals and when significant incidents or significant changes to operations or risks occur.	It names no review frequency.

The load-bearing phrase is in 6.4.2: changes must be tested and assessed “before being implemented”, and the assessment is anchored “based on the risk assessment carried out pursuant to point 2.1” [1]. It is the only cross-reference in the whole of point 6.4, and it turns your Article 21(2)(a) risk management framework into a pre-deployment gate rather than an annual paper exercise. If your risk assessment does not cover the asset you are about to change, 6.4.2 has nothing to gate against — the deficiency shows up as a change management finding, not a risk management one.

It also explains why 6.4.4’s review trigger is drawn so widely. The phrase “significant changes to operations or risks” appears 21 times across the Annex, in 11 of its 13 sections — 2.1.4, 6.3.3, 6.4.4, 6.7.3 and 12.2.3 among them [1]. A migration, an acquisition or a major new supplier does not merely generate a change record; it re-opens the risk assessment, the configurations and the asset inventory in parallel, and that documentation pass usually runs longer than the technical work.

What is law here, and what is only ENISA’s advice

ENISA’s Technical Implementation Guidance, version 1.0 of June 2025, expands point 6.4 across four pages of guidance, evidence examples and tips. It is explicit about its own status: it “provides non-binding guidance” that is “not legally binding and … only recommendations”, and whose implementation “does not assume compliance or conformity with the requirements of the regulation” [3].

That matters because almost everything a commercial change management template treats as mandatory comes from this layer, not from the regulation.

Element	Status	Source wording
Change advisory board (CAB)	ENISA guidance, conditional	“Where appropriate, establish a change advisory board (CAB) to oversee and approve changes”, evaluating requests on risk, impact, resource requirements and business alignment [3]
Rollback / pullback plans	ENISA guidance	Procedures should consider “requirements for performing rollbacks”; 6.4.3 guidance adds the “pullback scenario”, defined in a footnote as a roll-back or backout plan [3]
Separate test environment	ENISA guidance, conditional	“Where appropriate, a security impact analysis may be performed in a separate test environment before implementation in an operational environment” [3]
Change categories and differentiated workflows	ENISA guidance	Procedures “may allow different workflows depending on the criticality of the system, the scope of the change and the urgency”, for example an emergency intervention workflow [3]
Two-yearly procedure review	ENISA guidance	“Review the change management procedures at least once every two years” — the binding trigger in 6.4.4 remains planned intervals plus significant incidents or changes [1][3]
Pre-implementation testing and impact assessment	Binding	Point 6.4.2 [1]
Emergency change write-up	Binding	Point 6.4.3 [1]

Dropping an ENISA recommendation is a defensible decision, not a gap — but it is a documented one. Where the Annex itself qualifies a requirement with “where appropriate”, “where applicable” or “to the extent feasible” and you judge it inapplicable, CIR Article 2(2) requires you to “in a comprehensible manner document” your reasoning [1]. A small managed service provider that runs no CAB should record why its approval model is proportionate, rather than leaving the absence unexplained.

The two words everyone drops: repairs and maintenance

The clause is titled “Change management, repairs and maintenance” [1]. Commercial templates almost invariably cover the first third and stop, which leaves a predictable evidence gap on the physical side of the same point.

ENISA’s tips under 6.4 make the intended breadth concrete: perform and log changes, maintenance and repairs “with approved and controlled tools”; restrict maintenance tools to authorised personnel; ensure availability of “the required maintenance skills, resources and spare parts, including external support”; prevent unauthorised removal of maintenance equipment holding entity information, by sanitising, destroying, retaining it on site or explicitly authorising removal; and provide out-of-band remote access for when the standard connection fails [3]. The evidence examples include MFA on remote change, repair and maintenance procedures.

For a data centre or cloud provider, this is the part of 6.4 an on-site inspection can actually observe: hardware swaps, vendor engineers on the floor, and the laptop a contractor carries out of the building. None of them appear in a change ticket queue.

One procedure, three clauses

Point 6.4 is a hub rather than a silo. Patch management at 6.6.1 must be “coherent with the change management procedures referred to in point 6.4.1”, and vulnerability handling at 6.10.2(d) requires entities to ensure their handling is “compatible with their change management, security patch management, risk management and incident management procedures” [1]. Recital 16 signals the same intent, non-bindingly, for patching alignment [1].

Read the other way round: you do not need three procedures. You need one change procedure that patching and vulnerability remediation both enter through, with the categorisation criteria separating a routine security patch from a system replacement. The 45 NIS2 technical controls for IT administrators map the same Annex points to control-level tasks.

What a supervisor actually asks for

Article 32(2) separates two supervisory powers over essential entities: point (e) covers requests for information including “documented cybersecurity policies”, and 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]. Ad hoc audits under point (c) are available where justified by a significant incident. The written procedure answers one request; the change records answer the other, and the second is where change management fails.

ENISA’s evidence examples for 6.4 are specific enough to use as a checklist [3]:

• The documented procedures themselves, based on recognised standards or good practice
• Per-change records describing the steps followed and the result
• Emergency change records with the reason for the emergency, the approval, the reason for delay, follow-up actions, and how to revert the system if the change fails
• Specific pullback plans, where the pullback scenario has been adopted
• Logs of the dates and outcomes of periodic reviews of the change, repair and maintenance procedures
• An up-to-date asset inventory and risk treatment plan, since ENISA’s tips ask you to update point 12.4 and point 2.1.1 respectively when changes occur

One item on that list is routinely missed. ENISA also advises that “if an incident, in the sense of Article 23 of the NIS2 Directive, involves subsequent actions that entail system changes, then notify the competent authorities of these changes in accordance with the national reporting procedure” [3]. Post-incident remediation is change management and incident reporting at the same time — a link most change procedures do not contain.

Role	Owns	Effort
IT / operations	The procedure itself, categorisation criteria, per-change records, rollback plans	Medium
CISO / security	The 6.4.2 impact assessment, its link to the 2.1 risk assessment, emergency change review	Medium
Compliance / legal	Filing evidence under point (e), Article 2(2) reasoning for omitted items, the Article 23 notification link	Low
Management body	Approving the measures and overseeing implementation under Article 20(1), which also carries the liability [2]	Low

The exposure behind that last row sits in Article 34: for infringements of Article 21 or 23, fines of a maximum of at least EUR 10 000 000 or 2% of total worldwide annual turnover, whichever is higher, for essential entities, and at least EUR 7 000 000 or 1.4% for important entities [2]. Those are ceilings for Article 21 as a whole, not tariffs for a missing change record. Article 21(4) is the more immediate obligation: an entity that finds itself non-compliant must take corrective measures without undue delay [2].

Frequently asked questions

Do we need a document titled “Change Management Policy”?
Not under the binding text. Point 6.4.1 requires change management procedures, and mentions general policies only conditionally — “where applicable, the procedures shall be consistent with” them [1]. If your organisation already has a change policy, the procedures must align with it. If it does not, procedures plus records satisfy 6.4.

Can a CI/CD pipeline be our change management procedure?
It can be the standard-change workflow within it. ENISA’s guidance accepts that procedures “may allow different workflows depending on the criticality of the system, the scope of the change and the urgency” [3], which supports treating routine deployments differently from major changes. The constraint is 6.4.2: testing and impact assessment must happen before implementation, and must be traceable to your point 2.1 risk assessment [1].

How often must we review the change procedures?
The regulation sets no frequency: 6.4.4 requires review at planned intervals and on significant incidents or significant changes, so you choose the interval and record it. ENISA suggests at least every two years, as guidance [1][3].

We are not one of the 11 CIR entity types. Does any of this apply?
Point 6.4 does not bind you. Article 21(2)(e) as transposed nationally does, and member states map it in their own way — the German transposition, for instance, is itemised against equivalent national requirements [4]. Using the Annex as your reference standard is a defensible choice rather than an obligation.

What if an emergency change bypassed the whole process?
That is anticipated. Point 6.4.3 requires you to document the result of the change and the explanation for why the procedures could not be followed [1]. ENISA adds that the regular procedure should be applied immediately after the emergency change [3]. An undocumented emergency change is the finding; the emergency itself is not.

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; Recital 16; Annex points 2.1, 6.3, 6.4, 6.6 and 6.10)
2. Directive (EU) 2022/2555 (NIS2) — EUR-Lex (Articles 20, 21, 32 and 34)
3. Technical Implementation Guidance on cybersecurity risk-management measures, v1.0 (June 2025) — ENISA (section 6.4)
4. NIS2 Implementing Act DVO (EU) 2024/2690 — mapping — OpenKRITIS