NIS-2

NIS2 requirements: the ten Article 21 measures, and what each one needs

By Alessandro Stella · 25 May 2026 · 26 min read · Updated 16 August 2026

The NIS2 requirements that an inspection actually examines are set out in Article 21 of Directive (EU) 2022/2555. Article 20 makes the management body accountable and Article 23 sets the reporting clock, but Article 21 is the operational core: ten risk-management measures every essential and important entity must implement, document and be able to prove are operating.

The measures are deliberately technology-neutral. The directive tells you what to achieve, not what to buy — which sounds permissive and is unforgiving in practice. There is no list of approved products that constitutes compliance, and a vendor claiming their tool “covers Article 21” is saying nothing without the policy framework, the operational evidence and the management body approval that surround it.

This article walks through all ten: what each requires, what evidence gets asked for, where Commission Implementing Regulation (EU) 2024/2690 adds binding specificity, and what the common findings look like. It ends with the two things that decide how hard any of it is enforced — proportionality and your national transposition.

In a hurry? The free NIS-2 gap assessment asks one question per obligation and scores you measure by measure — about ten minutes, and it tells you which of the ten you could evidence today. If you would rather start from a written set, the NIS-2 Compliance Suite covers all ten in thirteen procedures. €590 excl. VAT.

What Article 20 requires of the management body

Article 20 is short — two paragraphs — and it is the article that decides who answers for the other ten measures.

Paragraph 1 gives the management body three duties, not one: approve the risk-management measures adopted under Article 21, oversee their implementation, and — the part boards most often underestimate — can be held liable for infringements of Article 21 by the entity. Approval is a decision at a point in time. Oversight is ongoing. Liability is what turns the first two from good governance into personal exposure.

None of the three can be delegated away. A CISO can prepare the measures, run the risk assessment, and manage the programme day to day. The management body still has to approve what is adopted and stay informed enough to oversee it — a board that has never seen the risk register cannot credibly claim to have overseen anything.

Paragraph 2 adds a training duty aimed at the management body itself: members are required to undergo training sufficient to identify cybersecurity risks and assess risk-management practices and their impact on the entity’s services. The directive separately encourages, but does not require, entities to offer similar training to staff more broadly. The obligation on the board is the one with no exception.

Evidence to have ready:

minutes recording the management body’s approval of the risk-management measures, dated and specific — “the board approved the information security policy” is weaker than “the board approved v2.3 of the policy, reviewed the risk register, and requested remediation of three open items”
a documented oversight mechanism: the management review records under measure 6, with evidence the board attended and asked questions, not just received a slide deck
individual training records for every management body member, not a department-wide completion rate
for essential entities, awareness that Article 32(5) lets authorities temporarily suspend a manager from exercising managerial functions where non-compliance persists — the ceiling above the ten million euro fine, not an alternative to it

The public-sector carve-out is narrow and easy to misread: Article 20(1)‘s liability clause applies without prejudice to national law on the liability of public institutions and public servants. It exempts the liability mechanism for certain public bodies, not the approval and oversight duties themselves, which still apply in full.

The gap this closes in practice: an organisation can implement all ten Article 21 measures well and still fail Article 20, if the only evidence of board involvement is that someone in IT sent a summary email. What the article requires is a board that can point to what it approved, when, and what it has asked about since.

Three principles that shape every choice

Before the list, three principles from Article 21(1) govern how you implement all of it.

The first is proportionality. The depth of your controls should match your risk exposure, your size and the severity of what an incident would cause — a sixty-person manufacturer is not held to the control depth of a transmission system operator. But proportionality calibrates effort, it does not authorise absence. Both organisations must address all ten measures; only the depth differs.

The second is the all-hazards approach. Article 21(2) requires protection from hazards of any origin, which includes technical failure, human error and environmental events alongside deliberate attacks. Backups stored only in the same data centre as production are not a defensible all-hazards control, however well encrypted.

The third is that evidence beats intent, and Article 21(2)(f) makes this explicit by requiring you to assess the effectiveness of your own measures. A policy that is written but not followed, monitored or reviewed is not a control — it is a document, and the difference is visible within minutes of an auditor arriving.

