BSI C5 on AWS: what you actually need to implement

The BSI Cloud Computing Compliance Criteria Catalogue — C5 — is published by Germany's Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik). It defines a baseline of information security requirements for cloud providers operating in Germany, with a particular focus on environments serving public sector, critical infrastructure and regulated industries. AWS holds a C5 attestation covering its infrastructure. That does not mean your workload is automatically compliant — it means the foundation is. Everything above the hypervisor is your responsibility.

What C5 actually is

C5 is not a certification you receive. It's an attestation standard — an auditor reviews your cloud environment against the catalogue criteria and issues an attestation report (Type 1 or Type 2). A Type 1 report confirms your controls exist at a point in time. A Type 2 report covers a period (typically 6–12 months) and verifies the controls were operating effectively throughout. For public sector contracts in Germany, Type 2 is typically required.

The catalogue itself covers 17 control domains across roughly 130 criteria. AWS publishes its own C5 attestation annually, which covers the infrastructure layer. When you build on AWS, your attestation scope includes both AWS's attested controls (referenced by inclusion) and your own customer-side controls. This is the shared responsibility model applied to compliance — and it's where most projects underestimate the scope of work.

The 17 control domains and what they mean on AWS

Rather than listing every criterion, here's a domain-by-domain breakdown of what actually requires implementation work on the customer side:

OIS — Organization of Information Security

Requires documented security policies, defined roles and responsibilities for cloud operations, and a formal risk assessment for the cloud deployment. On AWS this means documented architecture decisions, a defined RACI for cloud operations, and a risk register tied to your specific workload and data classification. This is largely process and documentation work — no specific AWS service covers it for you.

IM — Identity and Access Management

Requires strong authentication, least-privilege access, separation of duties, and periodic access reviews. On AWS: IAM Identity Center with MFA enforcement for all human access, SCPs to prevent IAM user creation in workload accounts, permission boundaries on all delegated roles, and quarterly access certification via IAM Access Analyzer. Root account access should be logged and physically controlled — MFA on root, hardware key preferred.

BCM — Business Continuity Management

Requires documented recovery objectives, tested failover procedures, and backup validation. On AWS: RTO and RPO defined per workload, AWS Backup with cross-region replication, Route 53 health checks with automated failover for critical endpoints, and documented and annually tested runbooks for recovery scenarios. The key gap most teams have here is the testing — backups that are never restored are not evidence of recovery capability.

COS — Communication Security

Requires encryption in transit for all data flows, including internal service-to-service traffic. On AWS: TLS 1.2 minimum enforced via ALB and API Gateway policies, ACM-managed certificates with automatic renewal, VPC endpoint policies for AWS service traffic that should not leave the AWS network, and PrivateLink for cross-account service exposure rather than internet-facing endpoints.

EKM — Encryption and Key Management

Requires encryption at rest for all data, customer-managed keys where data sensitivity requires it, and key lifecycle management with separation of duties. On AWS: KMS with customer-managed keys (CMKs) for sensitive workloads, key policies that enforce separation between key administrators and key users, automatic annual key rotation, and CloudTrail logging for all key usage. For the highest sensitivity data, AWS CloudHSM provides FIPS 140-2 Level 3 hardware-backed key storage.

VM — Vulnerability Management

Requires regular vulnerability scanning, a defined patch management process with SLA-based remediation timelines, and documentation of the asset inventory. On AWS: Amazon Inspector for continuous EC2 and container vulnerability assessment, AWS Systems Manager Patch Manager for automated patch deployment, and AWS Config for asset inventory and configuration drift detection. The C5 requirement isn't just scanning — it's demonstrating that findings are remediated within defined timelines. Build the tracking and closure process, not just the scanner.

RB — Resilience

Requires documented and tested high availability architecture, capacity planning, and DDoS protection. On AWS: multi-AZ deployments for all stateful resources, AWS Shield Standard (automatic) for basic DDoS protection, Shield Advanced for critical public-facing workloads, and documented capacity reviews tied to the workload's SLA.

