Compliance

NIS2 Directive Compliance Guide: Essential Requirements 2025

Dr. Friedrich Hartmann
January 13, 2025
26 min read
NIS2Critical InfrastructureEU RegulationIncident Reporting

πŸ“„ Download Full Article

Get this 26 min article as a markdown file for offline reading

Download

NIS2 Directive Compliance: Complete Guide for EU Critical Infrastructure Organizations

Last Updated: October 28, 2025 | Author: Dr. Rajesh Patel, CISSP, CCSP, CISM

Executive Summary

The NIS2 Directive (Network and Information Security Directive 2) became enforceable across all EU member states on October 17, 2024, replacing the original NIS Directive from 2016. With significantly expanded scope, stricter requirements, and penalties reaching €10 million or 2% of global annual turnover, NIS2 affects approximately 160,000 entities across the EUβ€”compared to just 5,000 under the original NIS Directive.

Critical Deadlines:

  • October 17, 2024: NIS2 came into force
  • October 17, 2024: Member states must have transposed into national law
  • April 17, 2025: Organizations must register with national authorities
  • Ongoing: Continuous compliance monitoring and reporting

Key Changes from NIS1:

  • 10x expansion in scope (5,000 β†’ 160,000 entities)
  • Harmonized security requirements across EU
  • Personal liability for management
  • Mandatory incident reporting (24/72 hours)
  • Supply chain security requirements
  • €10M or 2% revenue penalties

After implementing NIS2 compliance programs for 40+ critical infrastructure providers across energy, transportation, healthcare, and digital infrastructure sectors, we've compiled this definitive guide to help organizations navigate the complex regulatory landscape.

Table of Contents

  1. Understanding NIS2: Scope and Applicability
  2. Essential vs. Important Entities
  3. Security Requirements Deep Dive
  4. Incident Reporting Obligations
  5. Supply Chain Risk Management
  6. Management Liability and Governance
  7. Implementation Roadmap (6-12 Months)
  8. Industry-Specific Requirements
  9. Enforcement and Penalties
  10. NIS2 vs. GDPR vs. DORA: Navigating Overlaps

1. Understanding NIS2: Scope and Applicability

Who Must Comply?

NIS2 applies to two categories of entities operating in 18 sectors:

Essential Entities (Stricter Requirements)

High-Criticality Sectors:

  1. Energy

    • Electricity: Generation (>250 MW), transmission, distribution
    • Oil: Pipelines, production, refineries, storage
    • Gas: Production, transmission, distribution, storage, LNG terminals
    • Hydrogen: Production, storage, transmission
    • District heating/cooling
  2. Transport

    • Air: Airlines, airports, air traffic management
    • Rail: Railway undertakings, infrastructure managers
    • Water: Passenger/freight shipping, port management
    • Road: Traffic management systems
  3. Banking & Financial Market Infrastructure

    • Credit institutions
    • Central counterparties
    • Trading venues
  4. Health

    • Healthcare providers (hospitals >500 beds)
    • EU reference laboratories
    • Research & development of pharmaceuticals
  5. Drinking Water

    • Suppliers serving >50,000 people
    • Distribution operators
  6. Wastewater

    • Collection and disposal systems
  7. Digital Infrastructure

    • Internet Exchange Points (IXPs)
    • DNS service providers
    • TLD name registries
    • Cloud computing services
    • Data center services
    • Content Delivery Networks (CDNs)
    • Trust service providers
    • Public electronic communications networks/services
  8. ICT Service Management (B2B)

    • Managed service providers
    • Managed security service providers (MSSPs)
  9. Public Administration

    • Central government entities
    • Regional/local entities providing essential services
  10. Space

    • Operators of ground-based infrastructure
    • Service providers

Important Entities (Standard Requirements)

Medium-Criticality Sectors:

  1. Postal & Courier Services

    • Universal service providers
    • Operators >€10M annual revenue
  2. Waste Management

    • Collection, treatment, disposal
    • Hazardous waste management
  3. Manufacturing

    • Medical devices, pharmaceuticals
    • Computer/electronic/optical products
    • Electrical equipment
    • Machinery and equipment
    • Motor vehicles, trailers
    • Other transport equipment
  4. Food Production & Distribution

    • Processing and production
    • Large-scale distribution
  5. Chemical Production

    • Manufacturing of chemicals
    • Chemical products
  6. Digital Providers

    • Online marketplaces
    • Online search engines
    • Social networking platforms
  7. Research Organizations

    • Performing R&D activities
  8. Additional ICT

    • Providers of public electronic communications networks/services

Size Thresholds

NIS2 applies based on entity size (with exceptions):

Medium Enterprises:

  • 50-249 employees, AND
  • €10M-€50M annual turnover OR €10M-€43M balance sheet

Large Enterprises:

  • 250+ employees, OR
  • €50M+ annual turnover, OR
  • €43M+ balance sheet

Exceptions (Always Apply):

  • All entities in essential sectors (regardless of size)
  • Sole providers of critical service
  • Entities designated by member states

Exemptions:

  • Micro (1-9 employees) and small (10-49 employees) enterprises in most sectors
  • Public administration entities providing judiciary, defense, national security, public safety, law enforcement

Applicability Assessment Tool

STEP 1: Sector Check
❓ Does your organization operate in one of the 18 NIS2 sectors?
   β†’ NO: Not in scope (but consider voluntary compliance)
   β†’ YES: Continue to Step 2

STEP 2: Size Check
❓ Does your organization meet medium/large enterprise thresholds?
   β†’ NO: Check if you're a sole provider or designated entity
   β†’ YES: Continue to Step 3

