PCI DSS 4.0 -- Payment Card Industry Data Security Standard¶
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: Payment Card Industry Data Security Standard v4.0 Issued by: PCI Security Standards Council (PCI SSC) Current version: v4.0.1 (June 2024) Effective: All requirements mandatory from 31 March 2025 Type: Industry security standard (contractually required)
PCI DSS defines security requirements for any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). Version 4.0 introduced significant updates including customized implementation options, enhanced cryptographic requirements, and stronger key management mandates.
Who Must Comply¶
- Merchants that accept payment cards
- Payment processors and acquirers
- Issuers and service providers
- Any entity storing, processing, or transmitting cardholder data
- Their service providers (including cloud providers hosting cardholder data environments)
Relevance to cloudtaser¶
cloudtaser protects the encryption keys, database credentials, API tokens, and other secrets used to secure cardholder data environments. By moving secrets out of Kubernetes Secrets (etcd) and into EU-hosted OpenBao with memory-only delivery, cloudtaser addresses multiple PCI DSS requirements around key management, access control, and encryption.
Requirement 3 -- Protect Stored Account Data¶
Requirement 3 mandates that stored cardholder data is protected through encryption, truncation, or hashing, with strict key management for cryptographic operations.
3.1 -- Processes for Protecting Stored Account Data¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 3.1.1 | Policies and procedures for protecting stored account data are defined and understood | cloudtaser enforces policy declaratively via annotations (cloudtaser.io/inject, cloudtaser.io/secret-paths). GitOps workflows provide version-controlled policy management |
Operator |
| 3.1.2 | Roles and responsibilities for Req 3 activities are documented and understood | The operator controls injection policy, the secret store (OpenBao/HashiCorp Vault) controls access policy, eBPF enforces runtime enforcement. Separation of duties is architecturally enforced | Operator, Wrapper, eBPF |
3.5 -- PAN Rendered Unreadable Wherever Stored¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 3.5.1 | PAN is rendered unreadable anywhere it is stored | S3 proxy provides client-side AES-256-GCM encryption before cardholder data reaches cloud storage. DB proxy provides transparent database encryption. Encryption keys remain in EU OpenBao | S3 Proxy, DB Proxy |
| 3.5.1.1 | Hashes used to render PAN unreadable use keyed cryptographic hash functions | Cryptographic keys for hashing operations are stored in EU OpenBao, injected into process memory via memfd_secret. Keys never touch disk or etcd |
Wrapper |
| 3.5.1.2 | Disk-level or partition-level encryption used only for removable media | cloudtaser uses application-level encryption (S3 proxy, DB proxy), not disk-level encryption. This satisfies the intent: data is encrypted before reaching the storage layer | S3 Proxy, DB Proxy |
3.6 -- Key Management Processes and Procedures¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 3.6.1 | Key management processes and procedures for cryptographic keys are defined and implemented | OpenBao provides complete key lifecycle management: generation, storage, rotation, revocation, destruction. cloudtaser-cli target rotate supports operational key rotation |
Wrapper |
| 3.6.1.1 | Additional requirement for service providers: documented cryptographic architecture | cloudtaser's architecture (EU OpenBao, memfd_secret delivery, eBPF enforcement) is documented. cloudtaser-cli target validate verifies configuration matches the documented architecture |
CLI |
3.7 -- Key Lifecycle Management¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 3.7.1 | Key management policies and procedures include generation of strong cryptographic keys | OpenBao generates cryptographic keys using cryptographically secure random number generators. Key strength is configurable (AES-256 for symmetric, RSA-2048+ or ECDSA P-256+ for asymmetric) | Wrapper |
| 3.7.2 | Key management policies include secure distribution of cryptographic keys | Keys are distributed from OpenBao to workloads over TLS/mTLS. Keys are delivered directly into process memory (memfd_secret). They never transit intermediate storage |
Wrapper |
| 3.7.3 | Key management policies include secure storage of cryptographic keys | Keys are stored in the EU-hosted OpenBao (encrypted at rest with OpenBao's master key). In the workload, keys exist only in memfd_secret pages, invisible to the kernel direct map |
Wrapper |
| 3.7.4 | Key changes for keys at the end of their cryptoperiod | cloudtaser-cli target rotate supports key rotation. OpenBao supports configurable key rotation policies. Key rotation does not require workload restart |
Wrapper |
| 3.7.5 | Retirement or replacement of keys when integrity is weakened or suspected compromise | OpenBao supports immediate key revocation. Compromised keys can be rotated without workload downtime. The wrapper fetches new keys on the next rotation cycle | Wrapper |
| 3.7.6 | Split knowledge and dual control for manual key management operations | OpenBao supports Shamir's Secret Sharing for unseal keys. OpenBao policies enforce multi-party authorization for sensitive operations | Wrapper |
| 3.7.7 | Prevention of unauthorized substitution of cryptographic keys | OpenBao policies control which entities can write keys. Pod authentication (ServiceAccount + namespace) prevents unauthorized key substitution. eBPF blocks process memory tampering | Wrapper, eBPF |
| 3.7.8 | Key custodians acknowledge their responsibilities | OpenBao audit log records all key management operations with identity. This provides a tamper-evident record of key custody | Wrapper |
Requirement 4 -- Protect Cardholder Data in Transit¶
Requirement 4 mandates that cardholder data is encrypted during transmission over open, public networks.
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 4.1.1 | Policies for protecting CHD during transmission are defined | cloudtaser enforces TLS for all OpenBao communication. Network policies restrict communication paths | Wrapper, CLI |
| 4.2.1 | Strong cryptography for CHD transmission over open networks | All OpenBao communication uses TLS 1.2+ with strong cipher suites. mTLS is supported for mutual authentication | Wrapper |
| 4.2.1.1 | Trusted certificates for internet-facing transmissions | The wrapper validates OpenBao TLS certificates. Certificate pinning is supported for high-security environments | Wrapper |
| 4.2.2 | PAN secured when sent via end-user messaging technologies | Not directly addressed (cloudtaser does not process end-user messages) | -- |
Requirement 6 -- Develop and Maintain Secure Systems and Software¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 6.2.4 | Software engineering techniques prevent common vulnerabilities | cloudtaser eliminates the vulnerability of storing secrets in Kubernetes Secrets (accessible via etcd API). Developers reference OpenBao paths instead of embedding secrets | Operator, Wrapper |
| 6.3.2 | Custom software reviewed for vulnerabilities before production | cloudtaser-cli target discover scans for insecure secret references in deployment manifests. cloudtaser-cli target validate verifies configuration against best practices |
CLI |
Requirement 7 -- Restrict Access to System Components and Cardholder Data¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 7.2.1 | Access control model covers all system components | OpenBao policies define which workloads can access which secrets. The operator controls injection scope via annotations. eBPF enforces process-level isolation | Operator, Wrapper, eBPF |
| 7.2.2 | Access assigned based on job classification and function | OpenBao Kubernetes auth binds access to ServiceAccount + namespace. Different teams/functions use different namespaces with isolated OpenBao policies | Wrapper |
| 7.2.5 | Access assigned and managed via an access control system | OpenBao is the access control system for secrets. Access grants are declarative (Kubernetes RBAC + OpenBao policies) and auditable | Wrapper |
| 7.2.6 | Access to query repositories of stored cardholder data is restricted | DB proxy encryption ensures that even if the database is queried directly (bypassing the application), the data is encrypted with keys the querier does not have | DB Proxy |
Requirement 8 -- Identify Users and Authenticate Access¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 8.3.1 | User access to system components authenticated | OpenBao Kubernetes auth authenticates workloads using ServiceAccount tokens. Tokens are audience-bound and short-lived | Wrapper |
| 8.3.2 | Strong cryptography for authentication | ServiceAccount tokens use RSA or ECDSA signatures. OpenBao validates tokens against the Kubernetes API server's public key | Wrapper |
| 8.6.1 | System or application accounts managed and secured | OpenBao ServiceAccount tokens are ephemeral. The wrapper strips authentication tokens from the child process environment after authentication | Wrapper |
Requirement 10 -- Log and Monitor All Access¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 10.2.1 | Audit logs capture access to cardholder data | OpenBao audit log records all secret fetch operations with timestamp, identity, path, and result. eBPF logs all blocked access attempts | Wrapper, eBPF |
| 10.2.1.1 | Audit logs capture all access to PAN | All secret access goes through OpenBao (logged) and eBPF enforcement (logged). No secret access path bypasses logging | Wrapper, eBPF |
| 10.2.2 | Audit logs capture administrative actions | OpenBao audit log records all administrative operations. eBPF logs privileged operations on protected processes | Wrapper, eBPF |
| 10.3.1 | Audit log entries include all required elements | OpenBao audit log includes: timestamp, identity, source IP, path, operation, result. eBPF events include: timestamp, process ID, syscall, target, action | Wrapper, eBPF |
| 10.4.1 | Audit logs reviewed at least daily | cloudtaser-cli target audit can be scheduled for regular compliance reporting. Protection scores provide continuous monitoring |
CLI |
| 10.7.1 | Failures of security controls detected and responded to | eBPF generates events for all security violations. Protection score decreases trigger alerts. cloudtaser-cli target audit detects drift |
eBPF, CLI |
Requirement 12 -- Support Information Security with Policies¶
| Sub-Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 12.3.1 | Risk assessment performed at least annually | cloudtaser-cli target audit produces risk assessment evidence: protection coverage, orphaned secrets, eBPF enforcement gaps |
CLI |
| 12.3.2 | Targeted risk analysis for customized approach | Protection scores provide per-workload risk quantification. cloudtaser-cli target discover identifies specific risks |
CLI |
Component Coverage Matrix¶
| cloudtaser Component | PCI DSS Requirements Addressed |
|---|---|
| Operator (webhook injection) | 3.1, 6.2, 7.2 |
| Wrapper (secret delivery) | 3.5, 3.6, 3.7, 4.2, 7.2, 8.3, 8.6, 10.2, 10.3 |
| eBPF (runtime enforcement) | 3.7.7, 7.2, 10.2, 10.7 |
| S3 Proxy (client-side encryption) | 3.5.1 |
| DB Proxy (transparent encryption) | 3.5.1, 7.2.6 |
| CLI (audit, validate, discover) | 3.6.1.1, 6.3.2, 10.4, 12.3 |
Gaps and Limitations¶
| PCI DSS Area | Gap | Mitigation |
|---|---|---|
| Requirement 1 (network security controls) | cloudtaser generates NetworkPolicies but does not replace firewalls or network segmentation | Use Kubernetes NetworkPolicies (generated by cloudtaser-cli target netpol) alongside cloud provider firewall rules and segmentation |
| Requirement 2 (secure configurations) | cloudtaser secures secret configurations but does not harden the broader system | Use CIS Kubernetes Benchmarks for cluster hardening. cloudtaser handles the secret management layer |
| Requirement 4.2.2 (end-user messaging) | cloudtaser does not protect data in end-user messaging channels | Outside scope. cloudtaser operates at the infrastructure/application level |
| Requirement 5 (anti-malware) | cloudtaser's eBPF provides process-level protection but is not a general anti-malware solution | eBPF blocks code injection and memory tampering. Use dedicated anti-malware for broader coverage |
| Requirement 9 (physical access) | cloudtaser does not control physical access to data centers | Use a cloud provider with PCI DSS attestation for physical security. memfd_secret provides defense against physical memory access |
| Requirement 11 (security testing) | cloudtaser supports testing but does not replace penetration testing or vulnerability scanning | Use cloudtaser-cli target audit alongside penetration testing and vulnerability scanning tools |
| Scope of protection | cloudtaser protects secrets and encryption keys, not cardholder data directly | Deploy S3 proxy and DB proxy to encrypt cardholder data at rest with cloudtaser-protected keys. This provides end-to-end protection |
cloudtaser protects the keys, not the data directly
PCI DSS requires protecting cardholder data. cloudtaser's primary role is protecting the encryption keys, database credentials, and API tokens used to secure cardholder data. By ensuring these secrets never touch US-controlled storage and are invisible to the cloud provider, cloudtaser provides the foundation for PCI DSS-compliant cardholder data protection. The S3 proxy and DB proxy extend protection to the data itself.
Audit Evidence¶
cloudtaser produces evidence suitable for PCI DSS assessments (QSA/ISA):
# Generate compliance audit report
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com
# JSON output for QSA evidence packages
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com -o json
The audit report provides:
- Secret storage verification: no secrets in etcd (Req 3.5)
- Key management evidence: OpenBao connectivity, TLS configuration (Req 3.6, 3.7, 4.2)
- Access control verification: protection scores per workload (Req 7.2)
- Audit log summary: access events, violations (Req 10.2, 10.3)
- eBPF enforcement coverage per node (Req 7.2, 10.7)