NIS2 Directive Technical Compliance Checklist: What You Actually Need to Implement
NIS2 took effect across EU member states in October 2024. The directive's language -- 'appropriate and proportionate technical and organisational measures' -- is intentionally broad, which means security teams are left to determine what that means for their specific organization. This checklist translates the key articles of NIS2 into specific technical controls with implementation status tracking. It is not legal advice; have your legal team confirm applicability and national-law variations.
Is Your Organization In Scope? Quick Applicability Check
Before implementing anything, confirm scope. NIS2 applies if your organization meets ALL of the following:
Step 1: Sector check Are you operating in one of these sectors?
- Essential sectors: Energy, Transport, Banking, Financial market infrastructure, Health, Drinking water, Wastewater, Digital infrastructure (DNS, TLDs, cloud, data centers, CDN, TSP, electronic communications), ICT service management (B2B), Public administration, Space
- Important sectors: Postal and courier services, Waste management, Chemicals, Food, Manufacturing (medical devices, computers, electronics, machinery, motor vehicles), Digital providers (online marketplaces, search engines, social networks), Research institutions
Step 2: Size check Medium entity or larger: 50+ employees OR EUR 10M+ annual turnover (Some categories apply regardless of size: TLDs, DNS providers, cloud providers, certain digital infrastructure operators)
Step 3: Geography check Established in the EU, OR providing services to EU essential/important entities from outside the EU (in which case you must designate an EU representative)
If all three apply: NIS2 applies. Continue with this checklist. If uncertain: Engage legal counsel in the relevant EU member state(s). Member states vary in how they've transposed NIS2 into national law.
Article 21: Technical and Organisational Measures -- Control Mapping
Article 21 is the core technical requirement. It mandates an all-hazards approach covering the following (Article 21(2) a-j):
a) Risk analysis and information system security policies
| Required | Specific control | Implementation status |
|---|---|---|
| Risk analysis process | Documented risk assessment methodology, reviewed annually | ☐ Not started / ☐ In progress / ☐ Complete |
| Information security policy | Written, board-approved information security policy | ☐ / ☐ / ☐ |
| Policy review cycle | Annual review of policy, documented evidence | ☐ / ☐ / ☐ |
b) Incident handling
| Required | Specific control | Implementation status |
|---|---|---|
| Incident detection | SIEM or log aggregation with alerting capability | ☐ / ☐ / ☐ |
| Incident response plan | Written IR plan with defined roles, escalation, and containment procedures | ☐ / ☐ / ☐ |
| Incident logging | Centralized log retention for minimum 12 months | ☐ / ☐ / ☐ |
| Incident classification | Written definition of what constitutes a 'significant incident' triggering notification | ☐ / ☐ / ☐ |
| IR team/retainer | Named IR contact or external IR retainer with 24/7 availability | ☐ / ☐ / ☐ |
c) Business continuity and crisis management
| Required | Specific control | Implementation status |
|---|---|---|
| BCP/DR plan | Written business continuity and disaster recovery plan | ☐ / ☐ / ☐ |
| Backup and recovery | Automated backups with tested restoration; documented RTO/RPO | ☐ / ☐ / ☐ |
| Backup testing | Backup restore test completed within the last 12 months | ☐ / ☐ / ☐ |
| Crisis management | Defined crisis management process with named decision makers | ☐ / ☐ / ☐ |
d) Supply chain security
| Required | Specific control | Implementation status |
|---|---|---|
| Critical vendor inventory | List of all vendors with access to systems or data, classified by criticality | ☐ / ☐ / ☐ |
| Vendor security assessments | Security questionnaire or assessment for all critical vendors | ☐ / ☐ / ☐ |
| Contractual security requirements | Written security requirements in vendor contracts (right to audit, breach notification, data handling) | ☐ / ☐ / ☐ |
| Vendor access controls | Just-in-time or scoped access for vendors; no persistent admin access | ☐ / ☐ / ☐ |
e) Security in network and information systems acquisition, development and maintenance
| Required | Specific control | Implementation status |
|---|---|---|
| Secure development | Secure SDLC process documented and followed | ☐ / ☐ / ☐ |
| Vulnerability management | Defined process for tracking and remediating CVEs in used software | ☐ / ☐ / ☐ |
| Patch management | SLA-based patching: Critical <7 days, High <30 days | ☐ / ☐ / ☐ |
| Security testing | Penetration testing or vulnerability scanning, at least annually | ☐ / ☐ / ☐ |
f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
| Required | Specific control | Implementation status |
|---|---|---|
| Security metrics program | Defined KPIs tracked and reported to management | ☐ / ☐ / ☐ |
| Internal audit | Annual internal security audit or review | ☐ / ☐ / ☐ |
| Management review | Security posture reviewed by senior management at least annually | ☐ / ☐ / ☐ |
g) Basic cyber hygiene practices and cybersecurity training
| Required | Specific control | Implementation status |
|---|---|---|
| Security awareness training | Annual security awareness training for all employees | ☐ / ☐ / ☐ |
| Role-based training | Additional training for IT staff, developers, and executives | ☐ / ☐ / ☐ |
| Cyber hygiene baseline | MFA, password manager, endpoint protection, software update policy | ☐ / ☐ / ☐ |
h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption
| Required | Specific control | Implementation status |
|---|---|---|
| Encryption at rest | Sensitive data encrypted at rest (AES-256 or equivalent) | ☐ / ☐ / ☐ |
| Encryption in transit | TLS 1.2+ for all internal and external data transmission | ☐ / ☐ / ☐ |
| Certificate management | Certificate expiry monitoring; automated renewal where possible | ☐ / ☐ / ☐ |
| Key management policy | Written policy for cryptographic key generation, storage, rotation, and destruction | ☐ / ☐ / ☐ |
i) Human resources security, access control policies and asset management
| Required | Specific control | Implementation status |
|---|---|---|
| Access control policy | Written policy: least privilege, role-based access, review schedule | ☐ / ☐ / ☐ |
| Privileged access management | MFA for all admin accounts; privileged account inventory | ☐ / ☐ / ☐ |
| Access review | Quarterly or semi-annual access rights review | ☐ / ☐ / ☐ |
| Offboarding process | Documented process to revoke all access within 24 hours of employee departure | ☐ / ☐ / ☐ |
| Asset inventory | Comprehensive inventory of hardware, software, and data assets | ☐ / ☐ / ☐ |
j) The use of multi-factor authentication or continuous authentication solutions, secure voice, video and text communications and secured emergency communication systems
| Required | Specific control | Implementation status |
|---|---|---|
| MFA for all users | MFA enforced on all user accounts accessing company systems | ☐ / ☐ / ☐ |
| MFA for privileged access | Phishing-resistant MFA (hardware key or passkey) for admin accounts | ☐ / ☐ / ☐ |
| Secure communications | Encrypted channels for sensitive internal communications | ☐ / ☐ / ☐ |
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Article 23: Incident Reporting -- What to Build Before You Need It
Article 23 requires a three-stage reporting process. Build the infrastructure for this before an incident occurs.
Stage 1: Early warning (within 24 hours of awareness)
What to send:
- Date and time of detection
- Nature of the incident (brief description; no full analysis required)
- Whether the incident is suspected to involve unlawful or malicious acts
- Whether the incident has potential cross-border impact
- Affected services (brief)
Who to send it to: Your national NIS2 competent authority (varies by member state and sector). Find yours at: https://www.enisa.europa.eu/topics/incident-response/nis-cooperation/certs-in-europe
Stage 2: Incident notification (within 72 hours)
What to add:
- Initial assessment: severity and impact
- Indicators of compromise if available
- Whether the incident is ongoing
- Affected systems and services
- Estimated number of users affected
Stage 3: Final report (within 1 month)
What to include:
- Detailed description of the incident
- Type of threat or root cause
- Applied mitigation measures and those that are ongoing
- Cross-border impact assessment
- Actions taken to prevent recurrence
Build these templates in advance:
# /ir-templates/nis2-early-warning.md
# /ir-templates/nis2-incident-notification.md
# /ir-templates/nis2-final-report.md
Include your competent authority's contact information, preferred submission method (web form, email, or secure portal), and the name of the person authorized to submit notifications in your IR plan.
What constitutes a 'significant incident' requiring notification: Define this in your IR plan before an incident occurs:
Significant incident triggers (examples -- adapt to your sector):
- Service unavailability affecting >X% of users for >Y hours
- Confirmed unauthorized access to systems containing customer data
- Ransomware encryption of production systems
- Confirmed data exfiltration of any volume of sensitive data
- Any incident requiring public disclosure under other regulatory frameworks
(GDPR, financial regulations, etc.)
Management Accountability Under Article 20
NIS2 Article 20 is frequently overlooked: management bodies (board of directors, executive teams) are personally responsible for approving cybersecurity risk management measures and monitoring their implementation. They can be held personally liable for non-compliance.
What this means for security teams:
| Requirement | How to implement |
|---|---|
| Management approves security measures | Get board/exec sign-off on your information security policy, risk management approach, and significant security investments |
| Management monitors implementation | Quarterly security reporting to board or executive team (see board report template guide) |
| Management training | Board members must complete cybersecurity training; document completion |
| Liability for non-compliance | Management cannot delegate accountability away; they can delegate implementation |
Practical steps:
- Get your security policy formally approved by the board with signatures and date
- Establish quarterly board-level security reporting (see the CISO board report guide)
- Schedule annual cybersecurity briefing for board members (even 60 minutes annually satisfies the training requirement if documented)
- Create a paper trail: every significant security decision should have an email or meeting record showing executive awareness and approval
Gap Assessment Template: Tracking Your NIS2 Implementation
Use this to track progress and present to management.
Organization: [NAME]
Assessment date: [DATE]
Assessor: [NAME, TITLE]
Next review: [DATE + 6 months]
OVERALL STATUS:
Controls fully implemented: ___ / ___ (___% complete)
Controls in progress: ___
Controls not started: ___
Controls not applicable: ___
CRITICAL GAPS (any Not started with High/Critical risk rating):
1. [CONTROL] -- [TARGET DATE] -- [OWNER]
2. [CONTROL] -- [TARGET DATE] -- [OWNER]
ROADMAP SUMMARY:
Q[X] 2026 (immediate): Complete all incident reporting infrastructure
Q[X+1] 2026: Supply chain vendor assessments, access review, backup testing
Q[X+2] 2026: Management training, internal audit, policy reviews
Q[X+3] 2026: Full compliance review; engage external auditor or consultant
NOTES:
[National law variations relevant to your member state]
[Sector-specific guidance issued by your competent authority]
[Date of last legal review confirming applicability]
The bottom line
NIS2 is less prescriptive than PCI-DSS and more outcome-focused than ISO 27001. 'Appropriate and proportionate measures' means your controls should match your risk profile and sector. A small health sector organization and a large cloud provider face the same directive but implement it very differently. Map what you have against Article 21's ten categories, build your incident reporting infrastructure before you need it, and get management accountability documented before an enforcement inspection arrives.
Frequently asked questions
Who does NIS2 apply to?
NIS2 applies to medium and large organizations operating in sectors deemed critical by the EU: energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space. Medium means 50+ employees or EUR 10M+ annual turnover. The directive also extends to postal services, waste management, chemicals, food, manufacturing, digital providers, and research. If you operate in the EU or provide services to EU entities in these sectors, consult legal counsel to confirm applicability to your specific situation.
What is the difference between 'essential entities' and 'important entities' under NIS2?
Essential entities (EE) are subject to proactive supervision: the competent authority can conduct audits and inspections without an incident trigger. Important entities (IE) face reactive supervision: oversight is typically triggered by an incident or complaint. Fines differ: EE maximum is EUR 10M or 2% of global turnover; IE maximum is EUR 7M or 1.4% of global turnover. Both face the same technical requirements -- the difference is supervision intensity and fine levels.
What does NIS2 require for incident notification?
Article 23 requires a three-stage notification process: (1) Early warning within 24 hours of becoming aware of a significant incident -- basic facts, no investigation required yet. (2) Incident notification within 72 hours -- assessment of impact, severity, indicators of compromise. (3) Final report within one month -- full description, root cause, cross-border impact assessment, remediation measures. 'Significant incident' means one that causes or can cause severe operational disruption or financial loss. Define your severity threshold in your IR plan now.
Does NIS2 require specific security certifications?
NIS2 does not mandate specific certifications like ISO 27001 or SOC 2. However, EU cybersecurity certification schemes (under ENISA) may be recognized as evidence of compliance with NIS2's technical requirements. Practically, organizations that already have ISO 27001 certification have significant overlap with NIS2's requirements -- map your existing ISMS controls to NIS2 Articles 21 and 23 before assuming gaps.
What is 'all-hazards approach' in NIS2 Article 21?
Article 21 requires security measures covering all relevant hazards, not just cyber threats. This includes physical security (protecting network and information systems from physical access), environmental risks (flood, fire, power failure), and supply chain risks (third-party providers). In practice: your security program must address physical access controls for server rooms, business continuity for non-cyber disruptions, and vendor security assessments -- not just network and application security.
How does NIS2 handle supply chain security?
Article 21(2)(d) explicitly requires organizations to address security in supply chains, including the security practices of direct suppliers and service providers. This means: vendor security questionnaires or assessments for critical suppliers, contractual security requirements in vendor agreements, and an inventory of critical dependencies. You are responsible for the security posture of vendors with access to your systems or data -- 'we relied on our vendor' is not a defense under NIS2.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.