Article 21 Decoded: The 10 Cybersecurity Risk-Management Measures

Who should read this: CISOs, IT security leaders, risk managers, and anyone responsible for designing or implementing cybersecurity programmes.

Article 21 is the beating heart of NIS2. It specifies ten categories of mandatory cybersecurity risk-management measures that every essential and important entity must implement. These are not recommendations, guidelines, or best practices. They are legal obligations, and non-compliance carries penalties up to EUR 20 million or 4% of global annual turnover.

Yet Article 21 does not prescribe a single implementation pathway. It defines outcomes--what you must protect and what you must achieve--but allows flexibility in how you get there. This guide decodes each of the ten measures, explains what they require, and offers practical implementation notes.

The Foundational Principle: All-Hazards, Proportionate, Risk-Based

Before diving into the ten measures, understand the overarching principle in Article 21(1) and (2).

Article 21(1) requires that entities take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems." The measures must reflect the state-of-the-art, relevant standards, the cost of implementation, and the entity's size. Article 21(2) states that measures "shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents."

This means your measures must address not only cyberattacks but also physical threats (fire, flooding, physical break-ins, power loss) and environmental hazards. You cannot ignore the physical layer. An attacker who enters your data centre through a broken door is not a cyber threat, but your cybersecurity programme must address it.

The word "proportionate" matters. A microenterprise will implement different measures than a multinational corporation. Your implementation must reflect your risk profile, your size, and your operating context. Regulators will not punish you for not implementing measures that are disproportionate to your actual risks.

Measure 1 – Policies on Risk Analysis and Information System Security

Article 21(2)(a) requires "policies on risk analysis and information system security."

This is foundational. You must have documented policies that describe how your organisation identifies, assesses, and manages cybersecurity risk.

Your risk analysis policy should cover: how you identify assets (systems, data, infrastructure), how you identify threats and vulnerabilities affecting those assets, how you assess likelihood and impact, how you prioritise risks for treatment, and how you determine which risks you will accept, mitigate, or avoid.

Your information system security policy should cover: how you classify information, who has access to what information, how access is granted and revoked, how you protect information in transit and at rest, data retention and disposal, and how you prevent unauthorised disclosure.

These policies must be documented, current, and communicated to relevant personnel. They should be reviewed at least annually and updated to reflect changes in your threat landscape, business operations, or regulatory requirements.

Practical Implementation

Create a risk management framework that clearly defines your organisation's approach to identifying, assessing, and treating risk. Document your information classification scheme and access control policies. Ensure your policies specify roles and responsibilities. Make policies accessible to personnel who need them. Build a schedule for annual review and update. Link your policies to your incident response and business continuity plans.

Measure 2 – Incident Handling

Article 21(2)(b) requires "incident handling."

This is not optional. You must have a documented capability to detect, investigate, and respond to security incidents.

Your incident handling programme should define: what constitutes an incident (unauthorised access, data loss, system downtime, malware infection, etc.), how incidents are detected and reported, who has responsibility for incident response, what steps are taken during investigation, how severity is determined, what criteria define a significant incident (per Article 23(3)), how you preserve evidence, and how you document the response.

You must have a defined incident response team with clear roles: incident coordinator, technical investigator, management liaison, legal/compliance representative. The team must have contact information and escalation paths. You must conduct regular incident response drills to test your capability.

Critically, your incident handling process must integrate with your reporting obligation under Article 23. You must be able to identify significant incidents and notify your competent authority or CSIRT within 72 hours (or 24 hours if you are a trust service provider).

Practical Implementation

Define and document your incident definitions and severity classification. Establish an incident response team with clear roles and contact information. Create an incident response playbook with step-by-step procedures for common incident types. Set up detection tools (SIEM, intrusion detection, log monitoring) that alert your team to suspicious activity. Conduct tabletop exercises quarterly to test your response capability. Maintain an incident log documenting all incidents and their resolution. Integrate incident response with your legal and compliance functions to ensure proper notification.

