What Cyber-Risk-Management Baseline Does NIS2 Article 21 Actually Require?

Most teams reading NIS2 for the first time go looking for a control list and come back frustrated. Article 21 does not hand you 114 controls the way ISO 27001 Annex A does. It hands you ten measure categories, the word "appropriate," and a proportionality test that pushes the sizing decision back onto you.

That ambiguity is not a loophole. It is the work. When a competent authority shows up, it will not check whether you implemented control X.Y.Z. It will ask whether your measures are appropriate to the risk you carry, and it will ask you to produce the evidence. This piece walks the actual text of Article 21, the ten categories, how the proportionality language changes what "appropriate" means for your entity, and what you should have on a ticket before an authority asks.

Every regulatory claim below is traced to the parsed NIS2 directive text. Where the directive is general, this stays general. No invented control IDs.

What does NIS2 Article 21 actually mandate — and who has to meet it?

Article 21(1) is the operative sentence. Member States must ensure that essential and important entities "take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services."

Read that as three obligations stacked in one clause:

1. Manage the risks to your network and information systems.
2. Prevent or minimise incident impact — not just on you, but on the recipients of your services and on other services downstream.
3. Use technical, operational, AND organisational measures. Technology alone does not satisfy the article. Policy and process are named explicitly.

Who has to meet it is decided upstream, in Articles 2 and 3. Article 2 brings in entities of a type in Annex I or II that qualify as medium-sized enterprises or exceed the medium-sized ceilings, where they provide services in the Union. Article 3 then sorts those into two tiers: essential entities (Annex I types above the medium-sized ceiling, plus DNS providers, TLD registries, qualified trust service providers regardless of size, and others) and important entities (Annex I or II types that do not meet the essential criteria). Some categories — trust service providers, DNS service providers, top-level domain name registries — are in scope regardless of size under Article 2(2).

The category split matters less for Article 21 than people assume. Both essential and important entities owe the same baseline of measures. The difference shows up later, in the supervision regime — but the control floor is identical.

Which ten measure categories make up the minimum baseline?

Article 21(2) says the measures "shall be based on an all-hazards approach" and "shall include at least the following." That phrase — "at least" — is the one to internalise. These ten are a floor, not a ceiling.

The ten categories, verbatim from the directive:

1. (a) Policies on risk analysis and information system security.
2. (b) Incident handling.
3. (c) Business continuity, such as backup management and disaster recovery, and crisis management.
4. (d) Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.
5. (e) Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
6. (f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
7. (g) Basic cyber hygiene practices and cybersecurity training.
8. (h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
9. (i) Human resources security, access control policies and asset management.
10. (j) The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.

Two of these get under-read. Category (f) — assessing the effectiveness of your own measures — is a control about your controls. If you have policies but no mechanism to test that they work, you have nine categories, not ten. And category (j) is not just "turn on MFA." It also names secured voice, video, text, and emergency communications, qualified with "where appropriate" — which loops you straight back into the proportionality test.

How does the all-hazards, proportionality test change what 'appropriate' means for your entity?

This is where Article 21 stops being a checklist and becomes a sizing exercise.

The second subparagraph of 21(1) tells you how to calibrate. The measures "shall ensure a level of security of network and information systems appropriate to the risks posed," taking into account "the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation." Then it gives you the proportionality factors explicitly. When assessing proportionality, "due account shall be taken of the degree of the entity's exposure to risks, the entity's size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact."

So "appropriate" is a function of four inputs you have to be able to evidence:

• Your degree of exposure to risk.
• Your size.
• The likelihood of incidents.
• Their severity, including societal and economic impact.

The practical consequence: you cannot answer "did we meet Article 21" with a yes/no. You answer it with a documented risk assessment that ties each of the ten categories to your specific exposure, and shows why the depth you chose is proportionate. A 60-person managed service provider and a national TLD registry both owe category (c) business continuity — but the disaster-recovery posture that is "appropriate" for each is wildly different, and the directive expects you to show your work.

The "all-hazards approach" language in 21(2) widens the aperture further. The measures must protect "network and information systems and the physical environment of those systems from incidents." Physical environment is in scope. A backup strategy that ignores the risk to the room the backups sit in is not all-hazards.

And do not skip 21(4): an entity that finds it does not comply "takes, without undue delay, all necessary, appropriate and proportionate corrective measures." Self-identified gaps carry a remediation duty. A gap register with no movement on it is itself a finding.

What evidence does a competent authority expect to see for each Article 21 measure?

This is the part that turns the article into an evidence program. The supervisory powers in Article 32 tell you exactly what an authority can demand — and therefore what you should be able to produce on request.

Article 32(2) gives competent authorities, at minimum, the power to subject essential entities to:

• On-site inspections and off-site supervision, including random checks by trained professionals (point a).
• Regular and targeted security audits carried out by an independent body or the competent authority (point b).
• Ad hoc audits, including where justified by a significant incident or an infringement (point c).
• Requests for information necessary to assess the risk-management measures, "including documented cybersecurity policies" (point e).
• 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" (point g).

Two phrases there should reshape your evidence backlog. "Documented cybersecurity policies" means each of the ten categories needs a written policy you can hand over. And "the respective underlying evidence" means the audit report alone is not enough — the authority can ask for what sits beneath it.

Note also that under Article 32, the costs of a targeted security audit carried out by an independent body are, as a rule, paid by the audited entity. The audit is not just a compliance event; it is a line item.

A workable evidence map, one row per Article 21(2) category:

1. Policy artifact. The signed, dated, version-controlled policy for the category.
2. Implementation evidence. Configuration exports, ticket history, training completion records, test results — the proof the policy is live, not shelfware.
3. Effectiveness evidence. The output of category (f): the assessment that says this measure actually works, with a date.
4. Proportionality rationale. The risk-assessment entry that justifies the depth you chose against your exposure, size, and incident likelihood.

If you cannot produce all four rows for a category, that category is your weakest exhibit in an audit. Build the missing rows before the authority builds them for you. This is what continuous audit readiness means in NIS2 terms — the audit pack is a query, not a project.

One more grounding point on accountability: Article 20 puts the management body on the hook. Management bodies must approve the Article 21 measures, oversee their implementation, and can be held liable for infringements. Article 20(2) also requires members of the management body to follow cybersecurity training. So "board sign-off on the risk-management measures" and "evidence the board was trained" are themselves Article 21-adjacent evidence items.

How do the Article 23 reporting timelines (24h / 72h / 1-month) tie back to your incident-handling controls?

Category (b) — incident handling — does not live in isolation. It has to feed the Article 23 reporting machine, and that machine runs on a clock.

First, the trigger. Article 23(1) requires notification of any incident with a "significant impact." Article 23(3) defines significant: an incident is significant if it "has caused or is capable of causing severe operational disruption of the services or financial loss," or "has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage." The "capable of causing" language means you assess severity on potential, not just realised, impact.

The clock, from Article 23(4), measured from when you became aware of the significant incident:

1. Within 24 hours — an early warning, indicating where applicable whether the incident is suspected to be caused by unlawful or malicious acts, or could have cross-border impact.
2. Within 72 hours — an incident notification updating the early warning, with an initial assessment of severity and impact and, where available, indicators of compromise.
3. On request — an intermediate report on relevant status updates, if the CSIRT or competent authority asks.
4. Within one month of the 72-hour notification — a final report: detailed description and impact, the type of threat or root cause, applied and ongoing mitigation measures, and any cross-border impact.

If the incident is still ongoing when the one-month final report is due, Article 23(4)(e) requires a progress report at that point and a final report within one month of the incident being handled. There is also a derogation: trust service providers must submit their notification within 24 hours, not 72, for incidents affecting their trust services.

Now map that back to your incident-handling control. The 24-hour early warning is brutal for teams whose triage process is built around root-cause certainty. You will not have root cause in 24 hours. The directive does not ask for it — the early warning is a flag, the 72-hour notification is the initial assessment, the one-month report is the analysis. Build your runbook in those three gears.

What breaks here: the most common failure mode is a severity-classification step that lives in the analyst's head instead of in the runbook. If "is this significant under Article 23(3)" is a judgement call made on the fly during an incident, you will either over-report and exhaust your authority relationship, or under-report and miss the 24-hour window. Encode the significant-impact test as a decision step in the runbook, with the "capable of causing" language baked in, and rehearse it. The clock starts at awareness, and awareness is logged.

What does supply-chain security under Article 21(2)(d) and 21(3) require beyond a vendor questionnaire?

Category (d) is the one most likely to be under-built, because most teams already have a vendor questionnaire and assume it covers them. The text says otherwise.

Article 21(2)(d) names "security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Note "direct" — the obligation is scoped to your direct suppliers, not an infinite Nth-party chain, but it is about the relationship, not just the vendor's self-attestation.

Article 21(3) is where the depth gets specified. When deciding which supply-chain measures are appropriate, entities must take into account "the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures." That is three distinct inputs:

1. Vulnerabilities specific to each direct supplier — per-supplier, not a generic tier.
2. The overall quality of their products and cybersecurity practices.
3. Their secure development procedures.

A questionnaire that returns a yes/no on "do you have a security program" does not surface supplier-specific vulnerabilities or interrogate secure development. The article pushes you toward supplier-specific risk assessment and product-quality evaluation.

Article 21(3) adds one more input you do not control: entities are required to take into account "the results of the coordinated security risk assessments of critical supply chains carried out in accordance with Article 22(1)." Article 22 lets the Cooperation Group, with the Commission and ENISA, run Union-level coordinated risk assessments of specific critical ICT services, systems, or products. When one of those assessments lands and touches a product in your stack, it becomes an input you are obligated to factor in. Put a watch on it.

How do you map the Article 21 baseline to controls you already run for ISO 27001 or DORA?

You almost certainly already run most of these measures under another framework. The work is mapping, not building from zero.

The ten Article 21(2) categories overlap heavily with ISO 27001:2022 — its Annex A includes controls covering access control, cryptography, supplier relationships, incident management, business continuity, and asset management, which line up against categories (i), (h), (d), (b), (c), and (i) respectively. NIS2 itself signals the connection: Article 21(1) tells you to take "relevant European and international standards" into account when sizing measures.

The overlap with DORA's ICT risk-management chapter is also substantial for financial entities, and the directive anticipates the seam — Article 32(10) requires NIS2 competent authorities to coordinate with the DORA authorities, including where an essential entity is a designated critical ICT third-party service provider.

A practical mapping sequence:

1. Lay the ten categories down as the rows. They are your NIS2 control floor.
2. Map each existing control to the category it satisfies. Where an ISO 27001 control or a DORA measure already covers a category, reference it. Do not duplicate the work.
3. Flag the gaps. Category (f), measure-effectiveness assessment, is the one teams most often find uncovered, because most frameworks ask you to have controls but fewer ask you to prove your controls work.
4. Attach the proportionality rationale per row. This is the NIS2-specific artifact even a mature ISO shop will not have lying around.
5. Re-use evidence, do not re-collect it. Where one piece of evidence satisfies an ISO control and an Article 21 category, reference it once. The reviewer's job becomes review-and-confirm, not collect-everything.

The structural point: NIS2 Article 21 is not a new pile of work if your control framework already binds to obligations. The trap is treating it as a separate silo, re-running assessments you already passed, and ending up with three disagreeing evidence stores. Answer once, satisfy many.

This is exactly the mapping problem Aegis GRC is built to resolve. Map your NIS2 Article 21 baseline against the obligations that actually apply to your entity — with every obligation traced to a verbatim quote from the source legal text — at aegis-grc.com. The same answers feed your risk management register and your audit readiness pack, source-grounded, no AI hallucinations.

FAQ: NIS2 Article 21 baseline, evidence, and authority checks

Does NIS2 Article 21 give a specific control list like ISO 27001 Annex A? No. Article 21(2) sets out ten measure categories and says measures "shall include at least" those categories, based on an all-hazards approach. It does not enumerate granular controls. The Commission may adopt implementing acts laying down technical and methodological requirements for certain entity types under Article 21(5), but the article itself is category-level, not control-level.

Do essential and important entities have the same Article 21 obligations? Yes for the control baseline. Article 21 applies to both essential and important entities with the same ten-category floor. The difference between the tiers shows up in the supervision regime, not in the substantive risk-management measures.

What does "appropriate and proportionate" actually mean in practice? Article 21(1) defines the proportionality test: due account must be taken of the entity's degree of exposure to risk, its size, and the likelihood and severity of incidents, including societal and economic impact, alongside state-of-the-art and cost of implementation. In practice it means a documented risk assessment that justifies the depth of each measure against those factors.

What are the NIS2 incident-reporting deadlines under Article 23? From awareness of a significant incident: an early warning within 24 hours, an incident notification within 72 hours, an intermediate report on request, and a final report within one month of the 72-hour notification. Trust service providers must submit their notification within 24 hours rather than 72.

What evidence can a competent authority demand? Under Article 32(2), authorities can require on-site inspections, regular and ad hoc security audits, documented cybersecurity policies, and evidence of implementation including the results of security audits by a qualified auditor and the underlying evidence. Article 20 adds that the management body must approve the measures and is required to undergo cybersecurity training.