One more thing shapes what follows. For digital infrastructure and digital provider entities — DNS providers, TLD registries, cloud computing providers, data centres, CDN providers, MSPs, MSSPs, online marketplaces, search engines, social networks and trust service providers — Commission Implementing Regulation (EU) 2024/2690 translates Article 21 into binding technical detail across thirteen sections. It applies directly and identically across the Union, with no national transposition. For other sectors it is not binding, but national authorities increasingly treat it as the interpretive baseline for what “appropriate and proportionate” means.

Four domains, not ten items

The ten Article 21 measures grouped into four functional domains The ten measures in implementation order rather than regulatory order.

Article 21(2) lists the measures in regulatory order, which is not the order you would implement them in. For planning purposes it helps to group them into four domains: governance and risk (measures 1 and 6), operational resilience (2 and 3), supply chain and lifecycle (4 and 5), and the technical and human controls people experience daily (7 through 10).

The grouping is unofficial, but it matches how mature programmes structure the work — and it explains why starting anywhere other than governance tends to produce documents nobody uses.

How the ten measures map to the Implementing Regulation

Mapping between the ten Article 21 measures and the thirteen sections of the Implementing Regulation Annex Ten letters, thirteen sections. The correspondence is not one to one, and the places where it breaks are the informative ones.

The Annex to Implementing Regulation (EU) 2024/2690 is titled technical and methodological requirements, and it contains thirteen numbered sections. They do not line up one for one with the ten letters of Article 21(2), and the mismatches tell you where the Commission thought the directive was too compressed.

Measure (a) becomes two sections — the security policy in section 1 and risk management in section 2 — separating the governance statement from the process that feeds it. Measure (b) becomes section 3, with monitoring and logging as a distinct sub-section rather than an assumption. Measure (c) stays whole in section 4, covering the continuity and disaster recovery plan, backup and redundancy, and crisis management together. Measures (d), (e), (f) and (g) map cleanly onto sections 5 through 8.

The interesting split is measure (i). What the directive states in a single clause — human resources security, access control policies and asset management — becomes three separate sections: 10, 11 and 12. That is a signal about weighting. Access control alone carries sub-requirements on rights management, privileged accounts, administration systems, unique identification, authentication and multi-factor authentication, which is where measure (j) is operationalised for the entities the regulation binds.

Section 9 covers cryptography, matching measure (h). Section 13 covers physical and environmental security, which the directive reaches through the all-hazards principle rather than a dedicated letter — a reminder that Article 21 is a floor rather than a ceiling.

If you are directly bound by the regulation, that Annex is your specification and this article is a map of it. If you are not, it remains the most detailed official statement in existence of what these obligations mean, which is why supervisory authorities reach for it.

Measure 1 — Risk analysis and security policies

Article 21(2)(a) requires policies on risk analysis and information system security. In practice that means a documented methodology, an information security policy approved by the management body, and a risk register connecting identified risks to mitigation actions, owners and review dates.

The methodology has to be defensible rather than fashionable. ISO/IEC 27005 is the most common baseline, but any structured approach producing consistent, repeatable results will hold — what will not hold is generic boilerplate that has clearly never been adapted to your actual risk profile.

Evidence to have ready:

risk assessment methodology, approved and versioned
current risk register with owner, likelihood, impact, residual risk and review date per item
information security policy signed by the management body
records of periodic review, at least annually and on significant change
risk treatment plan with named owners and timelines

What comes up at audit is almost always the same: a register nobody has touched in eighteen months, a methodology that could belong to any company, risks identified with no treatment plan behind them, or a treatment plan with no evidence anyone executed it.

In the Implementing Regulation this measure occupies two sections. Section 1 requires the policy to be approved by the management body explicitly, to set objectives and assign roles, and to be reviewed on a defined cycle. Section 2 requires the risk management framework itself — the methodology, the treatment plan, and documented acceptance of residual risk by someone with the authority to accept it.

Measure 2 — Incident handling

Article 21(2)(b) requires incident handling — detection, analysis, containment, eradication, recovery and post-incident review. This measure has to be read alongside Article 23, because what you do internally must produce the data you are obliged to report externally within 24 hours, 72 hours and one month.

