SAQ-C1 — custodial wallets self-assessment
The SAQ-C1 reference question library (Annex 4 §A4.8). The structure mirrors the standard's B.1–B.8 domains. Answers are stored locally in your browser; nothing is sent to a server.
Draft v0.2 -> v1.0. Subject to change before 2027-01-01.
SAQ-C1 — custodial wallets self-assessment
Record an assessment for each control. The SAQ does not replace the annual full audit — it is a preparation and interim self-assessment tool (for Level 1, every 6 months between audits).
Tools are the interactive layer of the standard: the self-assessment, checklists and worksheets you fill in on the site. They help you prepare for an audit, surface gaps early, and see which controls are already covered. A self-assessment is not a certification: a full audit is performed annually for all levels (Section D.4.1).
In Place / Not in Place / N/A
SAQ-C1 — custodial wallets self-assessment
The SAQ-C1 reference question library (Annex 4 §A4.8). The structure mirrors the standard's B.1–B.8 domains. Answers are stored locally in your browser; nothing is sent to a server.
SAQ-C1
0 / 66
Section 1 — Organization information
1.1Are the legal entity, segment (C.1–C.4) and target level (L1/L2/L3) of the assessment declared?
1.2Are AUM / market cap / TVL stated in USD equivalent against the segment's level thresholds?
1.3Are an assessment contact and a compliance officer assigned?
Section 2 — Baseline certifications
2.1Are there valid PCI DSS and/or ГОСТ Р 57580 certifications (with level and validity stated)?
2.2Are there SOC 2 reports (Type 1/2) and/or an ISO 27001:2022 certification?
2.3Is there a CCSS certification (Level I/II/III) or other relevant certifications?
Section 3 — B.1: CCM inventory and classification
3.1Is a documented CCM inventory maintained (CMDB, vault paths, or equivalent)?
3.2Does the inventory cover all applicable CCM categories (A–F)?
3.3Does each entry hold category, description, technology, primary storage location and owner?
3.4Is the Cryptographic Material Environment (CME) defined and documented?
3.5Is network segmentation applied to reduce the CME (firewall, VLAN, isolation, HSM hardware boundary)?
3.6Is segmentation testing performed annually?
3.7Are data flows documented for each applicable CCM category (generation, storage, access, usage, transmission, destruction)?
3.8Is the CCM inventory reviewed quarterly (every 6 months for L1)?
3.9Is the inventory updated within 5 business days on event-triggered changes?
Section 4 — B.2: Generation of CCM
4.1Is a qualified entropy source used (TRNG FIPS 140-3 L3+, DRBG NIST SP 800-90A, HSM internal RNG, Secure Enclave/StrongBox, or СКЗИ КС2/КС3/КВ1)?
4.2Has entropy testing been performed (NIST SP 800-22, FIPS 140-2 statistical tests)?
4.3Is an air-gapped environment used for the cold-storage generation ceremony?
4.4Is the key ceremony protocol documented (roles, step-by-step protocol, verification, sign-off)?
4.5Is the ceremony multi-person (2-of-3 / 3-of-5; independent witness for L3)?
4.6Is post-generation verification performed (address derivation, signing test, MPC negative test)?
Section 5 — B.3: Storage of CCM
5.1Is category A (Master) stored via an HSM (FIPS 140-2/3 L3+) or MPC mechanism (≥2-of-3 for L1/L2, ≥3-of-5 with geographic distribution for L3)?
5.2Is plaintext CCM prohibited in .env, repositories, container images, environment variables, unencrypted DB fields, logs and localStorage?
5.3Is secrets scanning in place (TruffleHog, gitleaks, GitGuardian)?
5.4Is an AEAD cipher used for CCM encryption at rest (AES-256-GCM, AES-256-GCM-SIV, ChaCha20-Poly1305, or Kuznyechik MGM)?
5.5Is the Master Encryption Key (MEK) stored separately from the encrypted CCM (in an HSM/KMS/MPC, not co-located)?
5.6Does the cold-storage share of AUM meet the level threshold (L1 ≥65%, L2 ≥85%, L3 ≥95%)?
5.7Are CCM backups geographically distributed (L1 ≥2 locations, L2 ≥2 jurisdictions, L3 ≥3 jurisdictions)?
5.8Is backup restoration tested quarterly (for L2+; annually for L1)?
Section 6 — B.4: Usage of CCM
6.1Does the private key never leave its trusted boundary (HSM / MPC / Secure Enclave / TEE) for signing operations?
6.2Is multi-person authorization of signing implemented by transaction-value band per level?
6.3Are cookies set with HttpOnly + Secure + SameSite=Strict?
6.4Do 2FA methods meet the requirement (TOTP, FIDO2/WebAuthn, Secure-Enclave biometrics, hardware token) — with SMS, email links and push-without-challenge excluded?
6.5Is step-up authentication applied above the threshold (>$50K for L3, >$100K for L2)?
6.6Is DPoP (RFC 9449) implemented — mandatory for L3?
6.7Is a PAM solution used for privileged access to the CCM infrastructure?
6.8Is a kill-switch mechanism in place for privileged sessions?
Section 7 — B.5: Lifecycle management
7.1Is rotation cadence defined for all six CCM categories (per level)?
7.2Is triggered rotation on offboarding performed within SLA (L1 ≤24h, L2 ≤4h, L3 ≤1h)?
7.3Is a revocation playbook documented for each CCM category within SLA (confirmed compromise ≤15 min, suspected ≤1h)?
7.4Has recovery been tested in the last 12 months, meeting the level RTO (L1 ≤72h, L2 ≤24h, L3 ≤4h)?
7.5Are disposal procedures defined (cryptographic erasure, HSM zeroization, physical destruction for L3)?
Section 8 — B.6: Wallet architecture
8.1Are multi-sig thresholds met by balance/context (cold storage: L1 2-of-3, L2 3-of-5, L3 4-of-7 with geographic distribution)?
8.2Are keyholders geographically distributed (for L3, across multiple jurisdictions)?
8.3Is watch-only monitoring connected to all production wallets?
8.4Are the hot / warm / cold tiers architecturally isolated (cold air-gapped, warm restricted, hot DMZ)?
8.5Are withdrawal time-locks applied to high-value operations by level?
8.6Is destination-address whitelisting used for institutional accounts, with multi-person approval and a cooling-off period for new addresses?
Section 9 — B.7: Compromise detection and monitoring
9.1Is comprehensive logging of CCM events maintained with the required fields?
9.2Is log integrity ensured (cryptographic hash-chaining between entries or WORM storage)?
9.3Is the log retention period met (L1 12 mo, L2 24 mo, L3 36 mo)?
9.4Is anomaly detection implemented (rule-based for L1, statistical baselines for L2, ML for L3)?
9.5Is the watch-only reconciliation SLA met: detection time (L1 ≤5 min, L2 ≤1 min, L3 ≤30 sec) and response time (L1 ≤30 min, L2 ≤15 min, L3 ≤5 min)?
9.6Does reconciliation cover discrepancies between on-chain activity and signing logs?
9.7Does the Incident Response Playbook cover all required scenarios (hot-wallet drain, HSM compromise, MPC-participant compromise, mass session-token leak, insider exfiltration, vendor-side incident, phishing campaign)?
9.8Has an annual tabletop exercise been conducted?
Section 10 — B.8: Personnel and access control
10.1Has a background check of CCM personnel been performed with the required elements and periodicity (L1/L2 every 3 years, L3 every 2 years)?
10.2Is a separation-of-duties (SoD) policy documented with a matrix and automated conflict detection?
10.3Is access reviewed quarterly (for L2+)?
10.4Does onboarding include all pre-access requirements (background check, NDA, training, ≥80% comprehension test, 30/60/90-day probation)?
10.5Are offboarding SLAs met (account disablement, physical-access revocation, temporary multi-sig suspension, triggered rotation)?
10.6Are keyholders geographically distributed for L2+ (single jurisdiction is a fail for L2+)?
Section 11 — Final attestation
11.1Have all questions above been answered truthfully?
11.2Is supporting evidence retained and ready to provide on request?
11.3Are all eight Critical Requirements (B.1.1, B.1.2, B.2.1, B.3.1, B.4.1, B.5.2, B.7.3, B.8.1) In Place?
11.4Are any applied Compensating Controls and Customized Approach Objectives documented (if any)?
Figures are forward-looking targets, not current state.
Section 11 — Final attestation
Are all eight Critical Requirements (B.1.1, B.1.2, B.2.1, B.3.1, B.4.1, B.5.2, B.7.3, B.8.1) In Place?
The eight Critical Requirements undergo full Defined-Approach testing regardless of baseline certifications — carry-over never applies to them.
SAQ-C2 / C3 / C4 — structure (stubs)
The full SAQ-C2, C3 and C4 question libraries are published by the Council as separate documents at the CCSA v1.0 release. Below are their structural deltas relative to SAQ-C1 (Annex 4 §A4.9). The overall structure (Sections 1–11) is shared; the segment-specific questions differ.
SAQ-C2 — non-custodial wallets (vendor + device)
Focus on vendor scope (build infrastructure, release management, employee controls) and device scope (on-device entropy generation, Secure Enclave/StrongBox usage, signing and recovery UX). Questions for domains B.3.3 (hot/warm/cold tiering) and B.4.2 (dual control) are marked N/A. The subject is the product vendor, not the end user.
Full library coming with CCSA v1.0SAQ-C3 — exchanges (CEX and DEX front-ends)
Additional questions on customer-wallet session security (extended B.4.3), real-time reconciliation (B.7.3), withdrawal time-locks (B.6.4) and the hot/warm/cold AUM split. Session tokens are category D CCM; signing-time 2FA is mandatory.
Full library coming with CCSA v1.0SAQ-C4 — issuers (stablecoins / RWA / fiat-tokens)
Focus on mint/burn key protection (B.6.1 for mint keys), mint time-locks (B.6.4) and unauthorized-mint detection (B.7.3). Proof of Reserves, reserve composition and holder rights are out of CCSA scope and are not included in the SAQ.
Full library coming with CCSA v1.0Checklists
The 9 cryptography review items from Annex 2 §A2.8 that a CCSA-QSA runs against every CCM-related cryptographic operation.
Open the auditor checklist ->The Report on Compliance structure: a per-requirement assessment worksheet, Defined-Approach testing procedures, and carry-over validation. Reference template from Annex 3.
Open the ROC worksheet ->Compact “is this control covered?” lists for each of the eight domains B.1–B.8, with Critical Requirements flagged.
Go to the domain lists ->Is supporting evidence retained and ready to provide on request?
Tools are the interactive layer of the standard: the self-assessment, checklists and worksheets you fill in on the site. They help you prepare for an audit, surface gaps early, and see which controls are already covered. A self-assessment is not a certification: a full audit is performed annually for all levels (Section D.4.1).