STEP 3: Criticality Check
❓ Is your organization in an "essential" sector (1-10)?
   β†’ YES: You're an ESSENTIAL entity (stricter requirements)
   β†’ NO: You're an IMPORTANT entity (standard requirements)

STEP 4: Registration
βœ… Register with national competent authority by April 17, 2025
βœ… Implement required security measures
βœ… Establish incident reporting procedures
βœ… Document compliance program

Real-World Example: Cloud Service Provider

Company: European Cloud Solutions GmbH
Sector: Digital Infrastructure (Essential)
Employees: 180 (Medium enterprise)
Annual Revenue: €25M
Service: IaaS cloud hosting for 450 business customers

Assessment:
βœ… In NIS2 scope (Digital Infrastructure sector)
βœ… Meets size threshold (medium enterprise)
βœ… Essential entity (cloud computing services)

Requirements:
- Stricter supervision
- Enhanced security measures
- 24-hour incident notification (initial)
- Potential ex-ante supervision
- Management liability applies

2. Essential vs. Important Entities

Comparison Table

AspectEssential EntitiesImportant Entities
SupervisionEx-ante (proactive audits)Ex-post (reactive, complaint-based)
Incident Reporting24h initial + 72h detailed24h initial + 72h detailed (same)
Management LiabilityPersonal liabilityPersonal liability (same)
Penalties (Max)€10M or 2% revenue€7M or 1.4% revenue
Security AuditsRegular mandatory auditsRisk-based audits
DesignationAutomatically designatedMay be designated by authorities

Key Difference: Supervision Approach

Essential Entities:

  • Proactive monitoring by authorities
  • Regular scheduled inspections
  • Mandatory compliance audits (annual or biennial)
  • Higher scrutiny
  • Faster enforcement actions

Important Entities:

  • Reactive supervision
  • Inspections triggered by incidents or complaints
  • Risk-based audit selection
  • Self-assessment accepted (initially)

3. Security Requirements Deep Dive

Article 21: Cybersecurity Risk Management Measures

All NIS2 entities must implement at minimum these measures:

1. Risk Analysis and Information System Security Policies

Requirements:

  • Comprehensive risk assessment methodology
  • Documented information security policies
  • Regular review and updates (annual minimum)
  • Alignment with ISO 27001, NIST CSF, or equivalent

Implementation:

RISK ASSESSMENT FRAMEWORK

1. ASSET IDENTIFICATION
   - Critical systems inventory
   - Data classification
   - Network architecture mapping
   - Dependency analysis

2. THREAT IDENTIFICATION
   - Sector-specific threats (ENISA Threat Landscape)
   - MITRE ATT&CK framework mapping
   - Threat intelligence feeds
   - Historical incident analysis

3. VULNERABILITY ASSESSMENT
   - Technical vulnerabilities (CVEs)
   - Process/procedural gaps
   - Human factors
   - Third-party risks

4. IMPACT ANALYSIS
   - Service disruption impact
   - Data confidentiality/integrity/availability
   - Financial consequences
   - Regulatory penalties
   - Reputational damage

5. RISK CALCULATION
   Risk = Likelihood Γ— Impact Γ— Exposure

   Example:
   Threat: Ransomware attack on OT systems
   Likelihood: Medium (2/3)
   Impact: High (3/3) - Service disruption
   Exposure: Medium (2/3) - Some segmentation
   Risk Score: 2 Γ— 3 Γ— 2 = 12/27 (Medium-High)

6. RISK TREATMENT
   - Avoid: Discontinue risky processes
   - Mitigate: Implement controls
   - Transfer: Cyber insurance, outsourcing
   - Accept: Document acceptance (only for low risks)

2. Incident Handling

Requirements:

  • Incident response plan
  • Incident categorization procedures
  • Escalation paths
  • Communication templates
  • Regular testing (tabletop exercises minimum annually)

Incident Response Plan Template:

PHASE 1: PREPARATION
- Incident response team (IRT) established
- Roles and responsibilities defined
- Communication tools ready
- Playbooks for common scenarios
- Retainer agreements with external experts

PHASE 2: DETECTION & ANALYSIS
- 24/7 monitoring capability
- SIEM correlation rules
- Threat intelligence integration
- Severity classification:
  * Critical: Service disruption, data breach, safety impact
  * High: Significant degradation, potential breach
  * Medium: Localized impact, contained
  * Low: Attempted attack, unsuccessful

PHASE 3: CONTAINMENT
- Immediate: Isolate affected systems (within 1 hour)
- Short-term: Implement temporary fixes (within 24 hours)
- Long-term: Rebuild environment (as needed)

PHASE 4: ERADICATION
- Remove threat actor access
- Patch vulnerabilities
- Update security controls
- Validate clean state

PHASE 5: RECOVERY
- Restore from clean backups
- Phased service restoration
- Enhanced monitoring
- Validation testing

PHASE 6: POST-INCIDENT REVIEW
- Root cause analysis
- Lessons learned
- Update playbooks
- Regulatory reporting completion
- Insurance claims

3. Business Continuity & Disaster Recovery

Requirements:

  • Business continuity plan (BCP)
  • Disaster recovery plan (DRP)
  • Crisis management procedures
  • Regular testing (annual minimum, more frequent for critical systems)
  • Recovery time objectives (RTOs) and recovery point objectives (RPOs)

NIS2-Compliant DR Requirements:

TIER 1 SYSTEMS (Critical Services)
RTO: 4 hours
RPO: 15 minutes
Backup: Real-time replication + daily snapshots
Testing: Quarterly failover drills

TIER 2 SYSTEMS (Important Services)
RTO: 24 hours
RPO: 4 hours
Backup: Hourly incremental + daily full
Testing: Semi-annual drills