That connection is where most plans fail. A response process designed only around technical recovery does not surface the facts the early warning needs, and by the time someone thinks about notification the clock has been running for most of a day.

Evidence to have ready:

incident response plan covering roles, escalation, containment, eradication, recovery and review
detection capability proportionate to your risk profile
severity classification with named decision-makers
incident register with classification, timeline, root cause and lessons learned
exercise records showing the plan has been tested
mapping from your internal classification to the Article 23 reporting thresholds

The findings here are predictable. A plan exists but no detection capability supports it. Severity classification is defined and never used. The incident register is empty — not because nothing happened, but because nothing was recorded, which invites much harder questions about detection. Or the plan has simply never been exercised.

Section 3 of the Annex is unusually specific for the entities it binds, and its monitoring and logging sub-section is the part most organisations underestimate: what is logged, how logs are protected from tampering, how long they are kept, and how anomalies are actually reviewed rather than merely collected.

Our guide to building an incident response plan that survives the 24-hour clock covers the notification workflow in detail.

Measure 3 — Business continuity and crisis management

Article 21(2)(c) requires business continuity, including backup management and disaster recovery, and crisis management. In practice: a business impact analysis identifying critical services and their recovery requirements, documented continuity and recovery plans, backup procedures with tested restore, and a crisis capability that activates when an incident exceeds normal operational handling.

The word doing the work in that sentence is “tested”. A backup job that completes successfully proves data was written; it proves nothing about whether it can be read back, or how long that takes.

Evidence to have ready:

business impact analysis with named critical services, RTO and RPO
business continuity plan and disaster recovery plan
backup policy covering scope, frequency, retention, encryption and geographic separation
restore test records — not “we have backups” but “we restored X on date Y in Z hours, here is the report”
crisis management plan with activation criteria, decision authority and communication procedures
exercise records, at least annually

Proportionality has real bite here. A small important entity is not expected to run a fully redundant alternate site. It is expected to have a credible answer to what happens if its primary IT environment is gone for a week, including who decides, who communicates and how the business operates in the meantime.

Section 4 of the Annex requires the plans to rest on a business impact analysis, and requires both the plans and the recovery of backup copies to be tested at planned intervals and after significant incidents or significant changes, with the lessons learnt folded back in. We cover the two documents separately in what makes a business continuity plan work and the disaster recovery plan as a runbook.

Measure 4 — Supply chain security

Article 21(2)(d) requires security in the relationships with direct suppliers and service providers, and Article 21(3) adds that you must take into account the specific vulnerabilities of each supplier and the overall quality of their products and security practices, including their secure development procedures.

This is consistently the hardest measure to evidence, because it requires reaching beyond the perimeter you control — and it is the one auditors know is likely to surface gaps, so it gets looked at early.

Evidence to have ready:

supplier security policy
supplier inventory with risk classification
risk assessment for each critical supplier: questionnaire, certifications, audit reports
contractual security clauses, and evidence they are in your critical supplier contracts
monitoring procedure covering disclosures, breach notifications and certification renewals
records of supplier reviews

The findings: suppliers identified but never classified by risk, questionnaires sent and never read, contractual clauses that exist as a template but appear in none of the contracts that were signed before the template was written, and “monitoring” that turns out to mean trusting the supplier.

One practical check worth doing today: look at what notification deadline your critical suppliers owe you when they have an incident. If it is longer than your own 24 hours, your deadline is already spent before you hear about it.

Measure 5 — Acquisition, development and maintenance

Article 21(2)(e) covers security in acquisition, development and maintenance, including vulnerability handling and disclosure. For an entity that builds software this means a secure development lifecycle; for everyone it means a vulnerability management programme, a patch procedure with actual timeframes, and a route for outsiders to report a vulnerability to you.

“As soon as possible” is not a remediation timeframe. Severity-based windows with numbers in them are, and they are what gets measured.

Evidence to have ready:

secure development policy where applicable: threat modelling, secure coding, testing, code review
vulnerability management procedure with scanning frequency, severity classification and remediation windows
patch procedure differentiating critical, high, medium and low with maximum windows
scan reports and evidence of remediation
coordinated vulnerability disclosure policy and contact channel
penetration testing or security assessment records at a defined frequency

The Annex is particularly detailed here for digital infrastructure providers, requiring security testing integrated into the development lifecycle, secure handling of test data, and a mix of techniques — penetration testing, static and dynamic analysis, manual review — at different stages.

Measure 6 — Assessing effectiveness

Article 21(2)(f) requires policies and procedures to assess the effectiveness of your cybersecurity risk-management measures. Internal audit, indicators, management review. This is the measure that turns a documentation set into an operating system, and it is the one most often forgotten because it produces no obvious deliverable.

It is also where Article 20 accountability becomes visible in practice. The management review is the moment the management body sees the evidence, asks questions and approves direction — without it, “the board approved the measures” is an assertion with nothing behind it.

Evidence to have ready:

internal audit programme with an annual schedule
audit reports covering the ten measures across a defined cycle
an indicator set actually being tracked: incidents, patch compliance, training completion, supplier review status
management review minutes with documented decisions, at least annually
corrective action register tracked to closure

The failures: an internal audit performed once and never repeated, indicators defined and never reviewed, a management review held without minutes, corrective actions opened and never closed.

Worth understanding structurally: this measure is what makes the other nine auditable over time. Implemented last and scoped early is the pattern that works, because the indicators you choose determine what the other nine measures have to produce.

Measure 7 — Cyber hygiene and training

Article 21(2)(g) requires basic cyber hygiene practices and cybersecurity training. Acceptable use, credential management, mobile devices, phishing awareness, and recurring training with completion records — for everyone, contractors included, since contractors are the population most often missed and the first anyone asks about.

Article 20(2) separately requires training for the management body itself, and that obligation attaches to them personally.

Evidence to have ready:

acceptable use policy with acknowledgement records
password policy aligned to current guidance
mobile device or BYOD policy
phishing simulation programme with results tracked over time
training plan covering all staff, with role-specific modules where relevant
completion records: who, what, when, and the refresh frequency
separate evidence of management body training

Common findings: training delivered at onboarding and never refreshed, phishing simulations run once as compliance theatre, a management body that has never completed any training, and password policies still enforcing ninety-day rotation against current guidance.

Measure 8 — Cryptography

Article 21(2)(h) requires policies on the use of cryptography and, where appropriate, encryption. “Where appropriate” is not “optional” — it means scoped to where it reduces real risk, and sensitive personal data, authentication credentials and anything crossing an untrusted network are appropriate by default.

Evidence to have ready:

cryptography policy specifying approved algorithms, key lengths and protocols
key management procedure covering generation, storage, rotation and destruction
inventory of where encryption is applied
TLS configuration evidence for public-facing services
records of cryptographic reviews: algorithm deprecation, certificate expiry monitoring

The findings tend to be quiet ones: a policy still referencing obsolete algorithms, keys generated once and never rotated, no inventory distinguishing encrypted from unencrypted data, certificates expiring without anyone watching.

Section 9 of the Annex adds the requirement that algorithm and key strength be appropriate to the sensitivity of the data, and that the choices be reviewed against current practice — which is the mechanism by which an ageing policy becomes a finding rather than merely an oversight. Mature programmes now also carry at least an awareness statement on post-quantum migration, even where implementation is years away.

Measure 9 — HR security, access control and asset management

Article 21(2)(i) covers three intertwined controls — the employee lifecycle, who can access what under which conditions, and the asset inventory that makes the other two possible. The Implementing Regulation gives each of the three its own section, which is a reasonable indication of how much weight they carry.

Evidence to have ready:

HR security procedures: background checks where lawful, onboarding, role changes, offboarding with access revocation
access control policy built on role-based access and least privilege
privileged access management for administrative accounts
access review records showing periodic recertification
asset inventory covering hardware, software, data and services, with owner and classification
joiner-mover-leaver records showing access changes track HR events

