NIS2 Directive on AWS: A Practical Compliance Guide for EU Critical Infrastructure

The NIS2 Directive (officially Directive (EU) 2022/2555) is the European Union’s largest cybersecurity expansion since GDPR, replacing NIS1 with broader scope, higher penalties, and stricter incident reporting. The October 17, 2024 transposition deadline has passed; member states (Belgium, Germany, France, Italy, Netherlands, Spain, Poland, and others) are now actively enforcing national NIS2 implementations. For Essential and Important Entities — which now span 18 sectors and pull in tens of thousands of organizations that were not in scope under NIS1 — the question is no longer whether to comply but how quickly compliance can be evidenced.

This guide is for compliance leads, CISOs, and platform engineers operating in the EU or serving EU markets on AWS. It covers scope assessment, the 10 minimum measures, the three-stage incident notification timeline, supply-chain risk requirements, and the AWS service mapping that turns NIS2 controls from policy text into operational reality.

Need help with NIS2 readiness on AWS? FactualMinds runs NIS2 readiness engagements alongside ISO 27001 and SOC 2 — sharing controls and evidence across audits to compress the timeline. See our compliance services or talk to our team.

Step 1: Determine Whether NIS2 Applies

NIS2 has two thresholds: sectoral scope and size.

Sectoral scope — Annex I (Essential Entities):

• Energy (electricity, district heating/cooling, oil, gas, hydrogen)
• Transport (air, rail, water, road)
• Banking and financial market infrastructure
• Health (hospitals, labs, R&D, pharmaceutical manufacturers, medical-device manufacturers)
• Drinking water and wastewater
• Digital infrastructure (DNS, TLD registries, cloud computing service providers, data centre service providers, content delivery networks, trust service providers, electronic communications networks/services)
• ICT service management (managed service providers, managed security service providers)
• Public administration (central and regional)
• Space

Sectoral scope — Annex II (Important Entities):

• Postal and courier services
• Waste management
• Manufacture, production and distribution of chemicals
• Production, processing and distribution of food
• Manufacturing (medical devices, computer/electronic/optical products, electrical equipment, machinery, motor vehicles, transport equipment)
• Digital providers (online marketplaces, online search engines, social networking services platforms)
• Research

Size threshold: Medium-size enterprises (50+ employees OR €10M+ annual turnover) in covered sectors are in scope. Small and micro enterprises can be in scope if they are sole providers of a critical service, if disruption would have significant impact, or if explicitly designated by member-state authorities.

Extraterritorial reach: Non-EU organizations offering covered services to EU markets can be in scope. Cloud computing service providers (Annex I), online marketplaces (Annex II), and several other categories explicitly include non-EU providers.

Practical implications for AWS customers: If you’re a SaaS company serving EU enterprise customers in covered sectors, you may not be a NIS2 Essential or Important Entity yourself — but your customers are, and they will pass NIS2 supply-chain obligations downstream to you contractually. Many AWS-hosted SaaS providers receive their first NIS2 obligation through customer contracts, not direct regulation.

Step 2: Map the 10 Minimum Measures to AWS

NIS2 Article 21(2) lists 10 minimum cybersecurity risk-management measures. Each maps to AWS-native services, processes, or organizational controls.

1. Policies on risk analysis and information system security

Document an information security policy approved by leadership and a risk-assessment methodology. AWS contribution: AWS Artifact (provider attestations for your supply chain risk register), AWS Config + Security Hub (continuous control monitoring evidence). Most ISO 27001 ISMS documentation satisfies this — if you’ve read our ISO 27001 implementation guide, you’ve done this.

2. Incident handling

Documented incident response plan with severity classification, runbooks, escalation paths, and post-incident review. AWS contribution: GuardDuty (detection), Security Hub (aggregation and severity), EventBridge → Lambda (automated containment), CloudTrail Lake (forensic queries), Detective (behavior graph investigation). Test the plan annually with tabletop exercises.

3. Business continuity, backup management, and disaster recovery

Documented BCP/DR plan, tested at least annually, with defined RPO/RTO targets. AWS contribution: AWS Backup with cross-Region copies and Vault Lock (immutable backups), Pilot Light / Warm Standby / Multi-Region active-active patterns, scheduled DR drills with documented results.

4. Supply-chain security

Inventory of ICT suppliers, criticality classification, contractual cybersecurity obligations, and ongoing supplier monitoring. AWS contribution: AWS Marketplace tracking for sub-processors integrated into your AWS account, AWS Artifact for AWS’s own attestations (your evidence that AWS itself meets your supplier requirements), and Inspector v2 / GuardDuty findings on third-party container images and Lambda layers used in your workloads. Combine with a vendor risk register tracking each supplier’s SOC 2 / ISO 27001 / ENS / C5 status.