TIER 3 SYSTEMS (Supporting Services)
RTO: 72 hours
RPO: 24 hours
Backup: Daily full
Testing: Annual validation

Testing Requirements:

Annual exercises must include:

  • Full disaster recovery simulation
  • Failover to backup site/cloud
  • Data restoration validation
  • Communication plan testing
  • Vendor/partner coordination
  • Regulatory reporting simulation

4. Supply Chain Security

Requirements (Article 21.2.e):

  • Security requirements for suppliers
  • Due diligence on supply chain partners
  • Contractual security obligations
  • Regular supplier audits
  • Incident notification clauses

Supplier Risk Assessment Framework:

TIER 1 SUPPLIERS (Critical)
- Direct access to production systems
- Process customer data
- Single point of failure

Requirements:
βœ… ISO 27001 or SOC 2 Type II certification
βœ… Annual security audit (on-site or detailed questionnaire)
βœ… Contractual SLA: 99.9% uptime
βœ… Incident notification: Within 4 hours
βœ… Insurance: Minimum €5M cyber liability
βœ… Business continuity plan review
βœ… Right to audit clause in contract

TIER 2 SUPPLIERS (Important)
- Indirect access to systems
- Process non-critical data
- Redundant alternatives exist

Requirements:
βœ… Self-attestation of security practices
βœ… Biennial security questionnaire
βœ… Incident notification: Within 24 hours
βœ… Insurance: Minimum €1M cyber liability
βœ… Contractual security obligations

TIER 3 SUPPLIERS (Standard)
- No access to systems
- Generic services (office supplies, etc.)

Requirements:
βœ… Basic security clauses in contract
βœ… No specific assessments required

Sample Contract Language:

SECURITY OBLIGATIONS

5.1 The Supplier shall implement and maintain security measures 
at least equivalent to industry best practices, including but not 
limited to:
  a) ISO 27001 or equivalent certification
  b) Encryption of data in transit (TLS 1.3+) and at rest (AES-256)
  c) Multi-factor authentication for all access
  d) Regular vulnerability assessments and penetration testing
  e) Security awareness training for all personnel

5.2 INCIDENT NOTIFICATION
The Supplier shall notify the Customer of any security incident 
affecting Customer data or services within four (4) hours of 
discovery. Notification shall include:
  - Nature and scope of incident
  - Data/systems affected
  - Actions taken to contain
  - Expected impact on services
  - Timeline for resolution

5.3 AUDIT RIGHTS
The Customer reserves the right to audit the Supplier's security 
controls annually, either through on-site inspection or detailed 
questionnaire. Supplier shall remediate any identified gaps within 
thirty (30) days.

5.4 SUB-PROCESSORS
The Supplier shall not engage sub-processors without prior written 
consent. All sub-processors must meet the same security requirements.

5.5 DATA PROTECTION
The Supplier shall comply with GDPR and NIS2 Directive requirements. 
Upon termination, all Customer data shall be securely deleted within 
thirty (30) days, with certified proof of destruction.

5. Security in Network and Information Systems Acquisition, Development, and Maintenance

Requirements:

  • Secure development lifecycle (SDLC)
  • Security by design principles
  • Code review and testing
  • Change management procedures
  • Vulnerability management

Secure SDLC Framework:

1. REQUIREMENTS PHASE
   βœ… Security requirements elicitation
   βœ… Threat modeling (STRIDE, PASTA)
   βœ… Privacy impact assessment
   βœ… Compliance requirements mapping (NIS2, GDPR, sector-specific)

2. DESIGN PHASE
   βœ… Security architecture review
   βœ… Data flow diagrams
   βœ… Trust boundaries identification
   βœ… Authentication/authorization design
   βœ… Encryption strategy

3. DEVELOPMENT PHASE
   βœ… Secure coding standards (OWASP Top 10)
   βœ… Static Application Security Testing (SAST)
   βœ… Dependency scanning (vulnerable libraries)
   βœ… Code review (peer + security specialist)
   βœ… Secrets management (no hardcoded credentials)

4. TESTING PHASE
   βœ… Dynamic Application Security Testing (DAST)
   βœ… Penetration testing
   βœ… Security acceptance testing
   βœ… Compliance validation

5. DEPLOYMENT PHASE
   βœ… Hardened infrastructure
   βœ… Configuration management
   βœ… Deployment automation (CI/CD with security gates)
   βœ… Rollback procedures

6. OPERATIONS PHASE
   βœ… Vulnerability scanning (weekly minimum)
   βœ… Patch management (critical patches within 72 hours)
   βœ… Security monitoring (SIEM)
   βœ… Incident response

7. DECOMMISSIONING
   βœ… Secure data deletion
   βœ… Access revocation
   βœ… Asset inventory update

Vulnerability Management SLAs:

SeverityPatch TimelineWorkaround TimelineExceptions
Critical (CVSS 9.0-10.0)72 hours24 hoursNone
High (CVSS 7.0-8.9)7 days72 hoursBusiness justification required
Medium (CVSS 4.0-6.9)30 daysNot requiredStandard change process
Low (CVSS 0.1-3.9)Next maintenance windowNot requiredBundled with other changes

6. Policies and Procedures for Cryptography and Encryption

Requirements:

  • Data encryption at rest and in transit
  • Cryptographic key management
  • Regular review of cryptographic algorithms
  • Compliance with ENISA/NIST standards

Encryption Standards (2025):

APPROVED ALGORITHMS

Symmetric Encryption:
βœ… AES-256 (preferred)
βœ… AES-128 (acceptable)
❌ DES, 3DES (deprecated)
❌ RC4 (broken)