Measure 3 – Business Continuity and Disaster Recovery

Article 21(2)(c) requires "business continuity, such as backup management and disaster recovery, and crisis management."

Your services must remain available even when incidents occur. You must have plans and capabilities to restore systems and data if they are corrupted, deleted, or otherwise made unavailable.

Your business continuity plan should identify which services are most critical to your organisation and to your customers. For each critical service, define a recovery time objective (RTO--how long you can tolerate the service being down) and a recovery point objective (RPO--how much data loss you can tolerate). Design backup and recovery strategies that meet these objectives.

Backup management is essential. You must maintain backups of critical data and systems. Backups must be kept separate from production systems (ideally in a different geographical location) so that a disaster affecting your primary facility does not also destroy your backups. You must regularly test backup restoration to ensure backups are actually usable.

Disaster recovery is your capability to restore operations after a major incident. This might mean activating a backup data centre, switching to a secondary location, or gradually restoring services. You must have documented procedures and have tested them.

Crisis management is your capability to communicate with customers, regulators, and the public during a major incident. You must know who will speak to the media, what information you will disclose, and how you will keep stakeholders informed.

Practical Implementation

Conduct a business impact analysis to identify critical services and their dependencies. Define RTO and RPO for each critical service based on business needs. Implement backup systems with appropriate frequency (daily, hourly, or continuous depending on criticality). Verify that backups are stored off-site or on protected systems. Test backup restoration at least annually. Document your disaster recovery procedures. Identify alternative facilities or cloud providers that could take over critical services if your primary location is unavailable. Conduct disaster recovery drills at least annually. Create a crisis communication protocol with defined spokespersons.

Measure 4 – Supply Chain Security

Article 21(2)(d) requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

This is a new and mandatory obligation under NIS2. It was not mandated in NIS1, yet supply chain attacks (such as SolarWinds) have proven to be among the most damaging cyber threats.

Your supply chain security programme must address your relationship with direct suppliers and service providers. This includes: identifying critical suppliers (those whose failure would disrupt your services), assessing their cybersecurity practices and maturity, contractually requiring them to meet minimum security standards, monitoring their compliance, and having contingency plans if they are compromised.

Article 21(3) specifies that you 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." You must also consider the results of coordinated security risk assessments of critical supply chains conducted by the Cooperation Group under Article 22.

This is not a one-time assessment. Supply chain security is ongoing. You must monitor your suppliers, update your contracts as threats evolve, and test your contingency plans.

Practical Implementation

Create a supplier inventory identifying critical suppliers--those whose unavailability or compromise would significantly impact your services. For each critical supplier, conduct a cybersecurity assessment using a questionnaire or audit. Include security clauses in your supplier contracts requiring minimum security standards (incident response capability, patch management, access controls, etc.). Establish a service level agreement (SLA) that includes security performance metrics. Conduct periodic reassessments of critical suppliers. Develop contingency plans for each critical supplier--alternative suppliers, internal capability to replace services, or agreements with backup vendors. Participate in Cooperation Group assessments of critical ICT supply chains and incorporate findings into your supplier management. Document your supply chain security process and decisions.

Measure 5 – Security in Systems Acquisition, Development, and Maintenance

Article 21(2)(e) requires "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure."

Whether you build your own systems, buy off-the-shelf software, or use cloud services, security must be built in from the start, not bolted on afterward.

For systems you develop internally, you must have secure development practices. This includes: secure coding standards, code review processes, testing for security vulnerabilities before deployment, vulnerability scanning, and a process for managing vulnerabilities discovered after deployment.

For systems and software you acquire, you must have vendor selection criteria that include security requirements. Evaluate vendors' secure development practices. Require vendors to disclose vulnerabilities they discover in their products. Ensure your contracts require vendors to patch vulnerabilities in a timely manner.

For all systems, you must maintain and update them throughout their lifecycle. This includes applying security patches, updating configurations as threats evolve, and retiring systems at end-of-life in a secure manner (ensuring data is properly deleted, licenses are decommissioned, etc.).

