AWS and NIS2: Mapping 5 Security Services to Article 21 Before Your Auditor Does

AWS holds ISO 27001, SOC 2, and a German-government BSI C5 attestation. None of them make your organisation NIS2-compliant. Article 21(2) of Directive (EU) 2022/2555 places its ten cybersecurity measures on the entity operating the workload, not on the cloud provider underneath it — and the measures map unevenly onto the console you already have open. This guide maps five specific AWS services to five specific Article 21(2) letters, corrects a citation error that keeps circulating in AWS-and-NIS2 checklists, and marks exactly where AWS’s compliance evidence stops and your own documentation has to start.

Does Using AWS Put Your Organisation in NIS2 Scope?

NIS2 scope depends on your entity’s sector and size — not on which cloud provider you use. If you already know you’re an essential or important entity under Annex I or II, using AWS changes nothing about that classification. What changes is how you satisfy Article 21(2): some obligations land on infrastructure AWS controls, most land on the account, workload, and policy layer you control.

Who you are	NIS2 status	What that means for AWS
Your organisation, running production workloads on AWS (Annex I/II sector, medium+ headcount or turnover)	In scope if sector + size thresholds are met	Article 21(2) obligations are yours; AWS’s own certifications are supporting evidence, not a substitute
Amazon Web Services itself, as a cloud computing service provider	Annex I Digital Infrastructure — essential entity regardless of size	AWS is directly bound by Commission Implementing Regulation (EU) 2024/2690 (CIR) for its own operations, separately from your obligations
Your company runs a SaaS product on AWS, sold to other NIS2-scoped entities	Possibly in scope as a “cloud computing service” provider in your own right	You may sit under CIR as a second, distinct layer — not just as an AWS customer

Most readers of this guide are the first row: an essential or important entity that happens to run on AWS. Everything below is written for that case.

The Shared Responsibility Gap: What AWS Secures vs What Article 21 Still Makes You Own

The gap, not the stack, is where NIS2 liability actually sits. AWS’s shared responsibility model splits duties into “security of the cloud” (AWS: hardware, host operating system, virtualization layer, physical facilities) and “security in the cloud” (customer: guest OS, data, application, encryption, network traffic protection). How much lands on you depends on the service: run EC2 and you patch the guest OS, manage the applications, and configure the security groups yourself; run S3 or DynamoDB and AWS also runs the operating system, leaving you responsible mainly for data, encryption choices, and IAM permissions.

None of that line falls neatly on an Article 21(2) letter, and none of AWS’s own audited controls write the documents Article 21(2) actually requires: a risk-analysis policy (a), an incident-handling runbook naming who responds (b), a training programme (g). AWS cannot be fined for a misconfigured S3 bucket or an over-permissioned IAM role in your account — that exposure is entirely yours, regardless of how many compliance reports AWS itself holds.

For entities with strict data-residency requirements layered on top of NIS2, AWS has also launched a European Sovereign Cloud built as an independent, EU-only operation with its own identity and access management. AWS frames it around data residency and operational autonomy generally, not as a NIS2-specific control — worth knowing about for the data-sovereignty conversation, but it doesn’t change what Article 21(2) requires of your account configuration.

Five AWS Services Mapped to Article 21(2) — and Where the Citation Traps Are

One correction before the mapping: several AWS-and-NIS2 checklists circulating online cite CloudTrail’s logging obligation as sitting in “CIR Annex Section 6.11.” That section doesn’t cover logging. Section 6 of the CIR Annex covers acquisition, development, and maintenance of network and information systems — the actual logging and monitoring requirement sits at CIR Annex Section 3.2, under Incident handling. Citing the wrong section number in an audit binder is exactly the kind of detail that erodes credibility with an assessor who has the text open next to your evidence.

With that fixed, here’s how five AWS services line up against Article 21(2)’s ten measures. Where AWS has no service that substitutes for organisational work, this table says so — an attestation can’t write a training programme.

21(2)	Requirement	AWS service	How it maps
(a)	Risk analysis & security policy	AWS Config	Continuously evaluates resource configuration against rules and feeds configuration-drift data into your risk register — the risk-analysis methodology itself is still your policy to write
(b)	Incident handling	AWS Security Hub	Aggregates GuardDuty, Inspector, and Macie findings into one prioritised view — it’s the detection layer that triggers your incident-handling runbook, not the runbook itself
(c)	Business continuity, backup, DR	AWS Backup, Multi-AZ/Multi-Region	Organisational: you still set RTO/RPO targets and document the crisis-management plan
(d)	Supply chain security	AWS Artifact (subprocessor & compliance report access)	Organisational: AWS is a direct supplier in your own supply-chain register, not a substitute for it
(e)	Secure acquisition, development, maintenance	Amazon Inspector, Systems Manager Patch Manager	Automates vulnerability scanning and patch scheduling for the layer you own — your patch policy and timelines are still yours to set
(f)	Effectiveness-assessment policies	AWS Audit Manager, Security Hub compliance scores	Generates evidence for a self-assessment; the assessment methodology and cadence remain your policy
(g)	Cyber hygiene & training	None	No AWS service substitutes for a staff training programme — this measure is entirely organisational
(h)	Cryptography & encryption	AWS KMS	Customer-managed keys and envelope encryption directly implement a documented cryptography policy
(i)	HR security, access control, asset management	AWS IAM	Least-privilege policies and permission boundaries directly implement access-control policy; Config supplies the asset inventory
(j)	MFA & continuous authentication	IAM MFA enforcement, IAM Identity Center	Directly implements the multi-factor-authentication requirement, distinct from (i)’s broader access-control policy