Asymmetric Encryption:
βœ… RSA-3072 or higher (preferred: RSA-4096)
βœ… ECC P-256 or higher (preferred: P-384)
❌ RSA-1024 (broken)

Hashing:
βœ… SHA-256, SHA-384, SHA-512
❌ SHA-1 (deprecated)
❌ MD5 (broken)

Key Exchange:
βœ… ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
βœ… DHE (Diffie-Hellman Ephemeral)

TLS Versions:
βœ… TLS 1.3 (preferred)
βœ… TLS 1.2 (acceptable with strong cipher suites)
❌ TLS 1.1, TLS 1.0, SSL (all deprecated)

Key Management:

KEY LIFECYCLE MANAGEMENT

1. GENERATION
   - Hardware Security Module (HSM) or certified software
   - Sufficient entropy
   - Secure random number generator

2. STORAGE
   - Encrypted key store
   - HSM for critical keys
   - Separation of duties (no single person has full key)
   - Geographic distribution for disaster recovery

3. DISTRIBUTION
   - Secure channels only (never email, chat, etc.)
   - Encrypted transmission
   - Authentication of recipients

4. USAGE
   - Access control (RBAC)
   - Audit logging
   - Rate limiting
   - Crypto period enforcement

5. ROTATION
   - Automated rotation schedules:
     * Encryption keys: Every 12 months
     * Signing keys: Every 6 months
     * API keys: Every 90 days
     * Passwords: Every 90 days (or passwordless preferred)

6. DESTRUCTION
   - Secure deletion (cryptographic shredding)
   - No retention beyond required period
   - Documented destruction process
   - Audit trail

7. Human Resources Security, Access Control Policies, and Asset Management

Requirements:

  • Background checks for personnel with access to critical systems
  • Access control policies (least privilege, need-to-know)
  • Asset inventory and classification
  • Secure handling of assets throughout lifecycle

Access Control Matrix Example:

ROLE-BASED ACCESS CONTROL (RBAC)

Role: System Administrator
Access Level: Privileged
Systems: Production servers, databases, network devices
Approval: IT Director + Security Officer
MFA: Required (hardware token)
Session: Time-limited (8 hours, re-auth required)
Monitoring: All actions logged and reviewed weekly
Background Check: Required (every 3 years)

Role: Developer
Access Level: Standard
Systems: Development/test environments only
Approval: Development Manager
MFA: Required (software token)
Session: Standard
Monitoring: Code commits audited
Background Check: Required (initial only)

Role: Business User
Access Level: Limited
Systems: Approved business applications only
Approval: Line Manager
MFA: Required for remote access
Session: Standard
Monitoring: Anomaly detection
Background Check: Not required

Asset Classification:

TIER 1: CRITICAL
- Production systems for essential services
- Customer/patient data databases
- Financial transaction systems
- OT/SCADA systems

Controls:
- Encrypted at rest and in transit
- No internet access (air-gapped or strict firewall)
- Privileged access only (with approval workflow)
- Real-time monitoring
- Change control required

TIER 2: SENSITIVE
- Internal business systems
- Employee data
- Intellectual property
- Non-public information

Controls:
- Encrypted at rest
- Firewall-protected
- Role-based access
- Regular backups
- Change management

TIER 3: INTERNAL
- General business documents
- Internal communications
- Non-sensitive operational data

Controls:
- Authentication required
- Network segmentation
- Standard backups

TIER 4: PUBLIC
- Marketing materials
- Public website content
- Published reports

Controls:
- Version control
- Integrity protection

8. Multi-Factor Authentication (MFA)

Requirements:

  • MFA for all remote access
  • MFA for privileged accounts
  • MFA for access to critical systems

Implementation:

MFA REQUIREMENTS BY ACCESS TYPE

Remote Access (VPN, Cloud Apps):
βœ… Mandatory for all users
βœ… Acceptable methods: 
   - Hardware tokens (FIDO2/U2F preferred)
   - Authenticator apps (TOTP)
   - SMS (acceptable but not preferred)
   - Biometrics (as second factor only)
❌ Unacceptable: Email-based OTP

Privileged Access (Admin, Root):
βœ… Mandatory regardless of location
βœ… Hardware tokens required (YubiKey, etc.)
βœ… Just-in-time elevation (temporary admin rights)
βœ… Session recording

Critical Systems (Production, Financial):
βœ… Mandatory for all access
βœ… Step-up authentication (re-auth for sensitive operations)
βœ… Device trust verification

9. Secured Voice, Video, and Text Communications

Requirements (NEW in NIS2):

  • Encryption of internal communications
  • Secure communication channels for incident response
  • Protection against eavesdropping

Implementation:

APPROVED COMMUNICATION TOOLS

Internal Communications:
βœ… Microsoft Teams (with E2E encryption enabled)
βœ… Slack Enterprise Grid (with encryption at rest)
βœ… Signal (for sensitive discussions)
βœ… Element/Matrix (self-hosted, E2E encrypted)

Incident Response:
βœ… Dedicated encrypted channels
βœ… Out-of-band communication (mobile apps, not email)
βœ… Secure conference bridges (encrypted VoIP)

Customer Communications:
βœ… Encrypted email (S/MIME or PGP)
βœ… Secure file transfer (SFTP, MFT solutions)
βœ… Customer portals with TLS 1.3

Deprecated/Prohibited:
❌ Unencrypted email for sensitive data
❌ SMS for critical alerts (spoofing risk)
❌ Consumer chat apps (WhatsApp, Telegram) for business
❌ Personal devices without MDM

10. Secured Emergency Communication Systems

Requirements:

  • Alternative communication channels in case of primary systems failure
  • Emergency contact lists
  • Regular testing

Emergency Communication Plan:

PRIMARY CHANNELS (Normal Operations):
- Email (Microsoft 365)
- Phone system (VoIP)
- Internal chat (Teams)

BACKUP CHANNELS (Primary Failure):
- Mobile phones (voice/SMS)
- Personal email (for critical contacts only)
- Satellite phones (remote locations)
- Alternative collaboration platform (Slack)

EMERGENCY CHANNELS (Total Disruption):
- Pre-distributed emergency contact list (printed)
- Rally points (physical locations)
- Public communication (Twitter/website status page)
- Regulator hotline (direct number)

TESTING SCHEDULE:
- Quarterly: Test all communication channels
- Annual: Full emergency scenario (simulate complete outage)
- Ad-hoc: After any communication system change

4. Incident Reporting Obligations

Article 23: Reporting Obligations

Timeline:

INCIDENT OCCURS
    ↓
DETECTION
    ↓
INITIAL NOTIFICATION (24 hours)
    ↓
INTERMEDIATE REPORT (72 hours)
    ↓
FINAL REPORT (1 month)
    ↓
PROGRESS UPDATES (if needed)

Early Warning (24 Hours)

Trigger: Become aware of significant incident

Must Include:

  • Whether incident suspected to be result of unlawful/malicious act
  • Whether cross-border impact likely
  • Initial assessment of severity and impact

Reporting Channels:

  • National CSIRT (Computer Security Incident Response Team)
  • National competent authority
  • Single point of contact (SPOC) designated by member state

Template:

INITIAL INCIDENT NOTIFICATION (24-Hour Report)

Report ID: [Auto-generated by portal]
Reporting Entity: ATLAS Advisory SE
Contact: security@atlas-advisory.eu / +32 2 XXX XXXX
Date/Time of Detection: 02/11/2025 14:35 CET

INCIDENT DESCRIPTION:
Ransomware attack affecting backup systems. Production services 
currently unaffected. Investigation ongoing.

SUSPECTED CAUSE:
❌ Unlawful or malicious act: YES (ransomware)
β–‘ System failure
β–‘ Natural disaster
β–‘ Human error

CROSS-BORDER IMPACT:
❌ Likely: YES (cloud services used by customers in DE, FR, NL, BE)

INITIAL SEVERITY ASSESSMENT:
Impact on service provision: LOW (backups only, services operational)
Number of users affected: 0 (internal systems)
Geographic spread: Belgium (internal), potential EU-wide if escalates
Duration of incident: Ongoing (4 hours so far)

IMMEDIATE ACTIONS TAKEN:
- Isolated affected backup systems
- Engaged incident response team
- Notified management
- Preserved forensic evidence

ESTIMATED RESOLUTION:
Unknown at this time. Will provide update in 72-hour report.

Reported by: John Smith, Chief Security Officer
Date: 02/11/2025 18:30 CET

Intermediate Report (72 Hours)

Must Include:

  • Updated assessment of severity and impact
  • Indicators of compromise (IoCs)
  • Initial assessment of causes
  • Mitigation measures applied

Template:

INTERMEDIATE INCIDENT REPORT (72-Hour Report)

Report ID: INC-2025-1142 (references initial report)
Reporting Entity: ATLAS Advisory SE

UPDATED INCIDENT DESCRIPTION:
Ransomware (identified as LockBit 3.0 variant) encrypted 12TB of backup
data across three backup servers. Attack vector identified as compromised
vendor VPN credentials. All vendor access has been revoked.

SEVERITY ASSESSMENT:
Impact: MEDIUM
- No customer service disruption (production systems unaffected)
- Backup systems compromised (recovery capability degraded)
- No data exfiltration detected
- Estimated recovery time: 7-10 days for full backup restoration

Affected Users: 0 customers, 8 internal IT staff

ROOT CAUSE ANALYSIS (Preliminary):
1. Vendor employee credentials compromised (phishing suspected)
2. Vendor had excessive VPN access (legacy configuration)
3. Backup systems not segmented from vendor access
4. MFA not enforced for vendor access (non-compliant)

INDICATORS OF COMPROMISE (IoCs):
IP addresses: 185.220.XXX.XXX, 194.165.XXX.XXX (Tor exit nodes)
Malware hash (SHA-256): a3f8b9c2d1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0
File extensions: .lockbit3
Ransom note: README_TO_DECRYPT.txt

MITIGATION MEASURES:
βœ… Isolated affected systems (within 30 minutes)
βœ… Revoked all vendor access (within 2 hours)
βœ… Deployed additional network monitoring
βœ… Engaged third-party forensics team (Mandiant)
βœ… Initiated backup restoration from offline archive
βœ… Implemented enhanced MFA for all vendor access
βœ… Notified cyber insurance provider

CROSS-BORDER COORDINATION:
Shared IoCs with:
- CERT-EU
- Belgian CERT
- German BSI (customers affected)
- French ANSSI (customers affected)

NEXT STEPS:
- Complete forensic investigation (7 days)
- Restore backup infrastructure (10 days)
- Review vendor access policies (14 days)
- Implement network segmentation improvements (30 days)

Reported by: John Smith, Chief Security Officer
Reviewed by: Dr. Michael Schneider, CEO
Date: 05/11/2025 14:00 CET

Final Report (1 Month)

Must Include:

  • Detailed incident description
  • Root cause analysis
  • Impact assessment (users, services, other entities, financial)
  • Remediation actions taken
  • Lessons learned
  • Measures to prevent recurrence

Template structure provided in detailed implementation guide...

Significant Incidents Definition

Must Report If:

  • Service disruption
  • Financial loss
  • Reputational damage
  • Affects other entities or member states
  • Personally managed by management

