Article 21: Cybersecurity risk-management measures

Article 21: cybersecurity risk-management measures requirement means you must run a documented, risk-based cybersecurity program with technical, operational, and organizational controls that are proportionate to your risk, and that reduce both the likelihood and impact of incidents on your services. Operationalize it by mapping obligations to control owners, proving controls work in practice, and keeping audit-ready evidence. (Directive (EU) 2022/2555, Article 21)

Key takeaways:

• Treat Article 21 as an “evidence-first” requirement: supervisors will test operating effectiveness, not policy intent. (Directive (EU) 2022/2555, Article 21)
• Build a single obligation-to-controls register with jurisdiction notes, owners, and milestones to prevent scope drift across EU Member States. (Directive (EU) 2022/2555, Article 21)
• Make incident handling and third-party dependency risk demonstrable through repeatable workflows and retained records. (Directive (EU) 2022/2555, Article 21)

If you’re an essential or important entity under NIS 2, Article 21 is the backbone requirement that turns “cybersecurity” into a managed, auditable set of measures. It obligates you to take “appropriate and proportionate technical, operational and organisational measures” to manage risks to the network and information systems you use to operate or deliver services, and to prevent or minimize incident impact on your service recipients and connected services. (Directive (EU) 2022/2555, Article 21)

For a CCO or GRC lead, the fastest path is to stop thinking in terms of one policy and start thinking in terms of: (1) clear scope, (2) accountable ownership, (3) a control set that matches real risk, and (4) proof. Article 21 is drafted at a principles level, but it becomes enforceable through national transposition and supervision. That reality creates a common failure mode: teams “implement NIS 2” once, centrally, then cannot show how obligations translate into local operating requirements and evidence across jurisdictions. (Directive (EU) 2022/2555, Article 21)

This page gives requirement-level implementation guidance focused on operationalization: what to do, who needs to be involved, what artifacts to keep, and how to prepare for supervisory scrutiny.

Regulatory text

Operative requirement (excerpt): Member States must ensure essential and important entities take “appropriate and proportionate technical, operational and organisational measures” to manage risks to the security of network and information systems used for operations or service delivery, and to prevent or minimize incident impact on service recipients and other services. (Directive (EU) 2022/2555, Article 21)

Operator interpretation (what you must do):

1. Run a risk-management system for cybersecurity, not a one-time compliance project. Your program must cover technical controls (security tooling and configurations), operational controls (processes such as monitoring and incident response), and organizational controls (governance, roles, and accountability). (Directive (EU) 2022/2555, Article 21)
2. Proportionate measures are mandatory. You must be able to explain why your control design matches your risk profile and service criticality. “We’re too small” is not a control rationale; “we’re smaller, so we scoped to these assets and these controls based on service impact and dependency mapping” is. (Directive (EU) 2022/2555, Article 21)
3. Impact minimization is part of compliance. Resilience, containment, and recovery are in-scope because the requirement explicitly targets minimizing impact on recipients and other services. (Directive (EU) 2022/2555, Article 21)

Plain-English interpretation of the requirement

Article 21 requires you to:

• Know what you run (systems and services that matter).
• Know what can go wrong (risk assessment grounded in real dependencies, including third parties).
• Put safeguards in place (technical + process + governance measures).
• Detect and respond quickly (so incidents don’t cascade).
• Prove it (retain evidence that controls exist and operate). (Directive (EU) 2022/2555, Article 21)

A practical way to phrase the exam standard: can you show, with artifacts, that your cybersecurity program reduces risk to the systems that deliver your regulated services?

Who it applies to (entity and operational context)

Entities: Essential entities and important entities in scope of NIS 2, as determined by NIS 2 sector and size criteria and each Member State’s transposition approach. (Directive (EU) 2022/2555)

Operational context (what parts of the business are in-scope):

• Network and information systems used to operate the business or provide services.
• Dependencies that can affect service delivery, including critical third parties (cloud, managed service providers, telecom, payment processors, identity providers, hosting, and key software/SaaS). (Directive (EU) 2022/2555, Article 21)

Practical scoping rule: if an outage, compromise, or integrity failure in a system would materially affect customers/recipients or knock on to other services, treat it as in-scope and document why. (Directive (EU) 2022/2555, Article 21)

What you actually need to do (step-by-step)

1) Stand up an Article 21 obligation-to-controls register (your control spine)

Create a single register that ties Article 21 to your internal controls and evidence. Include:

• In-scope entities, countries, and regulators (jurisdiction notes matter because implementation is supervised nationally). (Directive (EU) 2022/2555)
• Control owners (RACI), implementation status, and testing cadence.
• Evidence pointers (where screenshots, tickets, logs, and reports live).
• Remediation tracking for gaps.

This register prevents the most common operational failure: distributed teams “doing security,” but nobody can prove requirement coverage end-to-end.