In practice, the most common Article 21(2)(i) failure isn’t a missing IAM policy — it’s a wildcard Action: "*" attached to a service role because the console’s default flow nudges toward broad grants rather than scoped ones. Config’s rule evaluations will flag it; nothing about that flag writes the access-control policy an auditor expects to see alongside it.

BSI C5: Turning a German Government Audit Into Your Article 21 Evidence

The most underused piece of AWS compliance evidence for a NIS2 audit file isn’t ISO 27001 — it’s BSI’s Cloud Computing Compliance Criteria Catalogue (C5). BSI — Germany’s national cybersecurity authority and one of the EU’s NIS2 competent authorities — publishes C5 as a 168-criteria catalogue across 17 subject areas, audited under either a Type 1 (controls suitably designed at a point in time) or Type 2 (controls operating effectively over a period) report.

AWS holds a C5 attestation covering Frankfurt, Ireland, London, Paris, Milan, Stockholm, Zurich, Spain, and a wide set of EU edge locations, retrievable on demand through AWS Artifact. That report can serve as third-party evidence supporting several of your Article 21(2) control narratives — it does not, on its own, satisfy any of them. C5’s own text is explicit that the catalogue “does not prescribe the measures through which criteria must be fulfilled,” which is another way of saying: it covers AWS’s side of the shared-responsibility line, and your documentation still has to cover yours.

CloudTrail, CIR Section 3.2, and Your Article 23 Clock

CloudTrail is not itself an incident-notification tool — it’s the raw evidence an incident-response team needs to beat Article 23’s notification clock. Under Article 23, entities must submit an early warning “within 24 hours of becoming aware of the significant incident,” a full incident notification “within 72 hours” including a severity assessment and compromise indicators, and a final report “not later than one month” after the notification.

Producing those compromise indicators and that severity assessment inside 72 hours means the log fields have to already exist. CIR Annex Section 3.2.3 specifies that logs must cover “relevant outbound and inbound network traffic,” “authentication-related events,” “all privileged access to systems and applications, and activities performed by administrative accounts,” and “access or changes to critical configuration and backup files.” A multi-region CloudTrail trail, with log file validation and KMS-encrypted storage, is the AWS-native way to capture exactly that set. Section 3.2.5 then requires logs to be “maintained and backed up for a predefined period” and “protected against unauthorised access or modification” — the CIR doesn’t prescribe a specific number of months, but a 12-month retention window is a widely used, defensible baseline. See the full CIR 3.2 logging breakdown for the remaining sub-requirements, including time synchronisation and periodic review.

What It Costs When the Gap Isn’t Closed

Article 34 fines target the entity operating the workload, not the cloud provider underneath it. AWS’s own compliance posture is irrelevant to your exposure under this article.

Entity type	Maximum fine (Article 34)
Essential entities	EUR 10,000,000 or 2% of total worldwide annual turnover, whichever is higher
Important entities	EUR 7,000,000 or 1.4% of total worldwide annual turnover, whichever is higher

For a board weighing budget, the comparison is straightforward: closing the shared-responsibility gap — writing the policies AWS was never going to write — costs a fraction of one Article 34 exposure event. For a smaller organisation without a dedicated compliance function, the practical takeaway is plainer still: even if AWS never has an incident of its own, a misconfigured S3 bucket or a wildcard IAM policy in your account is entirely your exposure, and enforcement bodies are already drawing that distinction.

Common Questions

Does AWS’s ISO 27001 or SOC 2 certification make us NIS2 compliant?
No. Those certifications attest to AWS’s own infrastructure controls — not your workload configuration, your policies, or your incident-response process, which is what Article 21(2) actually requires you to document.

Which AWS region should a NIS2-scoped entity use?
No NIS2 provision mandates a specific region. Data-residency-sensitive entities often pair an EU region with data-sovereignty controls for GDPR reasons — a separate consideration from NIS2 scope itself, though the two conversations frequently happen together.

Do we need a signed agreement with AWS specifically for NIS2?
NIS2 has no equivalent to a healthcare-style business associate agreement. Instead, document AWS as a direct supplier under your own Article 21(2)(d) supply chain security policy, citing AWS’s C5 and ISO reports as supplier due-diligence evidence.

Where to Start

Start with the two documents nothing in your AWS console will ever generate for you: an Article 21(2)(a) risk-analysis policy, and an Article 21(2)(b) incident-handling runbook that names who receives Security Hub’s escalated findings and what they do next. Everything else in this guide — KMS key policies, IAM access reviews, CloudTrail retention, the BSI C5 report sitting in Artifact — is evidence that supports those two documents. None of it replaces them.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Article 21, Directive (EU) 2022/2555 (NIS2 Directive)
• Article 23, Directive (EU) 2022/2555 (NIS2 Directive)
• Article 34, Directive (EU) 2022/2555 (NIS2 Directive)
• AWS Shared Responsibility Model — Amazon Web Services
• AWS and BSI’s Cloud Computing Compliance Criteria Catalogue (C5) — Amazon Web Services
• C5 – Introduction — BSI (Bundesamt für Sicherheit in der Informationstechnik, Germany’s national cybersecurity competent authority)
• Commission Implementing Regulation (EU) 2024/2690, Annex — Technical and methodological requirements
• European Digital Sovereignty — Amazon Web Services