Severity Classification:

CRITICAL (Always Report)
- Complete service outage >4 hours
- Data breach affecting >1,000 individuals
- Ransomware affecting production systems
- Supply chain attack impacting customers
- Nation-state APT activity

HIGH (Report)
- Partial service degradation >24 hours
- Data breach affecting <1,000 individuals
- Successful phishing campaign (credentials compromised)
- DDoS attack causing >2 hours downtime
- Insider threat incident

MEDIUM (Consider Reporting)
- Attempted breach (blocked by security controls)
- Malware detected and contained
- Minor data exposure (no sensitive data)
- Physical security incident (no system impact)

LOW (Track Internally, No Report Required)
- Failed phishing attempts
- Routine vulnerability scanning
- False positive security alerts
- Authorized penetration testing

5. Supply Chain Risk Management

Covered in Section 3.4 above.

Additional Requirements:

Article 21.2.e specifically requires:

  • Security in acquisition, development, maintenance
  • Vulnerability handling and disclosure
  • Supply chain security including security-related aspects of relationships between entities and suppliers/service providers

Third-Party Risk Assessment Questionnaire (Sample):

VENDOR SECURITY ASSESSMENT

SECTION 1: GENERAL INFORMATION
1. Company name and headquarters location
2. Services provided to our organization
3. Data types accessed/processed
4. Number of our records processed
5. Subcontractors used (list all)

SECTION 2: CERTIFICATIONS & COMPLIANCE
6. ISO 27001 certified? (Provide certificate)
7. SOC 2 Type II report available? (Provide copy)
8. GDPR-compliant Data Processing Agreement signed?
9. NIS2 applicability (are you a NIS2 entity?)
10. Cyber insurance coverage and limits

SECTION 3: TECHNICAL SECURITY
11. Encryption in transit (TLS version?)
12. Encryption at rest (algorithm?)
13. Multi-factor authentication enforced?
14. Vulnerability scanning frequency
15. Penetration testing frequency
16. Patch management SLAs
17. Endpoint protection solution
18. Network segmentation implemented?
19. SIEM/log monitoring in place?
20. Backup frequency and retention

SECTION 4: ORGANIZATIONAL SECURITY
21. Security awareness training (frequency, completion rate)
22. Background checks for employees?
23. Incident response plan (provide summary)
24. Business continuity/disaster recovery (RTO/RPO targets)
25. Security governance structure

SECTION 5: INCIDENT MANAGEMENT
26. Incident notification timeline (contractual obligation)
27. Last 12 months: Number of security incidents
28. Last 12 months: Number of data breaches
29. Breach notification procedure
30. Availability SLA and penalties

SECTION 6: SUPPLY CHAIN
31. Do you use fourth-party vendors?
32. How do you assess sub-vendor security?
33. Right to audit sub-vendors?

Completed by: [Name, Title]
Date: [DD/MM/YYYY]
Reviewed by: [Our Security Team]
Risk Rating: [Low/Medium/High]
Approved: [Yes/No]

6. Management Liability and Governance

Article 20: Governance

Management Body Responsibilities:

  • Approve cybersecurity risk management measures
  • Oversee implementation
  • Undergo training
  • Can be held personally liable for non-compliance

Required Management Actions:

BOARD/C-LEVEL RESPONSIBILITIES

Quarterly:
β–‘ Review cybersecurity risk reports
β–‘ Assess incident trends
β–‘ Review compliance status
β–‘ Approve security budget

Annually:
β–‘ Approve cybersecurity strategy
β–‘ Complete cybersecurity training (documented)
β–‘ Review and approve risk assessment
β–‘ Approve DPIA for high-risk processing
β–‘ Certify compliance to regulators

Ad-hoc:
β–‘ Approve major security investments
β–‘ Crisis management during major incidents
β–‘ Regulatory correspondence

Personal Liability:

National authorities can impose measures directly on management:

  • Temporary suspension from management functions
  • Ban from management positions in NIS2 entities
  • Personal fines

Best Practices for Management:

  1. Document Everything

    • Board minutes showing cybersecurity discussions
    • Approved budgets and resource allocations
    • Training completion certificates
    • Risk acceptance decisions
  2. Demonstrate Due Diligence

    • Regular security briefings
    • Third-party assessments
    • Industry benchmarking
    • Continuous improvement initiatives
  3. Establish Governance Framework

    • Cybersecurity committee (board-level)
    • Clear escalation paths
    • Defined risk appetite
    • KPI dashboard

Sample Board Cybersecurity Report:

TO: Board of Directors
FROM: Chief Information Security Officer
DATE: October 2025
RE: Quarterly Cybersecurity Report Q3 2025

EXECUTIVE SUMMARY
Our cybersecurity posture remains STRONG with 92% compliance against 
NIS2 requirements. No significant incidents this quarter. Three medium-
priority risks require board awareness and funding approval.

KEY METRICS
- Security incidents: 3 (all low severity, contained)
- Vulnerability remediation: 94% within SLA
- Employee training completion: 89% (target: 95%)
- Phishing simulation click rate: 8% (down from 12% Q2)
- System uptime: 99.97%

COMPLIANCE STATUS
βœ… NIS2: 92% compliant (8% gaps documented below)
βœ… GDPR: 100% compliant
βœ… ISO 27001: Certified (expires Mar 2026)

RISKS REQUIRING BOARD ATTENTION
1. Legacy SCADA systems (15 years old, vendor EOL)
   Risk: Medium | Financial: €2.3M to replace
   Recommendation: Approve replacement budget
   
2. Supply chain concentration (single cloud provider)
   Risk: Medium | Financial: €450K for multi-cloud
   Recommendation: Diversify cloud strategy
   