5. Network and information systems acquisition, development, and maintenance — including vulnerability handling and disclosure

Secure SDLC, vulnerability scanning, dependency management, coordinated vulnerability disclosure (CVD) program. AWS contribution: Amazon Inspector v2 (continuous EC2/ECR/Lambda scanning with CISA KEV reachability scoring), AWS CodeGuru Security (static analysis), Systems Manager Patch Manager (remediation orchestration). Run a public vulnerability disclosure program (often via HackerOne or Bugcrowd) — NIS2 anticipates that Essential and Important Entities have a structured CVD process, not just an internal vulnerability management program.

6. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures

Internal audit, control testing, KPI/SLO tracking. AWS contribution: AWS Audit Manager (automated evidence collection against built-in frameworks for SOC 2, ISO 27001, NIST CSF, HIPAA, and a dedicated NIS2 framework as it becomes available), Security Hub controls disabled-or-failing trends, Config conformance pack results.

7. Basic cyber hygiene practices and cybersecurity training

Annual security awareness training, phishing simulations, role-specific training for engineers and admins. This is HR-driven evidence — training records, completion rates, content review. The AWS layer is small but real: training your platform engineers on AWS-specific patterns (IAM, KMS, VPC isolation) reduces the rate of misconfiguration findings, which is itself a NIS2-reportable metric.

8. Policies and procedures regarding cryptography and encryption

Documented cryptography policy specifying algorithms, key management, lifecycle, and approved use cases. AWS contribution: AWS KMS (FIPS 140-2 Level 3 in many regions; FIPS 140-3 progressing), customer-managed keys with annual rotation, ACM for TLS certificate lifecycle, Secrets Manager for credential rotation. Document key ownership, rotation cadence, and approved cipher suites.

9. Human resources security, access control policies, and asset management

Background checks, joiners/movers/leavers process, access reviews, asset inventory. AWS contribution: IAM Identity Center (federated workforce access, scoped per role), IAM Access Analyzer (unused permissions detection), AWS Organizations + Tag Policies (asset inventory and ownership tagging), Resource Explorer (cross-account asset search). Quarterly access reviews documented with sign-off.

10. Multi-factor authentication, secured voice/video/text communications, and secured emergency communication systems

MFA enforced on all privileged access, secure communication channels for incident response. AWS contribution: IAM Identity Center MFA enforcement (FIDO2 strongly preferred over TOTP for privileged users), AWS Chatbot or third-party (Slack with E2EE / Signal) for secure incident channels, dedicated out-of-band communication channels for major incidents (e.g., a separate Slack workspace or phone tree if your primary channels are compromised).

Step 3: Operationalize the 24h / 72h / 1-Month Incident Reporting Clock

This is the operational requirement most likely to fail under stress. The clock starts when you become AWARE of a significant incident — meaning your detection systems flag it as such — not when you confirm it.

Three-stage timeline:

What counts as a “significant incident”? Article 23 defines significance: causes or is capable of causing severe operational disruption or financial loss; affects or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Member-state implementations refine these thresholds — your CSIRT relationship needs to confirm the classification model in your jurisdiction.

Architecting the 24-hour clock on AWS:

GuardDuty / Security Hub finding (SEVERITY: HIGH or CRITICAL)
    ↓
EventBridge rule (filter by severity, finding type, account)
    ↓
Step Functions workflow:
  1. Initial triage Lambda — enrichment, deduplication
  2. SNS notification to incident response channel
  3. PagerDuty / Opsgenie page to on-call
  4. Severity confirmation step (human or automated)
  5. If severity confirmed as NIS2-significant:
     a. Open incident in ServiceNow / Jira with NIS2 tag
     b. Start 24-hour timer (CloudWatch metric + alarm)
     c. Notify legal / DPO / NIS2-reporting team
     d. Begin evidence collection (CloudTrail Lake snapshot,
        Detective investigation, log isolation)

The point of the architecture is that the 24-hour clock is observable and alarmed. A CloudWatch alarm that fires at hour 18 if no early warning has been logged ensures the deadline cannot be missed quietly.

Pre-drafted notification templates: Have a one-page early-warning template in your incident response playbook that the SOC analyst can populate in 30 minutes. The template covers: what we observed, when, suspected cause, suspected scope, suspected cross-border impact. The 24-hour deadline cannot wait for a perfectly investigated narrative.

Member-state CSIRT contacts: Document the CSIRT contact for each member state where you operate. Belgium (CCB), Germany (BSI), France (ANSSI), Italy (CSIRT Italia), Netherlands (NCSC-NL), Spain (CCN-CERT), Ireland (NCSC-IE) — each has its own intake portal and language requirements. The first time you contact them should not be at hour 22 of the clock.

