In This Guide
- Article 21 Overview
- The Proportionality Principle
- Risk Analysis & IS Policies
- Incident Handling
- Business Continuity & Crisis Management
- Supply Chain Security
- Acquisition, Development & Maintenance
- Effectiveness Assessment
- Cyber Hygiene & Training
- Cryptography & Encryption
- HR Security, Access Control & Assets
- MFA & Secure Communications
- How Measures Interact
- How Glocert International Helps
- Frequently Asked Questions
- Article 21(2) of the NIS2 Directive prescribes 10 minimum cybersecurity risk management measures that both Essential and Important entities must implement.
- Measures are technology-neutral and outcomes-based — the Directive tells you what to achieve, not how to achieve it.
- The proportionality principle (Article 21(1)) means the depth and sophistication of controls must match the entity's risk exposure, size, and the societal impact of potential incidents.
- Organisations with an existing ISO 27001-certified ISMS already address a significant portion of Article 21, but gaps typically exist around supply chain security, management body accountability, incident reporting timelines, and explicit MFA requirements.
- Non-compliance can attract fines of up to EUR 10 million or 2% of global annual turnover for Essential entities.
Article 21 Overview
Article 21 of the NIS2 Directive (Directive (EU) 2022/2555) is the cornerstone of the Directive's cybersecurity obligations. It requires Essential and Important entities to take appropriate and proportionate technical, operational, and organisational measures to manage the risks posed to the security of the network and information systems they use for their operations or service provision.
Article 21(2) then enumerates 10 specific measures that must be included — as a minimum — within the entity's overall risk management framework. These measures are not exhaustive; entities may need additional controls depending on their risk profile. However, they represent the baseline that regulators and auditors will assess.
Article 20 of NIS2 places explicit accountability on the management body (board of directors, C-suite) for approving and overseeing the implementation of Article 21 measures. Management members must also undergo cybersecurity training. This is a significant shift from NIS1, where accountability was less precisely defined.
The Proportionality Principle — Article 21(1)
Before diving into the 10 individual measures, it is essential to understand the proportionality principle embedded in Article 21(1). Entities are not expected to implement identical controls regardless of size. Instead, measures must be proportionate to:
- The entity's risk exposure: What threats are realistic given the sector, geography, and technology stack?
- The size of the entity: A multinational critical infrastructure operator will be held to a different standard than a 50-person managed service provider.
- The likelihood and severity of incidents: Higher-probability, higher-impact scenarios demand more robust controls.
- The societal and economic impact: Entities whose disruption would affect public safety, health, or essential economic functions face stricter expectations.
In practice, this means a small Important entity may demonstrate compliance with a well-documented risk assessment and sensible baseline controls, whereas a large Essential entity in the energy or healthcare sector will need enterprise-grade security operations, advanced threat detection, and extensive supply chain governance.
Proportionality does not mean optional. Every in-scope entity must address all 10 measures — but the depth, sophistication, and investment will differ based on context.
(a) Risk Analysis and Information Security Policies
What the Directive Requires
Entities must establish policies on risk analysis and information system security. This is the foundational measure upon which all other controls are built. It requires a structured, repeatable methodology for identifying, assessing, and treating cybersecurity risks, together with a documented suite of information security policies that set the organisation's security direction.
Practical Implementation Guidance
- Risk assessment methodology: Define a methodology covering asset identification, threat analysis, vulnerability assessment, likelihood and impact scoring, and risk treatment options (mitigate, transfer, accept, avoid). Align with ISO 27005 or a recognised framework.
- Risk register: Maintain a living risk register that is reviewed and updated at least annually, and after significant changes to the environment.
- Policy framework: Develop an overarching information security policy approved by the management body, supported by topic-specific policies (acceptable use, access control, data classification, etc.).
- Policy governance: Assign policy ownership, define review cycles (at least annual), and communicate policies to all relevant personnel.
- Management body approval: Ensure the management body formally approves the risk assessment results and the information security policy — this is explicitly required under Article 20.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Risk assessment methodology document | Documented procedure covering scope, criteria, scoring, treatment options, and review frequency |
| Risk register | Spreadsheet or GRC tool export showing identified risks, owners, scores, treatment decisions, and residual risk levels |
| Information security policy | Board-approved policy with version control, approval signatures, and distribution records |
| Management review minutes | Meeting minutes evidencing board review and approval of risk assessment outputs |
| Policy acknowledgement records | Evidence that employees have read and acknowledged security policies |
Common Nonconformities
- Risk assessment not conducted or not updated following significant infrastructure changes
- Information security policy not formally approved by the management body
- Risk register treats all risks at the same level without differentiation of likelihood and impact
- Policies exist but are not communicated to staff or lack evidence of acknowledgement
(b) Incident Handling
What the Directive Requires
Entities must implement procedures and capabilities for incident handling — covering prevention, detection, analysis, containment, response, and recovery from cybersecurity incidents. This measure must be read alongside Article 23, which imposes strict incident reporting timelines to competent authorities and CSIRTs.
Practical Implementation Guidance
- Incident response plan: Document a formal incident response plan covering roles, escalation paths, containment procedures, eradication steps, recovery processes, and post-incident review.
- Detection capabilities: Deploy SIEM, EDR, IDS/IPS, or equivalent technologies appropriate to the entity's risk profile. Ensure 24/7 monitoring or appropriate on-call arrangements.
- Classification and triage: Define incident severity levels and triage criteria that determine response urgency and reporting obligations.
- Reporting procedures: Map internal incident classification to NIS2 reporting thresholds: early warning within 24 hours, incident notification within 72 hours, and final report within one month of the notification.
- Post-incident reviews: Conduct root cause analysis and lessons-learned sessions after significant incidents, and feed findings back into the risk assessment process.
- Testing: Conduct tabletop exercises or simulations at least annually to validate the effectiveness of the incident response plan.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Incident response plan | Documented plan with roles, escalation matrix, containment procedures, and communication templates |
| Incident log | Ticketing system records showing incident timeline, classification, actions taken, and resolution |
| Post-incident review reports | Root cause analysis documents with corrective actions and timelines |
| Tabletop exercise records | Scenario description, participant list, observations, and improvement actions from exercises |
| SIEM/EDR dashboards | Screenshots or reports demonstrating monitoring coverage and alert processing |
Common Nonconformities
- Incident response plan exists on paper but has never been tested through exercises
- No documented process for meeting NIS2 reporting timelines (24h / 72h / 1 month)
- Post-incident reviews not conducted, or findings not fed back into the risk register
- Detection capabilities limited to perimeter defences with no endpoint or internal monitoring
(c) Business Continuity and Crisis Management
What the Directive Requires
Entities must implement business continuity management, including backup management, disaster recovery, and crisis management. This measure ensures that critical services can continue or be rapidly restored following a disruptive cyber incident.
Practical Implementation Guidance
- Business impact analysis (BIA): Identify critical services and systems, determine maximum tolerable downtime, and set recovery time objectives (RTO) and recovery point objectives (RPO).
- Business continuity plans (BCPs): Develop plans for maintaining or resuming critical operations during and after an incident. Include manual workarounds where appropriate.
- Disaster recovery (DR): Implement DR capabilities for critical IT systems, including off-site or cloud-based recovery environments, tested failover procedures, and documented runbooks.
- Backup management: Implement the 3-2-1 backup rule (three copies, two media types, one off-site). Test restoration from backups regularly. Ensure backups are protected from ransomware (immutable/air-gapped copies).
- Crisis management: Establish a crisis management team with clear authority, decision-making protocols, and internal/external communication plans. Include communication templates for regulators, customers, and the public.
- Testing and exercising: Conduct BCP/DR tests at least annually. Validate that RTOs and RPOs are achievable.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Business impact analysis | Documented BIA identifying critical services, dependencies, RTOs, and RPOs |
| Business continuity plans | Plans for each critical service with activation criteria, procedures, and responsible persons |
| Backup policy and restoration test records | Policy defining backup scope, frequency, retention, and encryption; test logs showing successful restoration |
| DR test reports | Records of failover tests including achieved recovery times versus targets |
| Crisis communication plan | Contact lists, communication templates, and decision authority matrix |
Common Nonconformities
- Backups exist but restoration has never been tested
- BCPs cover IT systems but not business processes or manual workarounds
- No off-site or immutable backup copies, leaving backups vulnerable to ransomware
- RTOs and RPOs are stated but not validated through testing
- Crisis management team roles are undefined or members are unaware of their responsibilities
(d) Supply Chain Security
What the Directive Requires
Entities must address supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. This is one of the most significant expansions from NIS1, reflecting the growing threat of supply chain attacks.
Practical Implementation Guidance
- Supplier risk assessment: Identify and classify suppliers based on their criticality to the entity's operations and the potential impact of a compromise. Conduct security due diligence proportionate to the risk level.
- Contractual requirements: Include cybersecurity requirements in supplier contracts covering security standards, incident notification obligations, audit rights, data protection, and subcontractor management.
- Ongoing monitoring: Implement processes to monitor supplier security posture over time — through periodic assessments, security ratings platforms, or right-to-audit exercises.
- Software supply chain: Address risks from software dependencies, open-source components, and update mechanisms. Consider requiring Software Bills of Materials (SBOMs) from critical software suppliers.
- Incident coordination: Establish procedures for coordinating incident response with key suppliers, including mutual notification obligations and joint response protocols.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Supplier register with risk classification | Inventory of suppliers categorised by criticality with risk scores and review dates |
| Supplier security assessment records | Completed questionnaires, audit reports, or certification evidence for critical suppliers |
| Contract clauses | Extracts of cybersecurity clauses from supplier agreements (security standards, incident notification, audit rights) |
| Supplier monitoring reports | Periodic review outputs, security rating reports, or corrective action follow-ups |
| SBOM inventory | Software Bill of Materials for critical applications documenting third-party components |
Common Nonconformities
- No supplier risk classification — all suppliers treated identically regardless of criticality
- Contracts lack cybersecurity-specific clauses or incident notification requirements
- Initial supplier assessment conducted but no ongoing monitoring programme
- Software supply chain risks (open-source dependencies, update integrity) not addressed
(e) Security in Acquisition, Development, and Maintenance
What the Directive Requires
Entities must ensure security in network and information system acquisition, development, and maintenance, including vulnerability handling and disclosure. This encompasses the entire lifecycle of information systems from procurement through deployment to decommissioning.
Practical Implementation Guidance
- Secure development lifecycle (SDLC): Embed security into software development processes — threat modelling, secure coding standards, code review, static and dynamic application security testing (SAST/DAST).
- Procurement security requirements: Define security requirements for systems and services before procurement. Include security evaluation criteria in vendor selection.
- Vulnerability management: Implement a vulnerability management programme with regular scanning (at least monthly for critical assets), risk-based prioritisation, and defined remediation SLAs.
- Vulnerability disclosure: Establish a coordinated vulnerability disclosure (CVD) policy, including a clear channel for researchers or third parties to report vulnerabilities.
- Patch management: Define and enforce patch management timelines: critical vulnerabilities within 48-72 hours, high within 7 days, medium within 30 days.
- Change management: Implement formal change management processes for all modifications to production systems, including security impact assessment, testing, and approval workflows.
- Secure decommissioning: Ensure data sanitisation and secure disposal when systems reach end of life.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Secure development policy | SDLC policy covering threat modelling, code review, testing, and deployment security gates |
| Vulnerability scan reports | Monthly or continuous scan outputs showing identified vulnerabilities and remediation status |
| Patch management records | Ticketing system records showing patch deployment timelines against defined SLAs |
| Change management logs | Change advisory board records, approval workflows, and post-implementation reviews |
| Vulnerability disclosure policy | Published CVD policy with reporting channel, response timeline commitments, and safe harbour provisions |
Common Nonconformities
- Vulnerability scanning performed ad hoc rather than on a defined schedule
- No formal patch management SLAs; critical patches left undeployed for weeks or months
- Software development lacks security gates — code deploys to production without security testing
- No coordinated vulnerability disclosure policy or contact point for external reporters
- Change management bypassed for "emergency" changes without retrospective approval
(f) Policies and Procedures to Assess Effectiveness
What the Directive Requires
Entities must have policies and procedures in place to assess the effectiveness of the cybersecurity risk management measures they have implemented. This is the "check" phase — without it, organisations cannot know whether their controls are actually working.
Practical Implementation Guidance
- Internal audits: Conduct periodic internal audits of cybersecurity controls, covering all Article 21 measures on a defined cycle. Auditors should be competent and independent of the areas they audit.
- Penetration testing: Commission regular penetration tests (at least annually for critical systems) to validate the effectiveness of technical controls from an attacker's perspective.
- Security metrics and KPIs: Define measurable indicators to track control performance — e.g., mean time to detect (MTTD), mean time to respond (MTTR), patch compliance rates, phishing simulation click rates, backup success rates.
- Management review: Present security performance data to the management body at least annually, enabling informed decision-making on risk treatment and resource allocation.
- Continuous improvement: Use audit findings, test results, incident post-mortems, and metric trends to drive continual improvement of the cybersecurity programme.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Internal audit plan and reports | Audit programme covering all Article 21 measures, with completed audit reports and finding status |
| Penetration test reports | Reports from qualified testers covering scope, findings, risk ratings, and remediation recommendations |
| Security KPI dashboard | Dashboard or periodic report tracking key performance indicators over time |
| Management review minutes | Meeting records showing management body review of security effectiveness data and decisions taken |
| Corrective action tracker | Log of identified weaknesses with owners, due dates, completion status, and verification evidence |
Common Nonconformities
- No internal audit programme for cybersecurity controls; reliance solely on external audits
- Penetration testing limited to external perimeter with no assessment of internal network or applications
- KPIs defined but not regularly measured, reported, or acted upon
- Management body receives no regular reporting on cybersecurity control effectiveness
(g) Basic Cyber Hygiene Practices and Cybersecurity Training
What the Directive Requires
Entities must implement basic cyber hygiene practices and cybersecurity training for all staff. Article 20(2) additionally requires that management body members undergo specific cybersecurity training to enable them to assess risks and the adequacy of measures.
Practical Implementation Guidance
- Security awareness programme: Deliver regular security awareness training to all employees, covering phishing, social engineering, password security, safe browsing, mobile device security, and data handling. New starters should receive training during onboarding.
- Role-based training: Provide specialised training for roles with elevated risk — system administrators, developers, incident responders, and data handling personnel.
- Management body training: Ensure board members and senior executives receive cybersecurity training appropriate to their governance responsibilities. This should cover the entity's risk landscape, NIS2 obligations, and their personal accountability under Article 20.
- Phishing simulations: Conduct regular phishing simulation campaigns to measure susceptibility and reinforce training. Track click rates and reporting rates over time.
- Cyber hygiene baselines: Define and enforce basic hygiene standards: strong passwords or passphrases, software updates on endpoint devices, screen lock policies, clean desk policy, and secure Wi-Fi usage.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Training programme documentation | Training plan covering content, frequency, delivery method, and target audiences |
| Training completion records | LMS records showing completion rates by department and role, including management body members |
| Phishing simulation reports | Campaign results showing click rates, reporting rates, and trends across campaigns |
| Management body training certificates | Evidence of board-level cybersecurity training or briefing attendance |
| Cyber hygiene policy | Documented baseline hygiene standards enforced through technical controls and policy |
Common Nonconformities
- Training is one-off at hire with no annual refresher
- Management body members have not received cybersecurity training (an explicit NIS2 requirement)
- No phishing simulations conducted to validate training effectiveness
- Training content is generic and not tailored to the organisation's specific risk environment
(h) Policies on Cryptography and Encryption
What the Directive Requires
Entities must establish policies and, where appropriate, procedures on the use of cryptography and encryption. This measure aims to protect the confidentiality, integrity, and authenticity of information both at rest and in transit.
Practical Implementation Guidance
- Encryption at rest: Encrypt sensitive data stored in databases, file systems, backups, and removable media. Use AES-256 or equivalent algorithms. Implement full-disk encryption on endpoint devices (laptops, mobile devices).
- Encryption in transit: Enforce TLS 1.2 or later for all external and internal communications handling sensitive data. Disable deprecated protocols (SSL, TLS 1.0/1.1). Implement HTTPS everywhere for web-facing services.
- Key management: Establish a key management procedure covering key generation (using secure random sources), storage (HSMs or equivalent), rotation schedules, access controls, and secure destruction. Separate key management responsibilities from data access.
- Cryptographic policy: Document a policy specifying approved algorithms, minimum key lengths, use cases for encryption, digital signatures, and hashing. Prohibit use of deprecated algorithms (MD5, SHA-1, DES, 3DES).
- Certificate management: Maintain an inventory of TLS/SSL certificates, automate renewal where possible, and monitor for expiry.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Cryptographic policy | Policy defining approved algorithms, key lengths, use cases, and prohibited ciphers |
| Encryption implementation evidence | Configuration screenshots or reports showing encryption enabled on databases, storage, endpoints, and communications |
| Key management procedure | Documented procedure covering key lifecycle: generation, storage, rotation, access, and destruction |
| TLS configuration reports | SSL Labs or equivalent scan reports confirming TLS 1.2+ enforcement and cipher suite configuration |
| Certificate inventory | Register of all certificates with expiry dates, owners, and renewal status |
Common Nonconformities
- No formal cryptographic policy — encryption is applied inconsistently across systems
- Deprecated protocols (TLS 1.0/1.1) still enabled on internet-facing services
- Encryption keys stored alongside encrypted data without adequate access controls
- No key rotation schedule; same keys used since initial deployment
- Backup data stored unencrypted, exposing recovery media to data theft
(i) Human Resources Security, Access Control, and Asset Management
What the Directive Requires
Entities must address human resources security, access control policies, and asset management. This is a broad measure covering the security of people, the control of logical and physical access, and the governance of hardware, software, and data assets.
Practical Implementation Guidance
- Joiner-Mover-Leaver (JML) process: Implement a formal process for provisioning, modifying, and revoking access rights when employees join, change role, or leave. Automate where possible through identity governance tools.
- Role-based access control (RBAC): Implement the principle of least privilege through RBAC. Define access profiles based on job function and grant only the minimum access necessary. Review role definitions periodically.
- Privileged access management (PAM): Apply enhanced controls to privileged accounts: just-in-time access, session recording, separate admin credentials, and regular review of privileged account holders.
- Access reviews: Conduct periodic user access reviews (at least quarterly for critical systems, semi-annually for others) to verify that access rights remain appropriate.
- Asset management: Maintain a comprehensive inventory of hardware, software, and data assets. Classify assets by criticality and sensitivity. Define ownership for each asset.
- HR security controls: Conduct pre-employment screening proportionate to the role. Include security responsibilities in employment contracts. Conduct exit procedures including access revocation, equipment return, and NDA reminders.
Evidence Examples
| Evidence Item | Description |
|---|---|
| Access control policy | Policy defining least privilege, RBAC, access request workflows, and review requirements |
| JML procedure records | Ticketing records showing access provisioning, modification, and timely revocation for leavers |
| User access review reports | Quarterly or semi-annual review outputs showing all access verified, exceptions flagged, and actions taken |
| Asset inventory | CMDB or asset register listing hardware, software, and data assets with classification and ownership |
| Pre-employment screening records | Background check completion records for relevant roles (redacted personal data) |
Common Nonconformities
- Access not revoked within 24 hours of employee departure — orphaned accounts remain active
- Shared or generic accounts used for administrative access, preventing accountability
- Access reviews not performed or performed without proper verification (rubber-stamping)
- Asset inventory incomplete or outdated — shadow IT not addressed
- No privileged access management; admin credentials shared informally
(j) Multi-Factor Authentication and Secure Communications
What the Directive Requires
Entities must use multi-factor authentication (MFA) or continuous authentication solutions, and secured voice, video, and text communications, as well as secured emergency communication systems within the entity where appropriate.
Practical Implementation Guidance
- MFA scope: Deploy MFA for all remote access, VPN connections, privileged account access, cloud service authentication, and access to critical or sensitive systems. Extend to all user accounts where feasible.
- MFA method selection: Prefer phishing-resistant MFA methods (hardware security keys / FIDO2, authenticator apps with number matching) over SMS-based OTP. SMS-based MFA is better than nothing but is vulnerable to SIM swapping.
- Secure communications: Implement end-to-end encryption for voice, video, and messaging used for sensitive or operational communications. Evaluate and approve specific platforms for sensitive discussions.
- Emergency communications: Establish out-of-band emergency communication channels that do not rely on the primary IT infrastructure — e.g., separate mobile phones, encrypted messaging apps on personal devices, or satellite phones for critical infrastructure operators.
- Conditional access: Complement MFA with conditional access policies that assess device posture, location, and risk signals before granting access.
Evidence Examples
| Evidence Item | Description |
|---|---|
| MFA policy | Policy defining where MFA is required, approved authentication methods, and exceptions (if any) |
| MFA deployment report | Identity provider report showing MFA enrolment rates across user populations |
| Conditional access configuration | Screenshots or exports of conditional access policies from the identity provider |
| Secure communications register | List of approved communication platforms with encryption capabilities documented |
| Emergency communication plan | Documented out-of-band communication procedures with contact details and testing records |
Common Nonconformities
- MFA not enforced for all remote access or cloud service access
- Reliance on SMS-based OTP as the sole MFA method for privileged accounts
- No approved platform for secure internal communications; sensitive discussions occurring on unencrypted channels
- Emergency communication plan not established or not tested
- MFA exceptions granted broadly without risk-based justification or compensating controls
How the 10 Measures Interact
The 10 Article 21(2) measures are not independent silos — they form an interconnected system of controls that reinforce one another. Understanding these interactions is critical for effective implementation and for demonstrating compliance holistically.
- Risk analysis (a) drives everything: The risk assessment identifies which threats are most material, which in turn determines the depth required for incident handling (b), the scope of business continuity planning (c), and the priority of supply chain assessments (d).
- Incident handling (b) validates business continuity (c): Incident response capabilities are activated during business continuity events. The incident classification scheme should integrate with BCP activation criteria.
- Supply chain security (d) feeds into acquisition security (e): Supplier risk assessments inform procurement security requirements, and vulnerability disclosures from suppliers trigger patch management processes.
- Training (g) underpins all human-dependent controls: Access control policies (i) only work if staff understand them. Incident handling (b) depends on employees recognising and reporting suspicious activity. Cryptographic policies (h) require developers and administrators who know how to implement them.
- Effectiveness assessment (f) closes the loop: Internal audits, penetration tests, and KPIs provide feedback on whether all other measures are working as intended, driving continual improvement.
- MFA (j) reinforces access control (i): Multi-factor authentication is the technical enforcement mechanism for the access control policies defined under measure (i), and is a prerequisite for securing remote access to systems covered by business continuity plans (c).
When building your compliance framework, map each control to every Article 21 measure it supports. A single control (e.g., a SIEM platform) may provide evidence for incident handling (b), effectiveness assessment (f), and access monitoring (i) simultaneously. This reduces duplication and demonstrates integrated thinking to assessors.
How Glocert International Helps
Glocert International provides independent NIS2 cybersecurity assessments that evaluate your organisation's posture against all 10 Article 21(2) measures. Our assessments deliver:
- Gap analysis: Control-by-control evaluation against every Article 21 measure, identifying shortfalls and rating them by risk severity
- Prioritised remediation roadmap: Actionable plan with owners, milestones, and estimated effort for each gap
- Evidence compilation guidance: Practical advice on what evidence to collect and how to organise it for regulatory inspection
- Attestation-ready reporting: Assessment report suitable for presentation to management bodies, regulators, and supply chain partners
- ISO 27001 alignment: Where applicable, mapping your existing ISO 27001 controls to NIS2 requirements to maximise reuse and minimise duplication
Frequently Asked Questions
What are the 10 NIS2 Article 21 risk management measures?
The 10 measures mandated by Article 21(2) are: (a) risk analysis and information security policies, (b) incident handling, (c) business continuity and crisis management including backup and disaster recovery, (d) supply chain security, (e) security in network and information systems acquisition, development, and maintenance including vulnerability handling and disclosure, (f) policies and procedures to assess the effectiveness of cybersecurity risk management measures, (g) basic cyber hygiene practices and cybersecurity training, (h) policies and procedures on the use of cryptography and encryption, (i) human resources security, access control, and asset management, and (j) the use of multi-factor authentication or continuous authentication solutions, secured voice, video, and text communications, and secured emergency communication systems.
Does NIS2 Article 21 apply to both Essential and Important entities?
Yes. All 10 Article 21(2) measures apply to both Essential and Important entities. However, under the proportionality principle in Article 21(1), the depth and sophistication of controls must be appropriate to the entity's risk exposure, size, likelihood and severity of potential incidents, and the societal and economic impact. The supervisory regime also differs: Essential entities face proactive, ex-ante supervision, while Important entities face reactive, ex-post supervision triggered by evidence of non-compliance.
How does NIS2 Article 21 relate to ISO 27001?
There is significant overlap between the Article 21 measures and ISO 27001:2022 Annex A controls. Organisations with an existing ISO 27001-certified ISMS will find that many NIS2 requirements are already addressed. However, NIS2 introduces additional obligations that may go beyond ISO 27001, including explicit supply chain security requirements, mandated incident reporting timelines (24h / 72h / 1 month), management body personal accountability and training, specific MFA requirements, and emergency communication system provisions. A mapping exercise is recommended to identify and close any remaining gaps.
What happens if an organisation fails to comply with Article 21?
Non-compliance with Article 21 can result in significant penalties. For Essential entities, administrative fines of up to EUR 10 million or 2% of total worldwide annual turnover (whichever is higher) may be imposed. For Important entities, fines of up to EUR 7 million or 1.4% of turnover apply. Beyond financial penalties, competent authorities can issue binding instructions, order security audits at the entity's expense, or impose temporary prohibitions on individuals exercising managerial functions. Management bodies can also be held personally liable under Article 20.
When must organisations comply with NIS2 Article 21?
The NIS2 Directive (Directive (EU) 2022/2555) entered into force on 16 January 2023. Member States were required to transpose it into national law by 17 October 2024. Organisations within scope must comply with their Member State's transposing legislation from the applicable date. The European Commission also adopted Implementing Regulation (EU) 2024/2690 in October 2024, setting out specific technical and methodological requirements for providers of DNS services, TLD registries, cloud computing, data centres, CDNs, managed services, managed security services, online marketplaces, search engines, and social networking platforms.