The single most common finding across this entire measure is the gap between HR records and access records: someone left three months ago according to HR and their account is still active. Reconciling those two registers is unglamorous and produces more risk reduction per hour than almost anything else on this page.

Our guide to writing an access control policy that covers what most templates leave out goes into the revocation checklist and the service account problem in detail.

Measure 10 — MFA and secure communications

Article 21(2)(j) requires multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communication systems, where appropriate.

At minimum that means MFA on remote access, on privileged accounts and on email. And it means an emergency communication channel that works when the primary one is compromised — because the primary channel will be exactly the one the incident is about.

Evidence to have ready:

MFA policy specifying scope and approved factors
technical evidence of enforcement: logs, configuration, identity provider policies
coverage report by account category
secure communication policy where applicable
documented out-of-band emergency procedure with tested contact lists
records of emergency communication tests

Findings: MFA enabled on the corporate identity provider but not on the legacy systems beside it, SMS codes still protecting privileged access, emergency contact lists eighteen months out of date, and emergency procedures that quietly assume corporate email will be working.

For entities bound by the Implementing Regulation, multi-factor or continuous authentication for remote access and for access to critical systems sits inside the access control section as a requirement rather than a suggestion — the “where appropriate” qualifier of the directive does not survive into the technical specification.

How proportionality actually works

What proportionality can and cannot reduce under NIS2 Proportionality scales the depth of a measure. It never reduces one to nothing, and the reasoning has to be written down.

Proportionality is the most invoked and least evidenced concept in NIS-2 practice. Article 21(1) states the factors: the entity’s exposure to risk, its size, the likelihood of incidents occurring and their severity, including societal and economic impact. Those are the variables you are allowed to reason with — not budget, not convenience, not the fact that nobody has asked yet.

What proportionality genuinely scales is depth. The number of pages in a policy, the frequency of testing, whether privileged access management is a platform or a controlled spreadsheet, whether the recovery site is warm or is a documented rebuild procedure. A twenty-person entity and a two-thousand-person entity can both be compliant with visibly different implementations of the same measure.

What it does not do is remove a measure. There is no size at which incident handling, backup testing, supplier requirements or management body accountability disappear. They shrink in scope, not in existence — and an entity that has decided a whole measure is not applicable has made a decision the directive does not offer.

The part almost everyone skips is recording the reasoning. Where you have implemented something lightly, or decided a “where appropriate” element does not apply, the justification has to exist in a form a competent authority can read. “We are small” is not that. A short written rationale referencing your size, your operating model and the specific risk assessment finding that supports the decision — plus any compensating control — is, and it takes ten minutes per decision to write while the reasoning is fresh.

Do this at the moment of the decision, not at the moment of the inspection. Reconstructed justifications read exactly like what they are.

What your national transposition adds

The directive is not directly applicable law. It reaches you through your Member State’s transposition, and that is where three things get decided that the directive leaves open.

The first is registration: who has to register with the national authority, by when, and through which portal. Deadlines and mechanics vary, and missing registration is the one failure that is visible without any inspection at all.

The second is supervision. Essential entities are subject to both proactive and reactive supervision — authorities may inspect without a triggering incident. Important entities are subject to supervision after the fact, when something has gone wrong or evidence suggests non-compliance. Which category you fall into changes not what you must do, but how likely you are to be asked to prove it, and how much notice you get.

The third is enforcement. Maximum administrative fines are set at at least €10 million or 2% of total worldwide annual turnover for essential entities, whichever is higher, and at least €7 million or 1.4% for important entities. National law may go further, and several Member States have attached management liability provisions of their own.

The practical implication for a multi-country group: build one control framework to the directive and the Implementing Regulation, then map it to each national transposition rather than maintaining separate systems. The technical substance barely varies. Registration, reporting channels and deadlines do.

What gets examined first

The three evidence areas an inspection examines before anything else Governance, incidents and supply chain. Strong here and proportionate elsewhere is a defensible position.

Three patterns recur in what regulators and external auditors look at before anything else.

Governance evidence comes first: management body approval records, training records, risk acceptance decisions. It is the fastest way to establish whether an organisation is operating Article 21 or merely hosting it.

