NIS2 Article 21(2)(a): The Two Documents Every Auditor Asks For First

On 15 August 2026 the Dutch Cyberbeveiligingswet entered into force. More than 8,000 organisations now carry a duty of care, a registration obligation with the NCSC, and a 24-hour reporting clock.

Not one of them will be asked about their EDR console first.

NIS2 Article 21(2)(a) is where every supervisory conversation starts: your policy on the security of network and information systems, and your risk management framework. Two documents. Both signed by the management body. Both dated.

Most organisations have neither in the form the regulation actually requires. Here is what Article 21(2)(a) demands, control by control, and what that means for the consultants who have to deliver it.

Article 21(2)(a) is two obligations, not one

The Directive text is eight words long: "policies on risk analysis and information system security." Read quickly, it sounds like a single policy document.

Commission Implementing Regulation (EU) 2024/2690 disagrees. Its Annex splits Article 21(2)(a) into two separate top-level sections:

• Section 1 — Policy on the security of network and information systems, plus roles, responsibilities and authorities.
• Section 2 — Risk management policy: the framework, compliance monitoring, and independent review.

The CIR is directly binding on DNS providers, TLD registries, cloud providers, data centre operators, CDNs, managed service providers, managed security service providers, online marketplaces, search engines, social platforms and trust service providers. For everyone else it is the de facto benchmark, because national supervisors have nothing more specific to measure against.

If you deliver one combined "information security policy" and call Article 21(2)(a) done, you have satisfied roughly half of it.

Your security policy has eleven mandatory contents

Annex point 1.1.1 lists what the top-level policy must contain. Not "should consider" — must set out:

1. The entity's approach to managing security of its network and information systems
2. Alignment with business strategy and objectives
3. Stated security objectives
4. A commitment to continual improvement
5. A commitment to provide resources — staff, budget, processes, tools, technology
6. Communication to and acknowledgement by relevant employees and external parties
7. Roles and responsibilities as set out in point 1.2
8. The documentation to be kept, and its retention period
9. A list of the topic-specific policies
10. Indicators and measures to monitor implementation and current maturity level
11. The date of formal approval by the management bodies

Item 5 is the one that fails most audits. A policy that commits to security but never commits budget or headcount is not compliant with 1.1.1(e). Neither is item 10: if you cannot show the indicators you use to measure your own policy, you have a statement of intent, not a policy.

Item 11 is the cheapest to fix and the most frequently missing. A policy without a dated management-body approval is, for supervisory purposes, a draft.

Where 21(2)(a) sits among the ten measures

Article 21(2)(a) is the first of ten cybersecurity risk-management measures — and the one every other measure inherits from. Access control under 21(2)(i) has to be a topic-specific policy under your top-level policy. Backup requirements under 21(2)(c) have to be driven by a business impact analysis that feeds your risk treatment plan. Get (a) wrong and the other nine have no foundation to sit on.

The management body must sign — and sign again

Point 1.1.2 requires the policy to be reviewed and, where appropriate, updated by the management bodies at least annually, and additionally whenever significant incidents or significant changes to operations or risks occur. The result of each review must be documented.

Two practical consequences.

First, "annually" is a floor, not a schedule. A merger, a new cloud platform, a ransomware incident at a key supplier — each of these triggers an out-of-cycle review. If your client onboarded a new ERP in March and the policy was last reviewed in January, that is a gap a supervisor can find in one question.

Second, the review is a board activity, not an IT activity. The CISO can prepare it. The management body has to perform it. This is the operational expression of the personal accountability in Article 20 — and it is the reason board minutes have become audit evidence.

At least one person must report directly to the board

Point 1.2.3 is a single sentence with outsized consequences: at least one person shall report directly to the management bodies on matters of network and information system security.

For an MSP, this is the line you cannot cross on your client's behalf. You can run the SOC, write the policy, maintain the risk register and prepare the board pack. You cannot be the person who reports to the board on their behalf, because the accountability sits inside the entity.

Point 1.2.5 adds segregation of conflicting duties, where applicable. Point 1.2.4 concedes reality for smaller entities: security may be a duty carried out in addition to an existing role, rather than a dedicated function. What it does not concede is that the duty can be absent.

The risk management framework is a process, not a spreadsheet

Annex point 2.1.2 defines the cybersecurity risk management process in ten steps. Entities must:

• Follow a risk management methodology
• Establish a risk tolerance level in line with risk appetite
• Establish and maintain risk criteria
• Identify and document risks using an all-hazards approach, explicitly including third parties and single points of failure
• Analyse threat, likelihood, impact and risk level, using cyber threat intelligence and vulnerability data
• Evaluate risks against the criteria
• Identify and prioritise treatment options
• Continuously monitor implementation of treatment measures
• Name who is responsible for each treatment measure and by when
• Document treatment measures in a risk treatment plan, with comprehensible justification for any accepted residual risk