Vulnerability handling and disclosure is critical. You must have a process for identifying vulnerabilities (through your own testing, third-party assessments, or vendor disclosures), prioritising them based on risk, and applying fixes. You must also participate in coordinated vulnerability disclosure--if you discover vulnerabilities in third-party software or services, you should disclose them to the vendor responsibly and allow time for the vendor to patch before you disclose publicly.

Practical Implementation

Document your secure development practices including secure coding standards and code review requirements. Implement testing for security vulnerabilities in development (static and dynamic analysis, penetration testing). Create a vulnerability management process with clear prioritisation and remediation timelines. Establish vendor selection criteria that include security requirements. Audit vendors' security practices before contracting. Require vendors to commit to timely patching. Monitor for security patches and apply them promptly. Implement a configuration management process to track and update system configurations. Establish a vulnerability disclosure policy describing how you will report vulnerabilities to vendors. Maintain an inventory of systems and their lifecycle status. Plan for secure retirement of systems at end-of-life.

Measure 6 – Policies and Procedures to Assess Effectiveness

Article 21(2)(f) requires "policies and procedures to assess the effectiveness of cybersecurity risk-management measures."

You cannot just implement measures and assume they work. You must regularly assess whether your measures are actually effective at reducing risk.

This assessment should include: reviewing your risk assessments to ensure they accurately reflect your current threat landscape, testing your controls to confirm they are operating as designed, conducting security audits (internal or third-party), reviewing metrics and key risk indicators (KRIs) that track control effectiveness, and incorporating audit findings into your remediation programme.

Metrics matter. You might track: mean time to detect (MTTD) for security incidents, mean time to respond (MTTR), percentage of systems patched within your service level, number of access control violations detected, or percentage of personnel who have completed security training. These metrics give you visibility into whether your measures are working.

You should conduct an annual assessment of your overall cybersecurity risk posture. This assessment should consider your residual risk (risk that remains after you have implemented your measures), your risk appetite (how much risk you are willing to tolerate), and whether your measures are proportionate and effective.

Practical Implementation

Define metrics and KRIs that track control effectiveness for your key measures. Establish a quarterly review process where you assess metrics and identify trends. Conduct internal audits of cybersecurity controls at least annually. Engage third-party assessors to conduct penetration tests, vulnerability scans, or security audits at least annually. Document audit findings and create a remediation plan with clear owners and deadlines. Report audit results and remediation status to your management body quarterly. Conduct an annual security assessment that brings together your risk assessment, audit findings, and metrics to evaluate your overall cybersecurity posture.

Measure 7 – Basic Cyber Hygiene and Cybersecurity Training

Article 21(2)(g) requires "basic cyber hygiene practices and cybersecurity training."

Cyber hygiene is the foundation. Many breaches exploit basic hygiene gaps: weak passwords, unpatched systems, lack of multi-factor authentication, or poor email security.

Basic cyber hygiene practices should include: requiring strong passwords (or passphrases) with regular changes (or continuous monitoring for breaches), prohibiting password sharing, implementing password managers, maintaining updated patches on all systems, removing unnecessary services and access, backing up critical data regularly, using antivirus or endpoint detection and response (EDR) tools, enabling logging for security events, and monitoring for anomalous activity.

Cybersecurity training is equally important. All personnel must understand basic security hygiene. Users should understand phishing risks, how to report suspicious emails, the importance of not sharing credentials, and how to handle sensitive data. Developers should understand secure coding. System administrators should understand secure configuration. Your board and senior management should understand cybersecurity risk and their governance responsibilities.

Training should be mandatory for all personnel upon hire and refreshed at least annually. Training should be tailored to different roles (technical staff need more depth than general users). You should track training completion and require 100% attendance.

Practical Implementation