Daydream fit: Daydream can act as the system of record for the obligation register, owners, milestones, and evidence links, so you can answer supervisory questions without rebuilding the story each time.

2) Define “appropriate and proportionate” for your organization

Write a short proportionality rationale that you can defend:

• Business services and criticality categories (what must stay up).
• Crown-jewel systems and sensitive data paths.
• Threat assumptions relevant to your environment (keep this qualitative if you lack mature threat intel).
• Dependency map for critical third parties and key subcontractors. (Directive (EU) 2022/2555, Article 21)

The output is not a glossy risk report. It is a defensible explanation of why your chosen control depth matches your risk.

3) Implement the minimum operable set of measures across three control planes

Organize work so it matches the text: technical, operational, organizational. (Directive (EU) 2022/2555, Article 21)

A. Technical measures (examples of what auditors expect to see evidence for)

• Secure configuration baselines for endpoints, servers, network devices, and cloud workloads.
• Identity and access controls for privileged access; joiners/movers/leavers discipline.
• Vulnerability and patch management with exception handling.
• Backup protections and recovery capability aligned to critical services.

B. Operational measures

• Centralized logging/monitoring appropriate to critical systems.
• Incident triage and escalation workflows with clear severity definitions.
• Change management for production-impacting systems, including emergency changes.

C. Organizational measures

• Named accountability for cybersecurity risk decisions.
• Documented policies and standards mapped to controls.
• Internal assurance: control testing and remediation governance.

You do not need “every control.” You need a coherent set that covers the risks of the systems you rely on and that you can show operates in practice. (Directive (EU) 2022/2555, Article 21)

4) Make incident handling provable (not aspirational)

A recurring supervisory hangup is incident readiness that exists only in a policy binder. Build an incident package that includes:

• Triage decision tree (what constitutes an incident, what constitutes escalation).
• Roles: incident commander, comms lead, legal/privacy touchpoints, IT ops, third-party manager.
• Evidence retention steps: what to preserve, where, and who approves access.
• Tabletop exercises and lessons-learned action tracking.

Maintain records showing the workflow has been executed: tickets, timelines, communications approvals, and post-incident reports. (Directive (EU) 2022/2555, Article 21)

5) Pull critical third-party dependencies into the risk-management system

Article 21 is risk-management for systems you use to deliver services; in practice, third parties often run those systems.

Minimum operational expectations:

• Inventory critical third parties tied to in-scope services.
• For each critical third party, document: service dependency, data access, connectivity model, and failure modes.
• Build assurance activities into your cadence: due diligence, contractual security requirements, and issue management.
• Track third-party security events as part of your incident workflow. (Directive (EU) 2022/2555, Article 21)

6) Validate operating effectiveness and fix what fails

Supervisors will press for proof that controls work.

• Define test procedures for key controls (access reviews, restore tests, vulnerability remediation checks).
• Capture outcomes and exceptions.
• Push exceptions into a remediation queue with owners and due dates.

This is where many teams fall down: controls exist, but no consistent test evidence exists.

Required evidence and artifacts to retain

Use this as an audit-request checklist:

Governance and scoping

• NIS 2 applicability assessment and in-scope entity list. (Directive (EU) 2022/2555)
• Article 21 obligation-to-controls register with owners and milestones. (Directive (EU) 2022/2555, Article 21)
• Proportionality rationale (services, crown jewels, dependency map). (Directive (EU) 2022/2555, Article 21)

Risk management

• Cyber risk assessment methodology and latest cycle results.
• Risk register entries tied to systems/services and treatment plans.

Control design and operation

• Policies/standards (access control, logging, vulnerability management, backup, change management).
• Control operation evidence: access review exports, ticket samples, patch reports, SIEM alerts, backup job reports, restore test records.

Incident readiness

• Incident response plan and playbooks.
• Tabletop/exercise materials and after-action items.
• Incident tickets, timelines, communications approvals, and post-incident reports.

Third-party dependency management

• Critical third-party inventory and service mapping.
• Due diligence packages and security addenda in contracts.
• Ongoing monitoring notes and remediation tracking.

Common exam/audit questions and hangups

Use these to pre-brief control owners:

1. “Show me how you determined ‘appropriate and proportionate’ measures.” Expect to defend scoping, not just list controls. (Directive (EU) 2022/2555, Article 21)
2. “Which systems are used for service delivery, and how are they protected?” If you cannot map services to systems, you will scramble. (Directive (EU) 2022/2555, Article 21)
3. “Demonstrate incident handling in practice.” Auditors often request a recent incident record or an exercise with evidence of outcomes. (Directive (EU) 2022/2555, Article 21)
4. “How do you manage risk from critical third parties?” They will look for dependency mapping and assurance beyond initial onboarding. (Directive (EU) 2022/2555, Article 21)
5. “Where is your evidence?” If evidence is scattered across tools with no index, you lose time and credibility.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Avoid it by
Treating Article 21 as a policy-only update	The text demands measures and impact minimization, which requires operational proof. (Directive (EU) 2022/2555, Article 21)	Build an evidence map for each key control and test it.
Central program with no jurisdiction notes	NIS 2 is supervised through national regimes; requirements can be operationalized differently. (Directive (EU) 2022/2555)	Maintain a jurisdiction field in your obligation register and assign local owners.
Incident response that cannot produce artifacts	Examiners ask for timelines, tickets, and escalation records. (Directive (EU) 2022/2555, Article 21)	Define a standard incident record pack and require it for every incident/exercise.
Third-party risk handled outside cybersecurity risk	Critical dependencies can drive service impact, which is directly in-scope. (Directive (EU) 2022/2555, Article 21)	Tie critical third parties to services, risks, and incident workflows.
No operating effectiveness testing	“We have a control” is weaker than “here are last quarter’s test results.”	Build control tests into the GRC calendar and track exceptions to closure.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not list case examples.

Operational risk is still clear from the text: Article 21 ties cybersecurity measures to service continuity and incident impact on recipients and other services. If your controls do not reduce outage and compromise impact, you face supervisory findings and follow-on obligations under each Member State’s regime. (Directive (EU) 2022/2555, Article 21)

A practical 30/60/90-day execution plan

Use this as an execution sequence. Time labels are a planning tool, not a legal deadline.

First 30 days (stabilize scope and ownership)

• Confirm in-scope entities and services under NIS 2; document assumptions. (Directive (EU) 2022/2555)
• Build the Article 21 obligation-to-controls register: owners, systems, evidence locations, and known gaps. (Directive (EU) 2022/2555, Article 21)
• Draft your proportionality rationale and get executive sign-off on scoping and risk appetite.
• Inventory critical third parties tied to in-scope services; identify the “cannot fail” dependencies. (Directive (EU) 2022/2555, Article 21)

Next 60 days (make controls and incident handling exam-ready)

• Normalize core control evidence collection: access reviews, patching outputs, monitoring coverage, backup/restore proof.
• Publish incident triage and escalation workflow; run one tabletop and retain the full evidence pack. (Directive (EU) 2022/2555, Article 21)
• Add third-party assurance expectations for critical third parties (contract addenda where needed, due diligence refresh plan).
• Stand up remediation tracking with clear ownership and management reporting.

Next 90 days (prove operating effectiveness and close priority gaps)

• Execute operating effectiveness tests for top controls and document exceptions with closure plans.
• Run a service-impact scenario exercise (e.g., loss of a critical third party, ransomware affecting a core platform) and confirm communications paths.
• Produce a management-ready Article 21 compliance pack: register export, top risks, test results, and remediation status. (Directive (EU) 2022/2555, Article 21)

Where Daydream helps: use Daydream to keep the obligation register, evidence links, and remediation workflow together, so you can generate a regulator-ready pack without manual stitching.

Frequently Asked Questions

What does “appropriate and proportionate” mean in practice for Article 21?

It means your measures must match your real risk profile and service criticality, and you must be able to explain that match with documentation and evidence. Your proportionality rationale should connect services, systems, dependencies, and control depth. (Directive (EU) 2022/2555, Article 21)

Do we need to cover systems used for internal operations, or only customer-facing services?

Article 21 covers network and information systems you use “for their operations or for the provision of their services,” so internal systems can be in-scope if they affect service delivery or business operations. Document your scoping logic either way. (Directive (EU) 2022/2555, Article 21)

How should a GRC team prove compliance if security controls live in many tools?

Build an obligation-to-controls register that points to the system of record for each evidence type (tickets, logs, reports) and name an owner responsible for producing it on request. Then test evidence retrieval before an exam. (Directive (EU) 2022/2555, Article 21)

Are third parties explicitly part of Article 21?

Article 21 is framed around the security of the systems you use to operate and deliver services, which often includes critical third-party systems and services. Treat critical third-party dependencies as first-class inputs to risk assessment, incident handling, and remediation tracking. (Directive (EU) 2022/2555, Article 21)

What’s the fastest way to become “exam-ready” for Article 21?

Make incident handling and control testing provable: one working incident workflow, one completed exercise with retained artifacts, and a small set of high-impact control tests with recorded results and exception tracking. Anchor everything to a single register with owners. (Directive (EU) 2022/2555, Article 21)

Can we rely on existing ISO 27001 or NIST-based controls to satisfy Article 21?

Existing controls can form your baseline, but you still need to show they are appropriate for your NIS 2 in-scope services and that they operate effectively. Map your framework controls to Article 21 obligations and fill evidence gaps. (Directive (EU) 2022/2555, Article 21)