Read that list against the average client risk register. Most have a list of risks with a red-amber-green rating. Very few have a documented methodology, a stated tolerance level, named owners with deadlines, and written justification for residual risk.

The all-hazards requirement is also broader than most teams assume. It covers physical and environmental threats, supplier failure and staff unavailability — not just cyber attacks. If your register contains only attack scenarios, it does not meet 2.1.2(d). Third-party risk in particular must be identifiable in the register itself, which is where it connects to supply chain obligations under Article 21(2)(d).

Point 2.1.3 adds a constraint that consultants should welcome: when prioritising treatment, entities must weigh cost of implementation against expected benefit. Proportionality is written into the regulation. You are not required to recommend everything — you are required to justify what you did and did not do.

Residual risk needs a name on it

Point 2.1.1 is the sentence that changes governance: risk assessment results and residual risks shall be accepted by management bodies, or by persons who are accountable and have authority to manage risks, with adequate reporting to the management bodies.

That is a signature requirement. "The board was informed" is not acceptance. There has to be a decision, by a named accountable person, recorded.

Point 2.1.4 then requires the risk assessment and treatment plan to be reviewed at planned intervals and at least annually, and after significant incidents or significant changes. Same trigger logic as the policy review, applied to the register.

Compliance monitoring and independent review are two different things

Point 2.2 requires regular review of compliance with your own policies, standards and rules, with regular reporting to the management bodies through an effective compliance reporting system.

Point 2.3 requires something else entirely: an independent review of the entity's approach to managing security — people, processes and technology — carried out by individuals with appropriate audit competence who are not in the line of authority of the area under review.

Where separation is impossible because of size, the entity must put alternative measures in place to guarantee impartiality. It cannot simply skip the review.

This is the clearest commercial opening in Article 21(2)(a) for consultants and vCISOs. A ten-person important entity cannot produce an internally independent reviewer. An external one is the alternative measure. Note that 2.3 sits alongside, not instead of, the effectiveness assessment under Article 21(2)(f) — supervisors will expect both.

Supervisors are no longer waiting

The pressure is coming from two directions at once.

Nationally: the Netherlands went live on 15 August 2026 with the Cyberbeveiligingswet, covering 18 sectors and over 8,000 entities. Germany's registration window closed months ago with a large share of in-scope entities still unregistered. Austria, Sweden, Poland and Portugal are all in force.

From Brussels: on 8 July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice of the EU over incomplete transposition, requesting financial sanctions. Member states that are slow to transpose are being pushed hard — which historically translates into national authorities that are keen to demonstrate enforcement activity once their law lands.

What happens when 21(2)(a) is missing

An absent or undated policy is rarely the finding that ends an inspection. It is the finding that starts one. If the top-level policy is not approved, the topic-specific policies underneath it have no mandate. If the risk register has no methodology, every downstream control decision becomes unjustifiable.

From there, the supervisory toolkit escalates: binding instructions, mandatory audits at the entity's expense, public disclosure of non-compliance, administrative fines up to €10 million or 2% of global annual turnover for essential entities, and — for essential entities — temporary suspension of management functions.

A 30-day plan for consultants

If you support in-scope clients, this is the sequence that produces defensible evidence fastest:

Days 1–5. Pull the client's current security policy. Check it against the eleven contents in point 1.1.1. Most will fail on resources, indicators and the approval date.

Days 6–10. Establish whether anyone reports directly to the management body on security. If not, name that person and get it minuted.

Days 11–20. Rebuild the risk register around 2.1.2: documented methodology, stated tolerance, all-hazards scope including suppliers and single points of failure, named owners, deadlines, and written residual-risk justification.

Days 21–25. Put the policy and the risk treatment plan in front of the management body. Get formal approval, dated, minuted.

Days 26–30. Define the compliance monitoring cadence under 2.2 and schedule the first independent review under 2.3, with an explicit note on how impartiality is guaranteed.

That produces the two artefacts a supervisor asks for first — with the governance trail that proves they are real.

If you want a fast read on where a client stands against Article 21 before you commit to a project scope, run the NIS2 quick scan. It maps the gaps in minutes so you can price the work instead of guessing at it.

The short version

Article 21(2)(a) is not documentation overhead. It is the control that makes every other control defensible. A policy with eleven defined contents and a dated board approval. A risk framework with a methodology, named owners and accepted residual risk. Compliance monitoring, and an independent review by someone outside the line of authority.

Everything else in Article 21 is built on top of those. Build them first.