BSI C5 -- Cloud Computing Compliance Criteria Catalogue¶
Mapping, not certification
This document maps cloudtaser's technical controls to the named framework's requirements. It is evidence you can present to your auditor, not a cloudtaser certification. Certification is an outcome of your auditor's own review of your deployment (which may use cloudtaser's controls as supporting input).
Third-party audit roadmap: tracked in cloudtaser-sales#52. Target: Q2 2026. Until the audit completes, cloudtaser ships with deliberately-documented gaps rather than certification claims.
What this document IS / IS NOT¶
This is:
- A mapping of cloudtaser technical controls to framework requirements
- Evidence you can include in your auditor's evidence package
- A starting point for your DPIA / compliance narrative
This is NOT:
- A cloudtaser framework certification
- A substitute for your own audit/attestation/assessment
- Legal advice
Use this to accelerate your audit preparation, not to replace audit evidence.
Framework Overview¶
Full name: Cloud Computing Compliance Criteria Catalogue (C5:2020) Issued by: BSI (Bundesamt fur Sicherheit in der Informationstechnik -- Federal Office for Information Security, Germany) Current version: C5:2020 (revised from C5:2016) Type: Audited attestation standard for cloud service providers
The BSI C5 catalogue defines a minimum security baseline for cloud computing. It is widely used in Germany and increasingly across the EU as proof of cloud security maturity. C5 attestation is a prerequisite for cloud providers serving German federal agencies, and it is strongly recommended for providers serving regulated industries (banking, insurance, healthcare) in Germany.
Who Must Comply¶
- Cloud service providers serving the German public sector (federal, state, municipal)
- Cloud providers serving German regulated enterprises (financial services, critical infrastructure)
- Increasingly referenced by German enterprise procurement as a minimum requirement
Structure¶
C5:2020 contains 121 criteria organized into 17 requirement domains. Each criterion specifies a basic requirement and, for processing highly confidential data, an additional requirement. Attestation is performed by independent auditors under ISAE 3402 / ISAE 3000.
Relevant C5 Domains and cloudtaser Mapping¶
OIS -- Organizational Information Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| OIS-01 | Management responsibility for information security | cloudtaser provides quantifiable security metrics via protection scores. cloudtaser-cli target audit generates reports for management review |
CLI |
| OIS-02 | Information security management system | Protection scores and audit reports integrate into the ISMS as evidence of runtime secret protection | CLI, Operator |
| OIS-04 | Separation of duties | The operator enforces separation: only pods with correct ServiceAccount + namespace binding access secrets. eBPF enforces process-level isolation | Operator, eBPF |
SP -- Security Policies¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| SP-01 | Documentation of security policies | cloudtaser's annotation-based configuration (cloudtaser.io/inject, cloudtaser.io/secret-paths) provides declarative, auditable security policy |
Operator |
| SP-02 | Review and approval of policies | cloudtaser-cli target validate checks policy configuration against best practices. GitOps workflows (ArgoCD) provide approval trails for policy changes |
CLI |
IDM -- Identity and Access Management¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| IDM-01 | Identity and access management policy | OpenBao Kubernetes auth binds secret access to pod identity (ServiceAccount token + namespace). Only authorized workloads access secrets | Wrapper, Operator |
| IDM-02 | User registration and de-registration | Pod lifecycle manages access: secrets are only available while the pod is running with valid ServiceAccount binding. Pod deletion terminates access | Operator |
| IDM-03 | Provisioning of user access | The mutating webhook controls which pods receive secret injection based on annotation policy. Access is provisioned declaratively via Kubernetes manifests | Operator |
| IDM-06 | Privileged access management | eBPF blocks privileged operations (ptrace, /proc/pid/mem reads, kernel module loading) on protected processes. Even root cannot extract secrets from memfd_secret pages |
eBPF |
| IDM-08 | Secure log-on procedures | OpenBao authentication uses short-lived Kubernetes ServiceAccount tokens with audience binding. Tokens are stripped from the child process environment after authentication | Wrapper |
| IDM-10 | Access to source code and program libraries | Not directly addressed by cloudtaser | -- |
CRY -- Cryptography and Key Management¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| CRY-01 | Policy on use of cryptographic controls | cloudtaser enforces a consistent encryption model: TLS for transit, memfd_secret/mlock for secrets in use, AES-256-GCM for data at rest (S3 proxy) |
Wrapper, S3 Proxy |
| CRY-02 | Encryption of data in transit | All OpenBao communication uses TLS 1.2+ (mTLS when configured). Secrets are never transmitted in plaintext | Wrapper |
| CRY-03 | Encryption of data at rest | S3 proxy provides client-side AES-256-GCM encryption before data reaches cloud storage. Encryption keys remain in EU-hosted OpenBao | S3 Proxy |
| CRY-04 | Key management | Encryption keys are managed in the EU-hosted OpenBao (OpenBao). Key rotation is supported via cloudtaser-cli target rotate. Keys never leave EU jurisdiction |
Wrapper, S3 Proxy |
PS -- Physical Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| PS-01 through PS-05 | Physical security of data centers | cloudtaser does not manage physical security. However, memfd_secret removes secret pages from the kernel direct map, providing protection against physical memory access (cold boot, DMA) on supported kernels. Confidential computing (AMD SEV-SNP) adds hardware-level memory encryption |
eBPF, Wrapper |
OS -- Operational Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| OS-05 | Vulnerability management | cloudtaser-cli target discover identifies workloads using insecure Kubernetes Secrets (stored in etcd, accessible to the cloud provider). Each represents a data sovereignty vulnerability |
CLI |
| OS-06 | Logging and monitoring | eBPF agent generates security events for all blocked operations: SECRET_LEAK, PROCMEM_READ, ENVIRON_READ, PTRACE_DENIED, MODULE_LOAD, BPF_LOAD. Events integrate with SIEM via standard log collection |
eBPF |
| OS-07 | Monitoring of event logs | Protection scores provide continuous monitoring. cloudtaser-cli target audit produces scheduled compliance reports for log review |
CLI |
CS -- Communication Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| CS-01 | Network security management | cloudtaser-cli target netpol generates Kubernetes NetworkPolicies that restrict pod communication to the OpenBao endpoint, limiting the network attack surface |
CLI |
| CS-02 | Security of network services | OpenBao communication is over TLS/mTLS. The wrapper validates OpenBao TLS certificates. Network policies prevent lateral movement | Wrapper |
PI -- Portability and Interoperability¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| PI-01 | Portability of data and services | cloudtaser is cloud-agnostic. Secrets are stored in a portable EU OpenBao (OpenBao), not locked to any cloud provider's secret management service. Switching cloud providers does not require re-engineering secret management | Wrapper, Operator |
| PI-02 | Interoperability standards | cloudtaser uses standard Kubernetes APIs (admission webhooks, ServiceAccounts, annotations). It works on any conformant Kubernetes distribution | Operator |
SSO -- Supplier Relationships¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| SSO-01 | Information security in supplier relationships | cloudtaser eliminates the cloud provider (a key supplier) from the secret access chain. The provider operates infrastructure but never holds encryption keys or plaintext secrets | All |
| SSO-02 | Monitoring of supplier services | cloudtaser-cli target audit monitors protection coverage and detects drift. eBPF events detect anomalous access patterns from the infrastructure layer |
CLI, eBPF |
DEV -- Procurement, Development and Maintenance¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| DEV-01 | Secure development policy | cloudtaser-cli target discover scans for insecure secret references in CI/CD pipelines. cloudtaser-cli target validate verifies correct configuration before deployment |
CLI |
| DEV-05 | System security testing | Protection scores and audit reports verify that security controls are functioning correctly in production | CLI |
COM -- Compliance and Data Privacy¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| COM-01 | Compliance with legal and regulatory requirements | cloudtaser provides the technical layer for GDPR Art. 32 compliance, Schrems II supplementary measures, and NIS2 Art. 21 requirements. cloudtaser-cli target audit generates evidence packages |
CLI, All |
| COM-02 | Data protection | EU-hosted OpenBao ensures encryption keys remain under EU jurisdiction. memfd_secret ensures secrets are invisible to the cloud provider. Secrets never touch etcd or persistent storage |
Wrapper, eBPF |
Component Coverage Matrix¶
| cloudtaser Component | C5 Domains Addressed |
|---|---|
| Operator (webhook injection) | OIS, SP, IDM, PI |
| Wrapper (secret delivery) | CRY, IDM, CS, PI, COM |
| eBPF (runtime enforcement) | IDM, OS, PS, SSO |
| S3 Proxy (client-side encryption) | CRY, COM |
| DB Proxy (transparent encryption) | CRY, COM |
| CLI (audit, validate, discover) | OIS, SP, OS, CS, DEV, SSO, COM |
Gaps and Limitations¶
cloudtaser is a runtime data protection product, not a full cloud security platform. The following C5 domains are outside cloudtaser's scope:
| C5 Domain | Gap | Mitigation |
|---|---|---|
| PS (Physical Security) | cloudtaser does not control data center physical security | Use a cloud provider with C5 attestation for the infrastructure layer. cloudtaser's memfd_secret provides defense-in-depth against physical memory access |
| AM (Asset Management) | cloudtaser does not perform general IT asset management | Use Kubernetes-native asset inventory tools. cloudtaser-cli target discover covers secret-related assets |
| BCM (Business Continuity Management) | cloudtaser does not manage business continuity planning | OpenBao high availability and cloudtaser's cloud-agnostic design support BCM, but planning is the customer's responsibility |
| HR (Human Resources Security) | cloudtaser does not manage HR security processes | Organizational measure, outside product scope |
| RMG (Risk Management) | cloudtaser contributes to risk management but does not replace an enterprise risk management framework | Protection scores quantify one dimension of risk. Integrate with enterprise GRC tooling |
C5 is primarily a provider attestation
C5 attestation is typically sought by cloud service providers, not their customers. cloudtaser helps customers of non-C5-attested providers (or providers whose C5 scope does not cover all controls) achieve equivalent protection for secrets through technical enforcement. For cloudtaser SaaS customers, cloudtaser's own C5-relevant controls can be included in their provider's attestation scope.
Audit Evidence¶
cloudtaser produces evidence suitable for C5 audits:
# Generate compliance audit report
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com
# JSON output for audit evidence
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com -o json
The audit report provides:
- Protected vs. unprotected workload inventory (OIS, COM)
- eBPF enforcement coverage per node (OS, IDM)
- Protection scores per workload (OIS, DEV)
- OpenBao connectivity and TLS verification (CRY, CS)
- Orphaned Kubernetes Secrets in etcd (COM, OS)