Step 4: Build Supply-Chain Risk Management

NIS2 Article 21(2)(d) explicitly calls out supply-chain security. The expectation is that you have a defensible position for every ICT supplier touching your critical service.

Supplier inventory:

• Document every ICT supplier — hyperscaler (AWS), SaaS providers, sub-processors, professional services with privileged access
• Classify each by criticality to your service (Tier 1 = direct service-disruption risk, Tier 2 = data-protection risk, Tier 3 = administrative)
• For Tier 1 suppliers, document the alternative if the supplier becomes unavailable

Contractual obligations:

• Incident notification clauses — supplier notifies you within X hours of an incident affecting your data or service
• Right-to-audit clauses (limited to security-relevant evidence; AWS Artifact satisfies this for AWS itself)
• Vulnerability disclosure obligations
• Sub-processor disclosure and approval rights
• Data residency and sovereignty terms

Ongoing monitoring:

• Subscribe to vendor security advisories (AWS Security Bulletins, GitHub security advisories, NVD feeds, CISA KEV)
• Annual review of Tier 1 supplier SOC 2 / ISO 27001 reports via AWS Artifact and equivalent vendor portals
• Public threat intelligence on supply-chain compromises (SolarWinds-style events) — what actions you would take if such a compromise affected your suppliers

AWS-as-supplier evidence package:

For NIS2 supplier-evidence purposes, the AWS Artifact bundle plus your contractual AWS Customer Agreement and Data Processing Addendum is your defensible position for the AWS layer.

Step 5: Build the NIS2 Compliance Package

NIS2 enforcement is risk-based and member-state-specific, but the evidence package competent authorities are converging on includes:

Step 6: NIS2 Alongside ISO 27001 and GDPR

For most organizations in scope, NIS2 layers on top of existing programs rather than replacing them.

ISO 27001:2022 ISMS overlap:

• The NIS2 risk-assessment requirement maps to ISO 27001 Clauses 6.1.2 + 6.1.3
• The 10 minimum measures map to ISO 27001:2022 Annex A controls (~75% overlap)
• The internal audit + management review cycle is identical between the two regimes
• An organization with a mature ISO 27001 ISMS satisfies the structural NIS2 requirements; the gap is NIS2-specific incident notification, supply-chain documentation, and the NIS2-specific evidence package

GDPR overlap:

• 72-hour breach notification (GDPR Article 33) and 72-hour incident notification (NIS2 Article 23) often run in parallel for incidents involving personal data
• GDPR data protection by design (Article 25) and NIS2 cryptography measure (Article 21(2)(h)) reinforce each other
• The DPO function under GDPR can co-exist with the NIS2 reporting function, often under the same person at smaller organizations

Practical sequencing: If you’re standing up compliance from zero, build ISO 27001 first (largest scope, longest timeline, broadest customer recognition), layer GDPR specifics on top, then add NIS2-specific elements (incident timeline, supply-chain register, member-state CSIRT relationships). Total Year 1 effort: 12–18 months. Annual ongoing effort: typically 0.5–1.5 FTE for compliance operations plus 1–2 FTE-equivalent for audits / management review / training.

Penalties

NIS2 penalties are significant:

Member states can additionally impose temporary suspension of certifications or authorisations, and personal liability for management bodies in the case of repeated severe non-compliance.

Compared to GDPR (€20M / 4%), NIS2 caps are lower, but the compliance bar is operationally higher because of the 24-hour incident clock and the explicit supply-chain expectations. The penalty risk is greatest for organizations that fail to evidence their controls when an incident occurs — a poorly evidenced cybersecurity program is itself the breach.

Get Started

NIS2 readiness is a compliance project, an architecture project, and an incident-response operations project simultaneously. We help organizations operating in the EU build NIS2 programs alongside ISO 27001:2022, GDPR, and SOC 2 — sharing the underlying AWS controls so the engineering effort is amortized across multiple regulatory regimes.

If your customers are starting to ask about NIS2 in security questionnaires, or if your member-state authority has scheduled an inspection, we can help.

Talk to our team →

Related reading:

• ISO 27001 Certification on AWS: ISMS Implementation Guide — the strongest foundation for NIS2 readiness
• GDPR Compliance on AWS: A Practical Guide for SaaS — parallel EU regime for personal data
• NIST Cybersecurity Framework 2.0 on AWS — alternative organizing framework with strong overlap
• AWS Vulnerability Management Program: CVSS & KEV Prioritization — supply-chain vulnerability handling
• Amazon Inspector v2: Container and Lambda Vulnerability Scanning — continuous vulnerability monitoring for NIS2 measure 5
• How to Set Up AWS Security Hub for Compliance Monitoring — control monitoring evidence
• AWS Cloud Security and Compliance Resources Hub — full content cluster