Most guides about NIS2 give you a summary and move on. That works if you just need to know whether the directive applies to you. But if you’re the person who has to actually implement it - writing the policies, setting up incident reporting, getting management sign-off - you need more than a summary. You need to know what each article says, what it means in practice, and what evidence you should have ready when the auditor shows up.
This is that guide. I’m going to walk through NIS2 Articles 20 through 25 one by one. These six articles contain every requirement that directly affects your organization. The rest of the directive deals with how EU member states should organize themselves, how CSIRTs operate, and other institutional matters that you don’t control.
If you haven’t determined yet whether NIS2 applies to your organization, start with our NIS2 directive explainer - it covers scope, entity classification, and penalties. This article assumes you already know NIS2 applies to you, and you need to get compliant.
For a quick self-assessment, try our free NIS2 Readiness Assessment - it scores your readiness across all NIS2 domains in about 15 minutes.
Article 20 - Governance: management is personally on the hook
Article 20 is only two paragraphs long, but it changes the game for most organizations. Here’s what it says, stripped down:
- Management bodies must approve the cybersecurity risk management measures taken under Article 21
- Management bodies must oversee the implementation of those measures
- Management members can be held personally liable for infringements
- Management members must undergo cybersecurity training
- Organizations should offer regular training to employees
What this means in practice
Before NIS2, cybersecurity was something the IT department dealt with. The board received a quarterly report (maybe), and the topic rarely came up at leadership meetings unless something broke. Article 20 ends that arrangement.
Your board or executive management must:
- Formally approve your cybersecurity policies and risk management approach
- Receive regular briefings on cybersecurity posture and ongoing risks
- Complete cybersecurity training themselves - not just sign off that it happened, but actually attend
- Accept that if the organization fails to comply, they can be held responsible individually
I’ve seen this catch organizations off guard more than anything else in NIS2. The CTO or CISO can’t just handle it on their own. You need documented evidence that leadership approved the measures and stays involved.
Your checklist for Article 20
- Board or management body formally approved cybersecurity risk management measures (documented minutes or resolution)
- Regular cybersecurity briefings to management are scheduled and recorded (at least quarterly)
- Management members have completed cybersecurity training (with certificates or attendance records)
- Employee cybersecurity awareness training program is in place with participation tracking
- Roles and responsibilities for cybersecurity governance are defined and assigned
Article 21 - Cybersecurity risk management measures: the core requirements
This is the longest and most technical article. It’s where most of your implementation work will happen. Article 21 requires “appropriate and proportionate technical, operational and organisational measures” to manage risks. The proportionality language matters - a 50-person software company won’t be held to the same standard as a power grid operator.
Article 21(2) lists ten specific measure categories. Every NIS2-covered entity must implement all ten, scaled to their risk profile and size.
(a) Risk analysis and information system security policies
You need a written, approved information security policy that covers how you identify, assess, and treat cyber risks. This isn’t a generic policy downloaded from a template site. It should reflect your actual environment, your actual risks, and your actual decision making.
What to have ready:
- Information security policy (approved by management per Article 20)
- Risk assessment methodology document
- Risk register with identified threats, vulnerabilities, and treatment decisions
- Regular risk review cycle (at least annual, or triggered by significant changes)
Our risk assessment guide walks through how to build this in CISO Assistant. The free OWASP Risk Calculator can help you score individual threats consistently.
(b) Incident handling
You need a defined process for detecting, managing, responding to, and recovering from security incidents. This goes hand-in-hand with Article 23’s reporting obligations, but Article 21(b) is about your internal capability.
What to have ready:
- Incident response plan covering detection, containment, eradication, and recovery
- Defined severity levels and escalation procedures
- Roles and responsibilities for incident response team
- Post-incident review process
- Evidence of incident response testing (tabletop exercises or simulations, at least annually)
(c) Business continuity, backup management, disaster recovery, and crisis management
NIS2 lumps several related capabilities together here. You need plans for keeping your services running when something goes wrong, and plans for recovering when it goes very wrong.
What to have ready:
- Business continuity plan covering critical services
- Backup policy (what’s backed up, how often, where, retention period)
- Evidence that backups are tested regularly (restore tests)
- Disaster recovery plan with defined RTO (Recovery Time Objective) and RPO (Recovery Point Objective)
- Crisis management procedure (who decides what, communication chains)
If you haven’t defined your RTO and RPO yet, our free BIA Calculator helps you work through that process systematically.
(d) Supply chain security
This one trips up a lot of organizations. NIS2 requires you to secure not just your own systems but also the relationships with your direct suppliers and service providers. Article 21(3) adds that you must consider each supplier’s specific vulnerabilities, the overall quality of their products, and their cybersecurity practices - including secure development procedures.
What to have ready:
- Inventory of direct suppliers and service providers
- Risk assessment for each supplier (tiered by criticality)
- Cybersecurity requirements in supplier contracts
- Process for monitoring supplier security posture over time
- Evidence of supplier assessments (questionnaires, audit reports, certifications reviewed)
Our vendor security management guide covers the full process. The free Supplier Risk Assessment tool gives you a structured scoring framework.
(e) Security in network and information systems acquisition, development, and maintenance
This covers the entire lifecycle of your IT systems - from buying or building them, through operation, to decommissioning. It also explicitly includes vulnerability handling and disclosure.
What to have ready:
- Secure development policy (if you build software)
- Security requirements for new system acquisitions
- Vulnerability management process (scanning, patching, tracking)
- Coordinated vulnerability disclosure process
- Change management procedures that include security review
(f) Policies and procedures to assess the effectiveness of cybersecurity measures
In plain language: you need to check whether your security measures actually work. This means internal audits, security testing, metrics, or some combination.
What to have ready:
- Internal audit schedule for cybersecurity measures
- Penetration testing or security assessment results (at least annual for essential entities)
- Key risk indicators or security metrics that are reviewed regularly
- Process for acting on assessment findings (remediation tracking)
(g) Basic cyber hygiene practices and cybersecurity training
Beyond the management training required by Article 20, this covers everyone in the organization. “Basic cyber hygiene” is the directive’s way of saying: make sure people know the fundamentals.
What to have ready:
- Security awareness training program with regular sessions (not just onboarding)
- Training completion records for all staff
- Phishing simulation results (if applicable)
- Documented cyber hygiene standards (password policies, clean desk, device security)
(h) Policies on the use of cryptography and encryption
Where appropriate, you need policies governing how you use cryptography. “Where appropriate” depends on what data you handle and what systems you operate, but for most organizations covered by NIS2, encryption of data in transit and at rest is expected.
What to have ready:
- Cryptography and encryption policy
- Inventory of where encryption is applied (data at rest, in transit, end-to-end)
- Key management procedures
- Evidence of TLS/HTTPS enforcement across services
(i) Human resources security, access control policies, and asset management
Three topics bundled into one requirement. You need to know who has access to what, manage that access throughout the employee lifecycle, and maintain an inventory of your critical assets.
What to have ready:
- Access control policy (least privilege, role-based access)
- User provisioning and deprovisioning process (joiners, movers, leavers)
- Regular access reviews (at least annually for critical systems)
- IT asset inventory covering hardware, software, data assets, and critical infrastructure
- HR security procedures (background checks where applicable, security responsibilities in contracts)
Our asset management guide covers building an inventory that holds up under audit scrutiny.
(j) Multi-factor authentication and secured communications
The final measure requires MFA or continuous authentication “where appropriate,” plus secured voice, video, and text communications, and secured emergency communication systems.
What to have ready:
- MFA deployed on all critical systems, remote access, and privileged accounts
- Policy defining where MFA is required and exceptions (with risk justification)
- Secured communication channels for sensitive discussions
- Emergency communication system that works independently of primary systems (in case those are compromised)
Article 22 - EU-level coordinated supply chain risk assessments
Article 22 is less about what individual organizations must do and more about what happens at the EU level. The Cooperation Group (made up of member state representatives) can conduct coordinated risk assessments of critical supply chains when they identify a dependency that affects multiple member states.
What this means for your organization
You don’t initiate Article 22 assessments - the EU Cooperation Group does. But the results can affect you:
- If a coordinated assessment identifies risks in a supply chain you depend on, you may need to respond
- Article 21(3) explicitly references Article 22 - when considering your supply chain security measures, you must take into account the results of any coordinated assessments
- Sector-specific guidance may emerge from these assessments
In practice, keep an eye on ENISA publications and your national competent authority’s guidance. If a coordinated assessment touches a technology or supplier you rely on, factor those findings into your own risk assessments.
Your checklist for Article 22
- Monitor ENISA and national authority publications for coordinated supply chain risk assessment results
- Process for incorporating EU-level supply chain findings into your own supplier risk assessments
- Awareness of critical dependencies in your technology stack that could be subject to coordinated assessment
Article 23 - Reporting obligations: the 24/72/1-month timeline
Article 23 is where NIS2 creates the most operational pressure. When a “significant incident” occurs, you have strict reporting deadlines. There’s no flexibility on timing.
What counts as a significant incident?
An incident is significant if it:
- Has caused or is capable of causing severe operational disruption of the services or financial loss for the entity
- Has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage
The bar is not as high as you might think. A ransomware attack that encrypts production systems qualifies. A data breach exposing customer information qualifies. Even a near-miss that could have caused severe disruption may qualify under the “capable of causing” language.
The three-stage reporting process
| Stage | Deadline | What you must report |
|---|---|---|
| Early warning | 24 hours from awareness | Whether the incident is suspected to be unlawful or malicious; whether it could have cross-border impact |
| Incident notification | 72 hours from awareness | Initial severity assessment, impact assessment, indicators of compromise where applicable |
| Final report | 1 month from notification | Full root cause analysis, mitigation measures applied, cross-border impact details |
The 24-hour early warning is the one that catches people. You don’t need a complete picture - just a heads-up to your national CSIRT that something happened, whether it looks malicious, and whether it might spill across borders. Most organizations I work with don’t have a process that can reliably hit this window without prior planning.
For incidents affecting service delivery to recipients, the competent authority or CSIRT can also request intermediate progress reports between the 72-hour notification and the final report.
Who do you report to?
Your national CSIRT or the competent authority designated by your member state. This varies by country and sometimes by sector. Identify your reporting contact now, not during an incident.
For cross-border incidents, your CSIRT coordinates with others through the CSIRTs network.
Your checklist for Article 23
- Identified your national CSIRT and/or competent authority contact details
- Incident classification criteria defined (what qualifies as “significant” in your context)
- Reporting templates prepared for all three stages (early warning, notification, final report)
- Internal escalation procedure that can trigger the 24-hour early warning reliably
- Tested the reporting process at least once (even a dry run helps)
- Contact information for CSIRT stored somewhere accessible during a crisis (not only on a system that might be compromised)
Article 24 - Use of European cybersecurity certification schemes
Article 24 is forward-looking. It allows member states to require essential and important entities to use specific ICT products, services, or processes that are certified under the EU Cybersecurity Act’s certification framework (the framework managed by ENISA).
What this means today
As of early 2026, this article has limited practical impact for most organizations because few EU cybersecurity certification schemes are fully operational. The EU Common Criteria-based scheme (EUCC) is rolling out, and others are in development.
But the direction is clear: the EU wants to create a common market for certified cybersecurity products, and NIS2 gives member states the tool to require their use.
Your checklist for Article 24
- Awareness of EU cybersecurity certification schemes relevant to your sector
- Procurement policies that consider certified products where available
- Process for monitoring new certification requirements from your national authority
Article 25 - Standardisation
Article 25 encourages (but doesn’t mandate) the use of European and international standards for implementing Article 21 requirements. The Commission can adopt implementing acts specifying technical and methodological requirements.
What this means for you
This article gives you helpful guidance on how to implement Article 21. If you follow recognized standards like ISO 27001, IEC 62443 (for industrial systems), or ETSI standards, you’re likely meeting the intent of Article 21’s “state of the art” requirement.
The implementing act adopted under Article 21(5) for digital service providers (cloud, DNS, CDN, managed services, online marketplaces, search engines, social platforms, trust services) sets specific technical requirements. If you fall in one of those categories, check the implementing regulation for your sector.
Your checklist for Article 25
- Identified relevant standards for your sector (ISO 27001, IEC 62443, ETSI, etc.)
- Mapped your current compliance to those standards
- Monitoring for implementing acts that may set specific requirements for your entity type
Mapping NIS2 articles to ISO 27001
If you already have ISO 27001 in place, you don’t start from scratch. Here’s where the requirements line up and where NIS2 goes further:
| NIS2 Requirement | ISO 27001 Coverage | Gap to fill |
|---|---|---|
| Art. 20 - Management approval and oversight | Clause 5.1 Leadership commitment | NIS2 adds personal liability; ISO 27001 does not |
| Art. 21(a) - Risk analysis policies | Clause 6.1.2 Risk assessment | Good overlap; NIS2 is less prescriptive on methodology |
| Art. 21(b) - Incident handling | A.5.24-A.5.28 Incident management | NIS2 adds mandatory external reporting timelines |
| Art. 21(c) - Business continuity | A.5.29-A.5.30 BCM | Good overlap |
| Art. 21(d) - Supply chain security | A.5.19-A.5.23 Supplier relations | NIS2 requires deeper supplier assessment |
| Art. 21(e) - System lifecycle security | A.8.25-A.8.31 Development security | Good overlap |
| Art. 21(f) - Effectiveness assessment | Clause 9 Performance evaluation | Good overlap |
| Art. 21(g) - Training and hygiene | A.6.3 Awareness training | Good overlap |
| Art. 21(h) - Cryptography | A.8.24 Cryptography | Good overlap |
| Art. 21(i) - Access control and assets | A.5.15-A.5.18, A.5.9 | Good overlap |
| Art. 21(j) - MFA and secure comms | A.8.5 Authentication | NIS2 is more explicit about MFA and emergency comms |
| Art. 23 - Incident reporting | Not covered | Entirely new requirement: 24h/72h/1mo reporting |
The gaps are concentrated in three areas: management personal liability, mandatory incident reporting to external authorities, and deeper supply chain assessment requirements. If you’re ISO 27001 certified and address those three, you’re in strong shape for NIS2.
For the full control-by-control mapping with specific Annex A references and a practical implementation roadmap, see our guide on implementing NIS2 using your existing ISO 27001 controls. For a structured gap analysis, our free ISO 27001 Gap Analysis tool helps you assess your current state against Annex A controls - and you can overlay NIS2 requirements to see where you need additional work.
Putting it all together
Here’s a condensed master checklist. If you can check off everything here, you have the evidence base for NIS2 compliance:
Governance (Article 20)
- Management-approved cybersecurity policy
- Regular management briefings on cybersecurity
- Management cybersecurity training records
- Employee awareness training program
Risk management (Article 21)
- Risk assessment methodology and risk register
- Incident response plan (tested)
- Business continuity and disaster recovery plans (tested)
- Supplier security assessment program
- Vulnerability management process
- Internal audit or assessment program
- Cybersecurity training records for all staff
- Cryptography and key management policy
- Access control policy and regular access reviews
- IT asset inventory
- MFA on critical systems and remote access
- Secured communication channels
Incident reporting (Article 23)
- National CSIRT contact identified
- Incident classification criteria defined
- Reporting templates for all three stages
- Internal escalation process tested
Supply chain (Articles 21(d) and 22)
- Supplier inventory with risk tiers
- Security requirements in contracts
- Process for incorporating EU coordinated assessment results
Standards and certification (Articles 24-25)
- Relevant standards identified and mapped
- Monitoring for sector-specific implementing acts
Where to go from here
If you’ve been using this checklist as a gap analysis, you probably found areas that need work. That’s normal - most organizations I work with have 60-70% of these requirements partially addressed through existing practices. The work is in formalizing, documenting, and connecting those practices into a coherent program.
Start with the gaps that carry the most risk: incident reporting readiness (because the 24-hour timeline is unforgiving), management governance (because personal liability focuses attention), and supply chain assessments (because they take the longest to build).
For hands-on implementation, load the NIS2 framework in CISO Assistant and assess each requirement against your current state. The platform maps NIS2 requirements to ISO 27001 controls, so if you’re already working on ISO 27001, you can see exactly where you have coverage and where you don’t.
If you want to score your readiness quickly before diving into the details, our NIS2 Readiness Assessment gives you a domain-by-domain breakdown in about 15 minutes. And if you need help building a compliance roadmap that covers NIS2 alongside ISO 27001 or other frameworks, that’s what we do.
