映射和控制认可
开放映射矩阵 CCSA <-> PCI DSS、GOST R 57580、CCSS、SOC 2、MiCA。有效的基线证书可以满足 CCSA 的部分要求，从而使审核成本更低、速度更快。
草案 v0.2 -> v1.0。在 2027-01-01 之前可能会有更改。
控制认可意味着什么
如果实体持有有效的当前基线证书，则根据条件，标记为“全部”或“部分”的 CCSA 要求将被计入。控制认可引用了已经验证的对照，而不是重新测试它。
CCSA 引用而不是重写。添加窄增量只是为了保护关键密码材料 - 类似于 PCI DSS 仅保护持卡人数据。
部分 A.7 — CCSA v0.2
三个控制认可类别
Full — 基线完全满足要求；确认证书有效性后，状态为“In Place”，无需进一步测试。
部分 — 覆盖部分；加密特定部分还通过相关的既定方法测试程序进行测试。
N/A — 基线不满足要求（或者 CCSA 更严格）；残留不适用，并且进行了全面测试。
关键 — 8 关键要求之一；无论基线强度如何，控制认可永远不适用。
控制认可条件（A.7.2 部分）
基线证书在 CCSA 评估开始日期不早于 12 个月。
基线证书在评估开始日期至少还有 6 个月的剩余有效期。
证书范围与密码材料环境相交（CME，B.1.2 节）。
通过注册表验证：证书真实性、范围调整、控制连续性。
另外对于 SOC 2：仅限 2 型；报告覆盖期限至少6个月；期间结束日期不超过评估开始前 12 个月；标准包括安全性（强制性）和保密性。
另外，对于 MiCA：该实体位于 EU VASP 注册表中；其注册活动包括加密资产托管服务。
8 关键要求永远不会延续
控制认可永远不适用于 8 关键要求，无论基线强度如何。他们总是需要完整的既定方法测试。它们在表中的映射仅供参考。
交互式映射矩阵
选择基线并按控制认可类别过滤。 PCI DSS 矩阵（8 域 B.1–B.8）是最详细的集合；为 GOST、CCSS、SOC、2 和 MiCA 提供按键映射。
| CCSA 要求 | 基线参考 | 控制认可 | 注意 |
|---|---|---|---|
| B.1.1 | Req 9.5.1 (Media Inventory) — analogy | 关键 | A–F categorisation and CCM specifics require a full CCSA assessment |
| B.1.2 | Req 1.4 (CDE Definition) — analogy | 关键 | CME is a conceptual analogue of the CDE |
| B.2.1 | Req 3.6.1 (Key Generation) | 关键 | CCSA requires FIPS 140-3 Level 3 / NIST SP 800-90A |
| B.2.2 | Req 1.4 — analogy | N/A | CCSA requires air-gap (L2) / shielding (L3) |
| B.2.3 | — | N/A | Ceremony protocol is a CCSA-specific requirement |
| B.2.4 | — | N/A | Verification of generated material is CCSA-specific |
| B.3.1 | Req 3.5 (Protect Stored Account Data) | 关键 | CCSA requires HSM / MPC / Secure Enclave with explicit certification |
| B.3.2 | Req 3.5.1 (Strong Cryptography) | 完全覆盖 | AEAD is compatible with PCI Strong Cryptography |
| B.3.3 | — | N/A | Hot/Warm/Cold tiering is a CCSA-specific requirement |
| B.3.4 | Req 12.10.1 (Disaster Recovery) | 部分覆盖 | Additional checks: backup-specific MEK, geographic distribution |
| B.4.1 | Req 3.6.7 (Key Usage) | 关键 | CCSA refines this through a trusted boundary |
| B.4.2 | Req 7 (Restrict Access by Need to Know) | 部分覆盖 | CCSA refines this through a dual-control threshold table |
| B.4.3 | Req 8 (Authentication) | 部分覆盖 | 2FA on the signing operation, not only login |
| B.4.4 | Req 7, Req 8 (Access Control + Auth) | 完全覆盖 | PAM with MFA is fully covered |
| B.5.1 | Req 3.6.4 (Key Rotation) | 完全覆盖 | CCSA cadence is stricter than or equal to PCI "at least annually" |
| B.5.2 | Req 12.10 (Incident Response) | 关键 | CCSA sets specific revocation SLAs by event type |
| B.5.3 | Req 12.10 (Business Continuity) | 部分覆盖 | CCSA refines the scenarios and RPO/RTO |
| B.5.4 | Req 3.7 (Key Destruction) | 完全覆盖 | Cryptographic erasure and certified disposal |
| B.6.1 | — | N/A | Multi-signature is a crypto-specific concept |
| B.6.2 | Req 10 (Logging) — analogy | 部分覆盖 | Watch-only via on-chain is crypto-specific |
| B.6.3 | Req 1.4 — analogy | 部分覆盖 | CDE segmentation analogy for hot/warm/cold isolation |
| B.6.4 | — | N/A | Withdrawal time-locks are a crypto-specific concept |
| B.6.5 | Req 1.2 — analogy | 部分覆盖 | Allowlist analogy for withdrawal whitelisting |
| B.7.1 | Req 10 (Logging and Monitoring) | 完全覆盖 | Comprehensive logging with retention |
| B.7.2 | Req 10.4 | 部分覆盖 | CCSA requires automated detection with alerting and SLA |
| B.7.3 | Req 10.2 — analogy | 关键 | Reconciliation of signing logs <-> on-chain is crypto-specific |
| B.7.4 | Req 12.10 (Incident Response) | 完全覆盖 | Documented playbook with regulatory notification |
| B.8.1 | Req 12.7 (Personnel Screening) | 关键 | CCSA requires enhanced screening for keyholders |
| B.8.2 | Req 7 (Restrict Access by Need to Know) | 完全覆盖 | RBAC with conflict detection |
| B.8.3 | Req 12.6, Req 12.7 | 部分覆盖 | CCSA requires crypto-specific training |
| B.8.4 | Req 12.7 (Personnel) | 部分覆盖 | CCSA sets an SLA + triggered rotation on offboarding |
| B.8.5 | — | N/A | Geographic distribution of keyholders is crypto-specific |
RU 客户端的特殊条件（A.2.3 部分）：FSB 认证的 SKZI、DFA 的 GOST 算法、FinCERT 报告连接。
级别：CCSS I 级 -> CCSA 级别 1； II 级 -> 2 级； III 级 -> 3 级。储备证明（CCSS 域 9）超出了 CCSA 范围。
SOC 2 控制认可是有限的：一段时间内基于意见的评估，而不是 CCSA 的二元合规性。不可能完全从 SOC 2 控制认可 — 只能部分控制认可。
映射仅限于有关密码材料保护的 MiCA 文章。治理、发行、AML、披露和保险（69、70、76 条）不在 CCSA 范围内。键值为B.3.3（离线存储）。
按基线划分的覆盖范围摘要
从每个基线继承（全部和部分）的 CCSA 要求份额。数值仅供参考。
| 基线 | 已满 | 部分 | 严重 不适用 | 不适用（非关键） | 控制认可（指示性） |
|---|---|---|---|---|---|
| PCI DSS v4.0.1 | 7 | 10 | 8 | 7 | ~58% |
| ГОСТ Р 57580 | 6 | 3 | 8 | 0 | ~36% |
| CCSS v8.0 | 12 | 0 | 5 | 0 | ~65% |
| SOC 2 Type 2 | 0 | 8 | 8 | 0 | ~30% |
| MiCA | 0 | 7 | 2 | 0 | ~35% |
PCI DSS v4.0.1
~58%
ГОСТ Р 57580
~36%
CCSS v8.0
~65%
SOC 2 Type 2
~30%
MiCA
~35%
CCSS v8.0 是 CCM 最接近的基线，正如加密特定标准所预期的那样。
PCI DSS v4.0.1 是通用基础设施要求的强大基准（B.5.1、B.5.4、B.7.1、B.7.4、B.8.2、B.4.4）。
GOST 57580 对于俄罗斯客户至关重要；它涵盖了访问管理和事件管理的部分内容。
SOC 2 受到其基于意见的方法的限制；仅部分是可能的。
MiCA 服务于 EU 细分市场；它的主要价值在于B.3.3（离线存储策略）。
经济效果
通过多基线控制认可，评估员执行全面审核工作的大约 50% - 扣除 8 关键要求，无论基线如何，都会对这些要求进行全面测试。客户的审计成本降低了 1.5–2 倍。
对于每个要求，最好的控制认可是在范围与 CME（A.8 部分）相交的基线中选择的。