Incident response evidence comes second — the register, the exercise records, the mapping to Article 23 thresholds. An organisation that cannot show incidents, whether because none occurred or because none were recorded, gets pushed considerably harder on detection.

Supply chain evidence comes third, and it is the one most likely to surface significant gaps.

Strong on these three and proportionate elsewhere is a defensible position. Weak on these three, and the rest is unlikely to compensate.

One record per measure

The single record that most reliably evidences each of the ten measures If you can produce these ten on request, you are in better shape than most entities of your size.

Documents state intent; records prove operation. For each of the ten measures there is one record that carries most of the evidential weight, and assembling those ten is a faster route to readiness than writing another policy.

The pattern to notice is that nine of the ten are dated artefacts produced by doing something — a review, a test, an exercise, a reconciliation. Only the Statement-of-intent documents can be written in advance, which is why an organisation that has spent six months writing and none operating is further from compliance than it feels.

Four things to do this week

If the full picture is more than you can take on right now, these four give the most back for the least effort.

Start by reconciling your HR leaver list against active accounts. It is usually an uncomfortable morning and the fastest risk reduction available.

Then check what incident notification deadline your critical suppliers owe you. If it exceeds your own 24 hours, that is a contractual conversation, not a technical one.

Third, find out when your last restore test was, and if the answer is “we have backups” rather than a date and a duration, schedule one.

Finally, confirm whether every member of your management body has completed training, individually and on the record. It is the obligation that attaches to them personally, and the easiest to have quietly skipped.

Frequently asked questions

What are the NIS2 requirements for companies? Ten risk-management measures under Article 21(2), each implemented, documented and evidenced: risk and security policies, incident handling, business continuity and crisis management, supply chain security, secure acquisition and development, effectiveness assessment, cyber hygiene and training, cryptography, HR security with access control and asset management, and multi-factor authentication with secure communications. Alongside these sit the Article 20 duties of the management body and the Article 23 reporting deadlines.

Do all ten measures apply to every entity? Yes. Proportionality governs the depth of each measure, not whether you address it. A small important entity may have a two-page cryptography policy where a large essential entity has ten, but both must exist.

Is Commission Implementing Regulation (EU) 2024/2690 binding on us? Directly, only if you are one of the eleven digital infrastructure and digital provider entity types it names. For everyone else it is not binding, but national authorities increasingly use it as the reference for what “appropriate and proportionate” means.

How do the ten measures map to the thirteen Annex sections? Not one to one. Measure (a) splits into the security policy and risk management sections, measure (i) splits into human resources security, access control and asset management, and physical and environmental security gets a section of its own that has no dedicated letter in the directive.

Does ISO 27001 cover Article 21? It covers a large share of it. The consistent gaps are supply chain depth under Article 21(3), management body accountability under Article 20, the Article 23 reporting deadlines and the explicit MFA expectation. ISO 27001 is one way to demonstrate compliance, not a legal substitute.

How many documents does Article 21 actually require? The directive does not count documents. What it requires is that every measure maps to something that exists, has an owner, produces a record and gets reviewed. That can be thirty documents or eighty — the number is not the point, the mapping is.

What happens if we do not comply? Essential entities face maximum fines of at least €10 million or 2% of worldwide annual turnover, whichever is higher; important entities at least €7 million or 1.4%. Authorities can also impose binding instructions, order audits, and in the most serious cases suspend management functions. Essential entities are supervised proactively; important entities after the fact.

Where to go next

The free NIS-2 gap assessment asks twelve questions, one per obligation, and scores you measure by measure. It takes about ten minutes and produces the list of what you could not evidence today.

If you would rather start from a complete written set, the NIS-2 Compliance Suite covers all ten measures in thirteen procedures — one per process, each opening with a table mapping every obligation to the step that discharges it, the role accountable and the record it produces. €590 excl. VAT.

You may also want to read who must comply with NIS-2 if you are still confirming scope.

Sources

Directive (EU) 2022/2555 and Commission Implementing Regulation (EU) 2024/2690 are available on EUR-Lex. ENISA’s Technical Implementation Guidance maps the Implementing Regulation Annex to practical measures with evidence examples.