Security and Compliance Frameworks¶
Authorised application boundary
Authorised application code is trusted. An authorised app can send out a secret it has copied or encoded. Current content checks do not provide a general guarantee against this disclosure or a malicious authorised app. Memory-read tests and a Ready agent do not prove copied/encoded-secret exfiltration prevention. Enforced NetworkPolicy can restrict destinations, but allowed traffic remains a channel. See Security Model.
Workload identity and direct store-login boundary
In direct mode, OpenBao authenticates the ServiceAccount and namespace, not the injected wrapper. Anyone who can run a pod as the application's ServiceAccount can request a matching audience-bound JWT, log in to any store role bound to that identity, and read the records its policies allow. Node root can steal the projected JWT and do the same. CloudTaser does not bind direct store release to the injected wrapper. This limit remains unresolved. Blocking exec or protecting process memory does not block a separate store login. Port/bootstrap attestation claims do not apply to direct-mode logins.
Use one workload per identity: a dedicated ServiceAccount and exact-record store policy for each app. Restrict who can create or change workloads using that ServiceAccount, including controller templates, through Kubernetes RBAC and admission policy. Namespace access alone is not isolation between apps sharing an SA. Audience checks, shorter JWT lifetimes and source CIDRs limit some replay; they do not establish wrapper identity or stop node root. Confidentiality claims on this page do not cover this credential-acquisition path.
One workload per identity applies on both direct and Port paths. Denial of a second same-identity workload on Port has not been established; a different-ServiceAccount reader test does not prove that denial.
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 third-party audit roadmap. 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.
CloudTaser provides tamper-evident, fail-closed protection within the active enforcement boundary. It is not an absolute barrier against unrestricted node root or arbitrary kernel code. Ordinary application copies and provider access outside that boundary remain part of the assessment; see the security model.
cloudtaser provides technical controls that map to requirements across EU, national, and industry compliance frameworks. This page is a directory of every framework cloudtaser helps satisfy -- select any framework for the detailed control mapping.
Leadership summary
cloudtaser maps to 12 regulatory and industry frameworks spanning GDPR, financial regulation (DORA, PCI DSS), cybersecurity directives (NIS2), and national standards (German C5, French SecNumCloud, Dutch BIO/DNB). This broad coverage reduces compliance overhead and demonstrates due diligence to regulators and auditors.
At a Glance¶
| Framework | Scope | Who Must Comply | cloudtaser Relevance |
|---|---|---|---|
| GDPR / Schrems II | Data protection, international transfers | All EU data controllers and processors | Supplementary measures for US cloud usage |
| DORA | Digital operational resilience | EU financial entities (banks, insurers, payment firms) | ICT risk management, third-party provider controls |
| NIS2 | Cybersecurity for essential/important entities | Energy, transport, health, digital infrastructure, ICT services | Risk management, incident detection, supply chain security |
| EU Data Act | Data portability, cloud switching, safeguards | Cloud service providers and customers | Technical measures against non-EU government access |
| PCI DSS 4.0 | Payment card data security | Any entity storing/processing/transmitting cardholder data | Key management, encryption, access control |
| ISO 27001:2022 | Information security management | Any organization (voluntary, often contractually required) | 13+ Annex A controls |
| SOC 2 Type II | Trust services criteria | SaaS providers, service organizations | Confidentiality, availability, processing integrity |
| German C5 | Cloud computing compliance criteria | Cloud providers serving German public sector and enterprises | EU key control, encryption, access monitoring |
| French SecNumCloud | Cloud security qualification | Cloud providers serving French government and sensitive sectors | Data residency, immunity from non-EU laws |
| BIO | Dutch government information security baseline | Dutch government agencies and their suppliers | Encryption, access control, monitoring |
| DNB Guidelines | Outsourcing and cloud usage for financial institutions | Dutch banks, insurers, pension funds | Third-party risk, data access controls |
| EDPB 01/2020 | Supplementary measures for international transfers | Data exporters to third countries | Technical measures ensuring data protection |
EU-Wide Frameworks¶
GDPR / Schrems II¶
Full name: General Data Protection Regulation (Regulation (EU) 2016/679) Schrems II: CJEU Judgment C-311/18 (July 2020)
The foundational EU data protection regulation. After Schrems II invalidated the EU-US Privacy Shield, organizations using US cloud providers must implement "supplementary technical measures" that prevent US government access to EU personal data.
cloudtaser provides:
- Secrets never enter US-controlled storage (etcd, disk, K8s Secrets API)
memfd_secretremoves the protected mapping's direct-map alias; arbitrary kernel code and ordinary application copies remain outside that guarantee (see the security model)- EU-hosted OpenBao ensures encryption keys remain under EU jurisdiction
cloudtaser-cli target auditgenerates Article 30 Records of Processing evidence
Full GDPR / Schrems II mapping
DORA¶
Full name: Digital Operational Resilience Act (Regulation (EU) 2022/2554) Applies from: January 2025 Who: Banks, insurance companies, investment firms, payment institutions, crypto-asset service providers
DORA requires financial entities to implement ICT risk management frameworks, incident reporting, resilience testing, and third-party provider risk management.
cloudtaser provides:
- ICT risk quantification via protection scores
- eBPF-based incident detection and response (37 catalogued kprobe syscall programs)
- Technical controls that reduce specific read-path risks; residual provider risk depends on node integrity, privileges and the confidential-compute substrate
cloudtaser-cli target auditproduces DORA Article 6 risk assessment evidence
NIS2¶
Full name: Directive on Security of Network and Information Systems (Directive (EU) 2022/2555) Transposition deadline: October 2024 Who: Essential entities (energy, transport, banking, health, digital infrastructure) and important entities (postal, waste, chemicals, food, manufacturing, digital providers)
cloudtaser provides:
- Risk management measures (Article 21) via protection scores and audit reports
- Incident detection through eBPF event generation
- Read-path enforcement and tamper signals as part of supply-chain risk management
- Cryptography and encryption policy enforcement
EU Data Act¶
Full name: Regulation on harmonised rules on fair access to and use of data (Regulation (EU) 2023/2854) Applies from: September 2025
The EU Data Act includes provisions requiring cloud service providers to implement safeguards against non-EU government access to data. Article 32 requires "all reasonable technical, legal and organisational measures" to prevent international government access that conflicts with EU law.
cloudtaser provides:
- Technical measures restricting specific access paths within the deployed enforcement boundary
- EU-hosted key management under EU jurisdiction
- Client-side encryption for data at rest (S3 proxy)
- Process-level memory isolation for data in use
EDPB Recommendations 01/2020¶
Full name: European Data Protection Board Recommendations 01/2020 on measures that supplement transfer tools
The EDPB provides guidance on which supplementary measures are effective when transferring data to countries without adequate data protection (including the US).
cloudtaser provides:
- Measure 1 (encryption with EU-held keys): The customer operates the EU store; delivery uses TLS and creates no Kubernetes Secret for the value. Application copies, output, disk and swap require separate assessment
- Measure 2 (pseudonymisation): Pseudonymisation keys can be stored in the customer-operated EU OpenBao and delivered to workload memory; application use, copies and re-identification risk remain separate boundaries
- Measure 4 (encryption by data exporter): The customer controls EU-store administration, policies and key custody. This does not establish exclusive access under shared-identity, application or node compromise
- Measure 9 (EEA processing): The customer selects the EU store substrate; an EU store alone does not establish EEA-only processing. Assess workload, relay and output locations separately
Industry Standards¶
PCI DSS 4.0¶
Full name: Payment Card Industry Data Security Standard v4.0 Effective: March 2025 (all requirements) Who: Any entity storing, processing, or transmitting cardholder data
cloudtaser provides:
| PCI DSS Requirement | cloudtaser Measure |
|---|---|
| Req 3: Protect stored account data | Cardholder data keys stored in EU OpenBao, injected into memory only. S3 proxy encrypts stored data with AES-256-GCM |
| Req 4: Protect data in transit | TLS/mTLS for all OpenBao communication |
| Req 6: Develop secure systems | cloudtaser-cli target validate and cloudtaser-cli target discover identify insecure secret handling in CI/CD |
| Req 7: Restrict access to system components | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above |
| Req 8: Identify users and authenticate | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above |
| Req 10: Log and monitor all access | eBPF generates security events for all secret access attempts |
| Req 12: Support information security with policies | Protection scores and audit reports provide policy enforcement evidence |
ISO 27001:2022¶
Full name: Information security management systems - Requirements Who: Any organization (often contractually required by enterprise customers)
cloudtaser supports 13+ Annex A controls covering cryptography, access control, data leakage prevention, network security, and configuration management.
SOC 2 Type II¶
Full name: Service Organization Control 2 Type II Who: SaaS providers, cloud service organizations, managed service providers
cloudtaser supports Trust Services Criteria for confidentiality (CC6.x) and monitoring (CC7.x).
National Frameworks¶
German C5¶
Full name: Cloud Computing Compliance Criteria Catalogue (C5:2020) Issued by: BSI (Federal Office for Information Security, Germany) Who: Cloud providers serving German public sector and regulated enterprises
The C5 catalogue defines baseline security requirements for cloud providers. cloudtaser addresses key C5 domains:
| C5 Domain | Control Area | cloudtaser Measure |
|---|---|---|
| CRY | Cryptography and key management | EU-hosted OpenBao with sole key control. AES-256-GCM for storage. TLS for transit |
| IDM | Identity and access management | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above |
| OPS | Operational processes | Protection scores, audit reports, automated validation via CLI |
| LOG | Logging and monitoring | eBPF event generation for all secret access attempts with SIEM integration |
| PHY | Physical security | Confidential computing (SEV-SNP) encrypts VM memory against physical access |
| SPN | Supply chain management | Read-path controls and tamper signals; provider risk remains dependent on substrate and kernel integrity |
French SecNumCloud¶
Full name: Référentiel SecNumCloud v3.2 Issued by: ANSSI (National Agency for Information Systems Security, France) Who: Cloud providers serving French government, defense, and critical infrastructure
SecNumCloud requires cloud providers to demonstrate immunity from non-EU extraterritorial laws. cloudtaser provides the technical layer:
| SecNumCloud Requirement | cloudtaser Measure |
|---|---|
| Immunity from non-EU laws | Technical read-path controls; no guarantee against arbitrary kernel code or provider access outside the deployed boundary |
| EU data residency | The customer selects the EU store substrate. Delivery creates no Kubernetes Secret for the value, but application processing, copies and output may occur elsewhere and require separate residency assessment |
| Encryption key control | The customer or its EU delegate operates OpenBao and controls store policies and key custody. Runtime copies, raw store logins and privileged access remain subject to the identity and security boundaries above |
| Access logging | eBPF generates tamper-evident logs of all secret access attempts |
SecNumCloud is primarily a provider certification
SecNumCloud qualifies cloud providers, not their customers. cloudtaser supplies technical controls for a deployment-specific assessment. It does not confer SecNumCloud certification or equivalent protection guarantees on another provider.
BIO (Netherlands)¶
Full name: Baseline Informatiebeveiliging Overheid Issued by: Dutch government (CIP/BIO framework) Who: Dutch national and local government agencies and their suppliers
BIO is based on ISO 27001/27002 with additional controls specific to Dutch government. cloudtaser addresses:
| BIO Control Area | cloudtaser Measure |
|---|---|
| Encryption (10.1) | memfd_secret + mlock for secrets in use; S3 proxy AES-256-GCM for secrets at rest |
| Access control (9.x) | Active BPF LSM protects primary read paths; secondary-vector behavior depends on the deployed tier |
| Logging and monitoring (12.4) | eBPF events, protection score monitoring, cloudtaser-cli target audit |
| Supplier relationships (15.x) | Technical controls reducing specific provider-access risks, subject to the security model |
| Communications security (13.x) | TLS/mTLS for OpenBao communication; NetworkPolicies for network isolation |
DNB Guidelines (Netherlands)¶
Full name: De Nederlandsche Bank Good Practices for Information Security / Cloud Outsourcing Who: Dutch banks, insurers, pension funds under DNB supervision
DNB's guidance on cloud outsourcing requires financial institutions to maintain control over data and ensure the cloud provider cannot access sensitive information.
| DNB Requirement | cloudtaser Measure |
|---|---|
| Data access control | Fetched secrets stay in workload memory; confidentiality depends on kernel integrity, delivery mode and substrate |
| Risk management for third-party providers | Protection scores quantify residual risk; eBPF provides runtime enforcement |
| Exit strategy feasibility | cloudtaser is cloud-agnostic; secrets are in a portable EU OpenBao, not locked to any provider |
| Regulatory access to data | EU OpenBao under EU legal entity ensures regulatory access is governed by EU law |
Framework Coverage Matrix¶
Which cloudtaser components contribute to which frameworks:
| Component | GDPR | DORA | NIS2 | PCI DSS | ISO 27001 | SOC 2 | C5 | SecNumCloud | BIO | DNB |
|---|---|---|---|---|---|---|---|---|---|---|
| Operator | Art.32 | Art.7 | Art.21(e) | Req 6 | A.8.9 | CC6.3 | OPS | 12.4 | ||
| Wrapper | Art.32 | Art.9 | Art.21(h) | Req 3,7 | A.8.24 | CC6.1 | CRY | Key control | 10.1 | Data access |
| eBPF | Art.32 | Art.10,11 | Art.21(b) | Req 10 | A.8.12 | CC6.6 | LOG | Access logging | 12.4 | Risk mgmt |
| S3 Proxy | Art.32 | Art.9 | Art.21(h) | Req 3,4 | A.8.24 | CC6.7 | CRY | Data residency | 10.1 | Data access |
| CLI | Art.30 | Art.6,8 | Art.21(a) | Req 12 | A.8.9 | CC7.3 | OPS | 12.4 | Risk mgmt |