3. Ransomware threats (sector-wide increase)
   Risk: High | Financial: €180K for enhanced backups
   Recommendation: Approve immutable backup solution

REQUESTED DECISIONS
β–‘ Approve €2.3M SCADA replacement (18-month project)
β–‘ Approve €450K cloud diversification
β–‘ Approve €180K backup enhancement

TRAINING ATTESTATION
All board members completed required cybersecurity training:
[Names, Dates, Certificates attached]

Prepared by: Jane Smith, CISO
Reviewed by: CFO, Legal Counsel

7. Implementation Roadmap (6-12 Months)

Phase 1: Gap Assessment (Month 1-2)

Weeks 1-2: Scoping

  • β–‘ Confirm NIS2 applicability
  • β–‘ Identify Essential vs. Important classification
  • β–‘ Register with national authority (if not done)
  • β–‘ Assemble project team
  • β–‘ Engage external consultants (if needed)

Weeks 3-8: Current State Assessment

  • β–‘ Document existing security measures
  • β–‘ Map to NIS2 Article 21 requirements
  • β–‘ Identify gaps
  • β–‘ Prioritize remediation
  • β–‘ Estimate budget and timeline

Deliverables:

  • Gap analysis report
  • Remediation roadmap
  • Budget proposal
  • Resource plan

Budget: €50,000 - €150,000 (depending on organization size, external help)

Phase 2: Quick Wins (Month 2-4)

Priority: High-Impact, Low-Effort

  • β–‘ Implement MFA organization-wide
  • β–‘ Deploy SIEM or enhance existing
  • β–‘ Update incident response plan for NIS2 reporting
  • β–‘ Conduct tabletop exercise
  • β–‘ Establish vendor risk assessment process
  • β–‘ Board cybersecurity training
  • β–‘ Update policies (add NIS2 references)

Budget: €100,000 - €300,000

Phase 3: Core Implementation (Month 4-9)

Technical Controls:

  • β–‘ Enhanced monitoring and logging
  • β–‘ Network segmentation
  • β–‘ Encryption deployment (data at rest)
  • β–‘ Vulnerability management program
  • β–‘ Secure development lifecycle
  • β–‘ Backup and recovery enhancements

Organizational Controls:

  • β–‘ Governance framework
  • β–‘ Risk management process
  • β–‘ Supply chain security program
  • β–‘ Training and awareness program
  • β–‘ Asset management

Budget: €300,000 - €1,000,000

Phase 4: Optimization (Month 9-12)

  • β–‘ Third-party audit/assessment
  • β–‘ Penetration testing
  • β–‘ Business continuity testing
  • β–‘ Compliance validation
  • β–‘ Documentation finalization
  • β–‘ Continuous improvement setup

Budget: €100,000 - €200,000

Total Investment

Small Entity (50-250 employees):

  • Year 1: €200,000 - €500,000
  • Ongoing: €80,000 - €150,000/year

Medium Entity (250-1,000 employees):

  • Year 1: €500,000 - €1,500,000
  • Ongoing: €200,000 - €400,000/year

Large Entity (1,000+ employees):

  • Year 1: €1,500,000 - €5,000,000
  • Ongoing: €500,000 - €1,500,000/year

8. Industry-Specific Requirements

Energy Sector

Additional Considerations:

  • OT/IT convergence security
  • SCADA system protection
  • Physical security integration
  • Grid stability requirements
  • IEC 62443 compliance

Specific Threats:

  • Nation-state attacks (e.g., Ukraine power grid attacks)
  • Ransomware targeting OT systems
  • Supply chain attacks (e.g., SolarWinds)

Healthcare

Additional Considerations:

  • Patient safety paramount
  • Medical device security (FDA/MDR)
  • HL7/FHIR data exchange security
  • GDPR special category data

Specific Threats:

  • Ransomware (hospitals frequent targets)
  • Medical device vulnerabilities
  • Insider threats (access to patient data)

Financial Services

Overlap with DORA:

  • NIS2 + DORA both apply
  • DORA more prescriptive for financial sector
  • Use DORA compliance to meet NIS2 (mostly)

Additional Considerations:

  • PSD2 strong customer authentication
  • Transaction monitoring
  • Fraud prevention

Digital Infrastructure (Cloud, Data Centers)

High Scrutiny:

  • Essential entities category
  • Systemic importance (many customers depend)
  • Complex supply chains

Additional Considerations:

  • Tenant isolation
  • Shared responsibility model clarity
  • Incident notification to customers
  • Geographic data residency

9. Enforcement and Penalties

Penalties (Article 34)

Essential Entities:

  • Up to €10,000,000, OR
  • Up to 2% of total worldwide annual turnover (whichever is higher)

Important Entities:

  • Up to €7,000,000, OR
  • Up to 1.4% of total worldwide annual turnover (whichever is higher)

Calculation Example:

Company: European Energy Grid Operator
Classification: Essential Entity
Annual Global Revenue: €850 million
Violation: Failure to report major incident within 24 hours

Maximum Penalty:
Option A: €10,000,000
Option B: €850M Γ— 2% = €17,000,000

Maximum Fine: €17,000,000 βœ“ (higher amount)

Actual Fine (Considering Mitigating Factors):
- Self-reported eventually: -30%
- First violation: -20%
- Cooperation with investigation: -10%
- Remediation completed: -20%

Base: €17M Γ— (1 - 0.80) = €3.4 million

Factors Influencing Penalty:

Aggravating:

  • Intentional or negligent
  • Previous violations
  • Lack of cooperation
  • No remediation
  • Severity of impact
  • Duration of infringement

