PCI DSS 4.0 -- Payment Card Industry Data Security Standard
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 vault 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/vault-path). 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, 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 vault |
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 vault, 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 |
Vault provides complete key lifecycle management: generation, storage, rotation, revocation, destruction. cloudtaser rotate supports operational key rotation |
Wrapper |
| 3.6.1.1 |
Additional requirement for service providers: documented cryptographic architecture |
CloudTaser's architecture (EU vault, memfd_secret delivery, eBPF enforcement) is documented. cloudtaser 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 |
Vault 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 vault 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 vault (encrypted at rest with vault'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 rotate supports key rotation. Vault 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 |
Vault 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 |
Vault supports Shamir's Secret Sharing for unseal keys. Vault policies enforce multi-party authorization for sensitive operations |
Wrapper |
| 3.7.7 |
Prevention of unauthorized substitution of cryptographic keys |
Vault 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 |
Vault 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 vault communication. Network policies restrict communication paths |
Wrapper, CLI |
| 4.2.1 |
Strong cryptography for CHD transmission over open networks |
All vault 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 vault 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 vault paths instead of embedding secrets |
Operator, Wrapper |
| 6.3.2 |
Custom software reviewed for vulnerabilities before production |
cloudtaser discover scans for insecure secret references in deployment manifests. cloudtaser 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 |
Vault 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 |
Vault Kubernetes auth binds access to ServiceAccount + namespace. Different teams/functions use different namespaces with isolated vault policies |
Wrapper |
| 7.2.5 |
Access assigned and managed via an access control system |
Vault is the access control system for secrets. Access grants are declarative (Kubernetes RBAC + vault 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 |
Vault 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. Vault validates tokens against the Kubernetes API server's public key |
Wrapper |
| 8.6.1 |
System or application accounts managed and secured |
Vault 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 |
Vault 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 vault (logged) and eBPF enforcement (logged). No secret access path bypasses logging |
Wrapper, eBPF |
| 10.2.2 |
Audit logs capture administrative actions |
Vault 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 |
Vault 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 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 audit detects drift |
eBPF, CLI |
| Sub-Requirement |
Description |
CloudTaser Mapping |
Component |
| 12.3.1 |
Risk assessment performed at least annually |
cloudtaser 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 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 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 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 audit --vault-address https://vault.eu.example.com
# JSON output for QSA evidence packages
cloudtaser audit --vault-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: vault 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)