Define your organisation's basic cyber hygiene standards (password policy, patch management, antivirus, MFA, email security, etc.). Publish these standards and communicate them to all personnel. Implement technical controls to enforce these standards where possible (e.g., enforce MFA on VPNs, require antivirus on endpoints, scan emails for malware). Conduct quarterly awareness campaigns on phishing, password security, and data protection. Deliver role-based training annually (general security awareness for all staff, secure coding for developers, secure administration for IT staff, etc.). Track training completion and follow up with non-completers. Conduct a phishing simulation exercise quarterly and track which users fall for simulated phishing. Incorporate phishing results into your awareness programme.

Measure 8 – Cryptography and Encryption Policies

Article 21(2)(h) requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption."

Cryptography is the mathematical foundation of modern cybersecurity. It protects data confidentiality, integrity, and authenticity. You must have policies that ensure cryptography is used appropriately throughout your organisation.

Your cryptography policy should specify: which data must be encrypted (sensitive personal data, financial data, intellectual property, etc.), the encryption standards you will use (e.g., AES-256 for data at rest, TLS 1.2+ for data in transit), how encryption keys will be generated, stored, and rotated, who has access to encryption keys, and how encryption will be managed across your systems.

"Where appropriate" is important. Encryption is not always necessary. Encrypting non-sensitive operational data may create complexity without benefit. But sensitive data must be encrypted both at rest (when stored) and in transit (when transmitted across networks). Data transmitted over the internet should always be encrypted using TLS or equivalent standards.

You must also specify what encryption standards are acceptable. Old or weak algorithms should be deprecated. Your policy should require modern algorithms (AES, SHA-256, TLS 1.2 or higher) and prohibit weak algorithms (DES, MD5, SSL 3.0).

Encryption key management is critical. Keys are often the weakest point in cryptographic systems. You must ensure keys are stored securely (not in plain text in code or configuration files), rotated regularly (annually or more frequently), and accessible only to authorized systems or personnel.

Practical Implementation

Classify your data by sensitivity (public, internal, sensitive, highly sensitive). For each classification, define encryption requirements. For sensitive data, require encryption in transit using TLS 1.2+ and encryption at rest using AES-256. Audit your systems to identify where sensitive data exists and verify it is encrypted. For systems that do not yet encrypt sensitive data, create a remediation plan. Implement a key management system (KMS) that generates, stores, and rotates encryption keys. Ensure keys are never stored in code or configuration files. Implement hardware security modules (HSMs) for highly sensitive keys. Retire old or weak encryption algorithms. Document your cryptography policy and publish it to relevant teams. Include cryptography requirements in your system design reviews and vendor evaluations.

Measure 9 – Human Resources Security, Access Control, and Asset Management

Article 21(2)(i) requires "human resources security, access control policies and asset management."

Your people, processes, and assets are potential attack surfaces. You must manage access carefully.

Human resources security includes: background checks on personnel with access to critical systems, employment contracts that include security obligations, training on security policies, and secure termination procedures (revoking access promptly when employees depart).

Access control policies should follow the principle of least privilege: grant personnel only the minimum access needed to do their job. Access should be approved before being granted, reviewed periodically, and revoked immediately when no longer needed. Privileged access (e.g., administrative accounts) should be carefully controlled, monitored, and restricted to specific individuals who have been trained and approved.

Asset management ensures you know what systems, devices, and data exist in your organisation. You should maintain an inventory of hardware (servers, computers, phones, network devices), software (applications, libraries, patches), and data (what data exists, where it is stored, who has access). This inventory helps you identify security gaps--an unpatched system cannot be fixed if you do not know it exists.

Practical Implementation

Define and document your access control policy based on least privilege. Require managers to certify that access granted to their teams is appropriate and necessary. Implement privileged access management (PAM) for administrative accounts, requiring approval before use and logging all privileged actions. Review all user access quarterly and revoke access no longer needed. Revoke access immediately upon termination, before the departing employee's last day if possible. Implement role-based access control (RBAC) that assigns access based on job roles rather than individual names. Maintain an asset inventory (hardware, software) and update it quarterly. Track asset lifecycle (acquisition, deployment, updates, retirement). Use multi-factor authentication for critical systems and administrative access. Document access policies and require all personnel with system access to sign an acknowledgment.