LOG — Logging and Monitoring

Requires comprehensive audit logging, integrity protection of log data, log retention appropriate to the compliance regime, and alerting on security-relevant events. On AWS: CloudTrail enabled in all regions with log file validation, S3 access logging with Object Lock (WORM) for log integrity, VPC Flow Logs for network traffic visibility, Security Hub as the aggregation point for security findings, and GuardDuty for threat detection. Log retention of 3 years is common in public sector C5 engagements — budget for the S3 storage accordingly and set lifecycle policies to move older logs to Glacier.

PI — Portability and Interoperability

Requires that data can be exported in interoperable formats and that migration away from the provider is documented as a process. On AWS this is largely contractual and architectural — avoid proprietary serialization formats for long-term storage, document your data export procedures, and ensure your Terraform/IaC codebase is an accurate reflection of your deployed state (so a migration is possible from IaC, not from console drift).

The controls AWS already covers for you

AWS's own C5 attestation covers the physical and infrastructure layer: data centre security, hardware lifecycle, network security of the underlying infrastructure, hypervisor isolation, and AWS personnel vetting processes. When you're scoping your own attestation, these are referenced by inclusion — your auditor will review AWS's attestation report rather than auditing the data centres themselves. This significantly reduces scope, but it requires you to download and maintain a current copy of the AWS C5 attestation as part of your evidence package.

What the evidence package needs to contain

An auditor assessing a C5 Type 2 report will expect to see:

• Architecture documentation that maps to each applicable control domain
• Screenshots or API outputs confirming service configurations (CloudTrail enabled, MFA enforced, encryption settings, etc.)
• AWS Config rules with compliance history showing controls were continuously effective during the attestation period
• Security Hub findings report with evidence of remediation for critical and high findings
• IAM Access Analyzer reports and evidence of periodic access reviews
• Backup and recovery test logs
• Vulnerability scan history with remediation tracking
• Incident response procedure documentation and any incident log for the period
• AWS's current C5 attestation report (referenced by inclusion)

The most common failure mode in C5 readiness assessments: teams have the right AWS services deployed but no documentation proving the controls were operating continuously. AWS Config with custom rules is the most efficient way to generate the continuous compliance evidence an auditor actually needs — it produces a dated history of configuration states across the attestation period, not just a point-in-time screenshot.

The realistic timeline

For an environment starting from scratch on AWS with a reasonable landing zone already in place, a realistic timeline to C5 Type 2 readiness looks like this:

The AWS services you'll definitely use

If you're building a C5-ready environment on AWS, these services are non-negotiable:

• AWS CloudTrail — enabled in all regions, log file validation on, logs to a dedicated S3 bucket in a separate audit account with Object Lock
• AWS Config — recording all resource types, custom rules mapped to C5 criteria, aggregator for multi-account visibility
• AWS Security Hub — C5 standard enabled (AWS provides a managed mapping), findings aggregated from all accounts
• Amazon GuardDuty — enabled in all accounts and regions, findings fed to Security Hub
• AWS KMS — customer-managed keys for all sensitive storage (RDS, S3, EBS, Secrets Manager), annual rotation, key usage logging via CloudTrail
• IAM Identity Center — all human access via SSO, MFA enforced, no shared IAM users in workload accounts
• Amazon Inspector — continuous EC2 and container vulnerability assessment
• AWS Backup — backup plans with cross-region replication for critical data, annual restore tests documented

One practical tip

Enable the AWS Security Hub C5 standard early — it automatically maps AWS Config rules to C5 control IDs and provides a compliance score. It won't cover everything (particularly the process and documentation controls), but it gives you a live dashboard of the technical controls status and generates the evidence trail an auditor needs. Starting the observation period with Security Hub already running means your evidence collection is automatic rather than reconstructed after the fact.