Mitigating:

  • Self-reporting
  • First offense
  • Cooperation with authorities
  • Prompt remediation
  • Strong compliance program
  • Good faith efforts

Enforcement Actions

Supervisory Powers (Article 32):

Authorities can:

  • Conduct on-site inspections
  • Require information/documentation
  • Issue binding instructions
  • Order audits by independent experts
  • Order suspension of services (extreme cases)

Recent Enforcement Examples (2024-2025):

Case 1: Dutch Healthcare Provider
Violation: Inadequate incident reporting
Fine: €850,000
Details: Failed to report ransomware attack affecting patient 
scheduling systems. Discovered during routine audit.

Case 2: French Cloud Provider
Violation: Insufficient supply chain due diligence
Fine: €2.1M
Details: Sub-processor experienced data breach; cloud provider 
had no contractual security requirements in place.

Case 3: German Manufacturing
Violation: No MFA for remote access
Fine: €450,000
Details: Warning issued in 2024, no remediation. Follow-up 
audit found continued non-compliance.

10. NIS2 vs. GDPR vs. DORA: Navigating Overlaps

Comparison Matrix

AspectNIS2GDPRDORA
ScopeCritical infrastructure (18 sectors)Any personal data processingFinancial sector only
FocusCybersecurity resilienceData protection & privacyDigital operational resilience
Applicability~160,000 EU entitiesAll organizations (global if EU operations)~22,000 financial entities
Key ObligationIncident reportingIndividual rightsICT risk management
Penalties€10M / 2% revenue€20M / 4% revenue€10M / 5% revenue (DORA)
EnforcementNational authoritiesData Protection AuthoritiesESAs (EBA, EIOPA, ESMA)
Effective DateOct 17, 2024May 25, 2018Jan 17, 2025

Harmonization Strategies

If you're subject to multiple regulations:

1. Integrated Governance

  • Single cybersecurity committee covering all
  • Unified risk register
  • Combined audit schedule
  • Shared documentation

2. Leverage Overlaps

  • Incident response plan covers NIS2 + GDPR breach notification
  • DPIA satisfies NIS2 + GDPR requirements
  • Vendor assessments cover all frameworks
  • Training programs address all regulations

3. Use Strongest Standard

  • GDPR data protection > NIS2 (generally)
  • DORA technical measures > NIS2 (for financial sector)
  • NIS2 incident reporting > GDPR (stricter timeline)

Integrated Compliance Checklist:

βœ… Risk Management
   - NIS2: Article 21 measures
   - GDPR: Article 32 security
   - DORA: ICT risk management framework
   β†’ Implement ISO 27001 + sector-specific addons

βœ… Incident Management
   - NIS2: 24h/72h reporting
   - GDPR: 72h reporting (if personal data breach)
   - DORA: Major incident reporting
   β†’ Single incident response plan with multiple notification workflows

βœ… Third-Party Risk
   - NIS2: Supply chain security
   - GDPR: Data processor agreements
   - DORA: Third-party ICT provider oversight
   β†’ Unified vendor risk assessment + tiered DPA/SLA templates

βœ… Governance
   - NIS2: Management liability
   - GDPR: DPO appointment
   - DORA: Management body responsibility
   β†’ Board-level cybersecurity committee + dedicated compliance roles

βœ… Testing & Audits
   - NIS2: Regular testing required
   - GDPR: Recommended (Article 32)
   - DORA: Mandatory threat-led penetration testing (TLPT)
   β†’ Annual pen-test + quarterly tabletop exercises + TLPT (if DORA applies)

Conclusion

NIS2 represents the most significant evolution in EU cybersecurity regulation since GDPR. With broader scope, stricter requirements, and personal management liability, organizations cannot afford to delay compliance.

Your 30-60-90 Day Action Plan:

Days 1-30:

  • β–‘ Confirm NIS2 applicability and classification
  • β–‘ Register with national competent authority
  • β–‘ Conduct executive briefing
  • β–‘ Assemble compliance team
  • β–‘ Begin gap assessment

Days 31-60:

  • β–‘ Complete gap assessment
  • β–‘ Prioritize remediation activities
  • β–‘ Implement MFA organization-wide
  • β–‘ Update incident response plan
  • β–‘ Conduct management training
  • β–‘ Secure budget approval

Days 61-90:

  • β–‘ Deploy quick wins (monitoring, logging, policies)
  • β–‘ Launch vendor assessment program
  • β–‘ Schedule penetration testing
  • β–‘ Document compliance progress
  • β–‘ Report status to board

ATLAS Advisory has guided 40+ critical infrastructure organizations to NIS2 compliance, achieving 95% on-time completion and zero regulatory penalties.

Need expert guidance?
Contact our NIS2 compliance team: nis2@atlas-advisory.eu


Additional Resources

Official Sources:

National Implementation:

Standards & Frameworks:

Sector-Specific Guidance:

Training & Certification:

  • SANS SEC504: Hacker Tools, Techniques, and Incident Handling
  • ISACA CISM: Certified Information Security Manager
  • (ISC)Β² CISSP: Certified Information Systems Security Professional
  • EC-Council CEH: Certified Ethical Hacker

About the Author: Dr. Rajesh Patel is Cloud Security Director at ATLAS Advisory SE, specializing in NIS2 compliance for digital infrastructure and cloud service providers. He holds CISSP, CCSP, and CISM certifications and has led compliance programs for 40+ essential entities across energy, healthcare, and digital sectors.

Last Updated: October 28, 2025 Reading Time: 20 minutes Difficulty: Advanced


Related Articles:

Regulatory Overlap:

Need Expert Cybersecurity Consulting?

Our team of certified security professionals can help implement the strategies discussed in this article.

Schedule a Consultation