Measure 10 – Multi-Factor Authentication and Secure Communications

Article 21(2)(j) requires "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."

Multi-factor authentication (MFA) is one of the highest-impact controls. A password alone is easily compromised (through phishing, brute force, or data breaches). MFA adds a second factor--something you have (a phone), something you are (biometric), or something you know (security questions)--so an attacker who steals a password still cannot gain access.

You should require MFA for at least critical systems: VPN access, administrative access, email systems, and any system that handles sensitive data. The word "appropriate" gives some flexibility, but security best practices strongly favour requiring MFA for any system with access to sensitive data or administrative functions. Consumer-level employees accessing non-sensitive systems might be lower priority, but high-privilege accounts must use MFA.

Continuous authentication is an alternative mentioned in the Directive. This means that instead of authenticating once at login, the system continuously verifies the user's identity based on behaviour, biometrics, or device characteristics. If the identity cannot be verified, the system may require re-authentication or lock the session. This is more advanced and less widely deployed than MFA, but represents an emerging best practice.

Secured voice, video, and text communications means that internal communications should use encrypted channels. Email should be encrypted (either end-to-end encryption or encrypted transport). Voice and video calls should use encrypted protocols (e.g., TLS for video conferencing, encrypted VoIP). This prevents eavesdropping or interception.

Secured emergency communication systems are critical for incident response. If your primary network is compromised, you must have a way to communicate that the attacker cannot intercept. You might maintain a secondary communication channel (a separate phone line, a radio system, an out-of-band messaging system) that incident responders can use if the primary network is unavailable.

Practical Implementation

Mandate MFA for all VPN access, administrative accounts, and any system handling sensitive data. Use authenticator apps or hardware security keys rather than SMS (which can be intercepted). For less critical systems, at minimum require strong, unique passwords. Implement continuous authentication for sensitive systems if feasible (user behaviour analytics, device identity verification). Encrypt email in transit (TLS) and optionally at rest. Use encrypted video conferencing platforms (Teams, Zoom with encryption enabled, etc.). Require encrypted messaging for sensitive conversations. Establish an out-of-band communication channel (phone line, radio, satellite phone) that incident response teams can use if the primary network is down. Test your emergency communications quarterly to ensure they work when needed.

Putting It Together: Article 21 Implementation Roadmap

The ten measures are interconnected. You cannot implement them in isolation.

Start with measures 1 and 2: document your risk analysis and incident handling processes. These create the foundation.

Add measure 6: establish how you will assess whether your measures are working.

Add measures 3, 4, and 5: address your critical dependencies (business continuity, supply chain, systems).

Add measures 7, 8, 9, and 10: harden your operational controls (hygiene, encryption, access, authentication).

Integrate everything: ensure your board approves all measures (Article 20), ensure you can report incidents (Article 23), and ensure your measures reflect your risk profile (Article 21(1)).

Key Takeaways

- The ten Article 21(2) measures are mandatory for all essential and important entities: risk analysis and security policies, incident handling, business continuity, supply chain security, secure systems development, effectiveness assessment, cyber hygiene and training, cryptography, human resources and access control, and multi-factor authentication.

- Each measure must be tailored to your organisation's size, threat profile, and business model; "proportionate" is key--regulators will not penish you for not implementing measures disproportionate to your actual risks.

- Measures are interconnected and should be implemented as an integrated programme; measures 1, 2, and 6 create the foundation; measures 3, 4, and 5 address critical dependencies; measures 7, 8, 9, and 10 harden operational controls.

- Supply chain security (measure 4) is new and mandatory under NIS2; it requires identifying critical suppliers, assessing their security practices, contractual requirements, and contingency plans.

- Implementation requires documented policies, regular testing and assessment, clear roles and responsibilities, and integration with board-level governance; the 12 May 2025 compliance deadline requires immediate action to close gaps.