CCSA vs PCI DSS / CCSS
A control-ID bridge: where CCSA is equivalent to PCI DSS and CCSS, where they cover a requirement only partially, and what CCSA adds on top.
Draft v0.2 -> v1.0. Subject to change before 2027-01-01.
Why this comparison matters
The first question an auditor or a buyer asks is “how does CCSA differ from what we already have?” Auditors think in control IDs, so the table below is a control-level bridge: every CCSA requirement is mapped to a PCI DSS and a CCSS control by their own numbers.
The table answers three practical questions: what an existing audit already covers and carries over, what is covered only partially and needs additional testing, and what CCSA adds in full — controls that neither standard addresses.
CCSA does not duplicate PCI DSS and CCSS — it builds on them as a baseline: overlapping controls carry over, and assessment focuses on crypto specifics.
Section A — CCSA v0.2
Scope of the comparison
PCI DSS is a payment card data security standard. The mapping is by analogy: key-management, access, logging and response controls are relevant, but crypto specifics (wallets, on-chain, ceremony) are absent from PCI DSS.
CCSS is a crypto-specific security standard and the closest baseline. There is more overlap on key management and wallets, but CCSS scope differs: Proof of Reserve (CCSS Domain 9) is out of CCSA scope, and material inventory and classification are not formalised in CCSS.
The mapping is against PCI DSS v4.0.1 and CCSS v8.0. This is an illustrative projection of the existing carry-over dataset into a “vs” view, not an official recognition statement by the PCI SSC or the CCSS Steering Committee.
How to read the relations
Equivalent — the standard has an analogous control; the requirement carries over when carry-over conditions are met.
Partial — the standard covers the requirement only in part; additional CCSA testing is needed.
Gap — the standard does not address this requirement.
CCSA only — the requirement is added entirely; no counterpart exists. It is one of the Critical Requirements and never carries over.
Control-ID bridge
Each row is a CCSA requirement and its control counterpart in PCI DSS and CCSS. The relation is shown per standard. Critical Requirements are marked with a star and are tested in full regardless of baseline.
Filter by domain
Requirements shown: 28
| CCSA | PCI DSS v4.0.1 | PCI relation | CCSS v8.0 | CCSS relation | Note |
|---|---|---|---|---|---|
B.1.1 | Req 9.5.1 — analogy | CCSA only | — | Gap | A–F categorisation and CCM specifics require a full CCSA assessment. |
B.1.2 | Req 1.4 (CDE) — analogy | CCSA only | — | Gap | CME is a conceptual analogue of the PCI DSS CDE. |
B.2.1 | Req 3.6.1 | CCSA only | CCSS 1. Key/Seed Generation | CCSA only | CCSA requires verifiable entropy (FIPS 140-3 Level 3 / NIST SP 800-90A); CCSS addresses the entropy source but without the CCSA threshold. |
B.2.2 | Req 1.4 — analogy | Gap | CCSS 1. Key/Seed Generation | Equivalent | Generation-environment isolation is covered by CCSS; PCI DSS has no analogue. |
B.2.3 | — | Gap | CCSS 1. Key/Seed Generation | Equivalent | The ceremony protocol is documented in CCSS; absent from PCI DSS. |
B.3.1 | Req 3.5 | CCSA only | CCSS 3. Key Storage | CCSA only | CCSA requires HSM / MPC / Secure Enclave with explicit certification; PCI DSS and CCSS require storage protection but without the CCSA mechanism threshold. |
B.3.2 | Req 3.5.1 | Equivalent | — | Gap | AEAD is compatible with PCI Strong Cryptography (Req 3.5.1). |
B.3.3 | — | Gap | — | Gap | Hot/Warm/Cold tiering is crypto-specific; neither PCI DSS nor CCSS prescribes it. |
B.3.4 | Req 12.10.1 | Partial | — | Gap | Additional checks: backup-specific MEK and geographic distribution on top of PCI Req 12.10.1. |
B.4.1 | Req 3.6.7 | CCSA only | CCSS 4. Key Usage | CCSA only | CCSA refines key usage through a trusted boundary; CCSS covers hardware-backed signing. |
B.4.2 | Req 7 | Partial | CCSS 4. Key Usage | Equivalent | PCI restricts access by need-to-know; CCSA and CCSS set dual-control thresholds. |
B.4.3 | Req 8 | Partial | — | Gap | 2FA on the signing operation, not only at login; no direct CCSS analogue. |
B.4.4 | Req 7, Req 8 | Equivalent | — | Gap | PAM with MFA is fully covered by PCI DSS Req 7 and Req 8. |
B.5.1 | Req 3.6.4 | Equivalent | CCSS 6. Keyholder Grant/Revoke | Equivalent | CCSA rotation cadence is stricter than or equal to PCI’s “at least annually”; CCSS covers rotation. |
B.5.2 | Req 12.10 | CCSA only | CCSS 5. Key Compromise Policy | CCSA only | CCSA sets specific revocation SLAs by event type; PCI and CCSS describe response without such SLAs. |
B.5.3 | Req 12.10 | Partial | CCSS 5. Key Compromise Policy | Equivalent | Recovery is covered by CCSS; partially in PCI DSS via Req 12.10. |
B.5.4 | Req 3.7 | Equivalent | CCSS 8. Data Sanitization Policy | Equivalent | Cryptographic erasure and certified disposal match PCI Req 3.7 and CCSS Domain 8. |
B.6.1 | — | Gap | CCSS 2. Wallet Creation | Equivalent | Multi-signature is crypto-specific; covered by CCSS Wallet Creation, absent from PCI DSS. |
B.6.3 | Req 1.4 — analogy | Partial | CCSS 2. Wallet Creation | Equivalent | Hot/warm/cold isolation by analogy with CDE segmentation; CCSS covers it directly. |
B.6.4 | — | Gap | — | Gap | Withdrawal time-locks are crypto-specific; neither PCI DSS nor CCSS prescribes them. |
B.7.1 | Req 10 | Equivalent | CCSS 10. Audit Logs | Equivalent | Comprehensive logging with retention matches PCI Req 10 and CCSS Audit Logs. |
B.7.2 | Req 10.4 | Partial | — | Gap | CCSA requires automated detection with alerting and SLA on top of PCI Req 10.4. |
B.7.3 | Req 10.2 — analogy | CCSA only | CCSS 7. Third-Party Audits — analogy | CCSA only | Reconciliation of signing logs <-> on-chain is crypto-specific; a full CCSA assessment. |
B.7.4 | Req 12.10 | Equivalent | CCSS 5. Key Compromise Policy | Equivalent | A documented playbook with regulator notification matches PCI Req 12.10 and CCSS Domain 5. |
B.8.1 | Req 12.7 | CCSA only | — | Gap | CCSA requires enhanced screening for keyholders beyond PCI Req 12.7. |
B.8.2 | Req 7 | Equivalent | — | Gap | RBAC with conflict detection matches PCI Req 7. |
B.8.3 | Req 12.6, Req 12.7 | Partial | CCSS 6. Keyholder Grant/Revoke | Equivalent | CCSA requires crypto-specific training; CCSS covers keyholder onboarding. |
B.8.4 | Req 12.7 | Partial | CCSS 6. Keyholder Grant/Revoke | Equivalent | CCSA sets an SLA and triggered rotation on offboarding; CCSS covers keyholder revoke. |
What CCSA adds beyond PCI DSS and CCSS
The eight Critical Requirements are the core of CCSA that no baseline fully covers. They never carry over, are tested under the Defined Approach, and four of them do not permit Compensating Controls at all.
Full inventory of cryptographic material
Critical RequirementB.1.1 — accounting for all key material with A–F categorisation. PCI DSS offers only an analogy (media inventory, Req 9.5.1); CCSS has no formalised inventory.
Classification by criticality category
Critical RequirementB.1.2 — singling out Critical Cryptographic Material as an analogue of the CDE. Neither PCI DSS nor CCSS prescribes such a classification of crypto material.
Key generation with verifiable entropy
Critical RequirementB.2.1 — a verifiable entropy source (FIPS 140-3 Level 3 / NIST SP 800-90A). PCI and CCSS address generation but without a mandatory verifiable threshold.
Storing Critical Cryptographic Material in HSM / MPC / Secure Enclave
Critical RequirementB.3.1 — mandatory hardware-backed storage with explicit mechanism certification. PCI and CCSS require storage protection but do not prescribe a specific certified mechanism.
Access control and authorization of cryptographic operations
Critical RequirementB.4.1 — using the key only inside a trusted boundary. PCI describes usage and access generally; CCSA pins down the boundary for each signing operation.
Secure key revocation and rotation by SLA
Critical RequirementB.5.2 — specific revocation SLAs depending on the type of compromise event. PCI and CCSS describe response but do not set measurable revocation deadlines.
Compromise detection and on-chain reconciliation
Critical RequirementB.7.3 — reconciling signing logs against on-chain state in watch-only mode. This is a crypto-specific control present in neither PCI DSS nor CCSS.
Separation of duties and personnel access control
Critical RequirementB.8.1 — enhanced screening for keyholders and strict separation of duties. PCI sets personnel screening (Req 12.7) generically, without enhanced keyholder requirements.
Hot / Warm / Cold storage tiering
Crypto-specific controlB.3.3 — architectural separation of hot, warm and cold key storage. A structural crypto control with no analogue in PCI DSS or CCSS.
Withdrawal time-locks
Crypto-specific controlB.6.4 — time-locks and thresholds on withdrawal operations. A crypto-specific wallet-architecture control absent from both standards.
What this gives the auditor and the buyer
Overlapping controls carry over from existing PCI DSS and CCSS audits, and assessment focuses on the eight Critical Requirements and crypto specifics. This reduces new work without lowering the bar.
If you already hold a valid PCI DSS or CCSS audit — start with the carry-over controls and direct your effort to the eight Critical Requirements.
A control carries over once the carry-over conditions are met (report validity, scope match, validation). See the carry-over and mapping page for details.
Ready to move from comparison to preparation
Run the readiness self-assessment or explore the full carry-over matrix across five baselines.
The Council responds within 5 business days.