FAQ

In scope is the protection of Critical Cryptographic Material (CCM) only: inventory, generation, storage, usage, lifecycle, wallet architecture, compromise detection, and personnel control (domains B.1–B.8). The boundary is deliberately narrow — the way PCI DSS protects only cardholder data. Deliberately out of scope: smart-contract security, Proof of Reserves and reserve composition, AML and on-chain forensics, trading-engine integrity and market manipulation. This is a positioning boundary, not a gap: the Council does not duplicate financial-intelligence functions and does not audit business logic.

To four segments (Section C): C.1 — custodial wallets and custodians (all 8 domains mandatory), C.2 — non-custodial wallets, where the certification subject is the vendor or device maker, never the end user, C.3 — exchanges for their custody infrastructure, C.4 — issuers for their mint/burn keys. The level in each segment is driven by its own scale metric (AUM, MAU, daily volume, market cap). An organization operating across several segments meets the union of all mandatory requirements, and the overall level is the strictest among its segments.

No. CCSS (CryptoCurrency Security Standard) is a baseline partner of CCSA, not a competitor: its requirements carry over, and CCSS levels I/II/III map to CCSA levels 1/2/3. The difference is coverage. CCSS focuses on key management for wallets and exchanges; CCSA additionally spans four segments (wallets, exchanges, custodians, issuers), adds regulatory positioning, a public registry of certified products, and a network of accredited auditors. We deliberately reference CCSS rather than rewrite it.

Crypto-infrastructure security is fragmented: each segment has its own standardiser (PCI SSC for cards, C4 for CCSS wallets, Rosstandart for GOST R 57580.3 in Russia, EBA/ESMA for MiCA in the EU), yet none covers cryptographic-material protection end-to-end, and 60–70% of the common-infrastructure work is duplicated. CCSA does not replace these standards; it bridges them through a single carry-over matrix and adds a narrow delta only for Critical Cryptographic Material. The posture is "reference, don't rewrite."

CCSA is a market initiative at the v0.2 draft stage; today it is a private standard, not a mandatory regulatory requirement. The target position is a global initiative with regional recognition. The path to recognition is on the roadmap: v1.0 is targeted for 2026-12-01, and the roadmap lists applications for recognition in non-Russian jurisdictions (VARA in Dubai, FSRA in ADGM) in 2028. These are planned targets, not confirmed status. CCSA complements regulators' requirements rather than competing with them.

The standard is run by the CCSA Council — a private standard-setting organization modelled on PCI SSC and the Linux Foundation. Standard decisions are made by an independent board (at least 7 members: an independent chairman, independent directors, and non-voting Founding-Member observer seats). 4pay.online is one Founding Member with one of seven seats — the first reference company, not the owner of the standard. At this stage the named composition of the board and committees is published as reserved seats with appointment timelines, not as confirmed names.

If the organization holds a valid baseline certificate (PCI DSS, GOST 57580, CCSS, SOC 2 Type 2, or MiCA), the corresponding CCSA requirements carry over under conditions: certificate age no more than 12 months at assessment start, at least 6 months remaining validity, scope overlap with the CCM environment, and registry-based authenticity validation. Categories: Full — the requirement is accepted without re-testing; Partial — only the crypto-specific portion is additionally tested; N/A — carry-over does not apply. With multi-baseline carry-over the auditor performs roughly 50% of the work versus a full audit — indicatively 1.5–2x cheaper for the client.

No. The eight Critical Requirements never carry over, regardless of the baseline certificate's strength — they are always tested in full via the Defined Approach. These include CCM inventory and classification (B.1.1, B.1.2), storage of Critical Cryptographic Material in HSM/MPC/Secure Enclave (B.3.1), secure key revocation and rotation (B.5.2), and compromise detection (B.7.3). For four of them a Compensating Control is fully forbidden; for the rest it is allowed only at Level 1 with Council approval. Their mapping in the tables is reference context only.

Through governance structure and a formal policy. Standard decisions are made by an independent board: the chairman and independent directors cannot be employees of the Council, a Member organization, or an accredited audit firm, and must have no financial ties to them. Annual disclosure of affiliations is mandatory for the board, C-level, and audit-firm owners. On an active conflict the participant recuses: no discussion, no vote, no access to materials, and the fact is recorded in a public register. Undisclosed conflicts carry sanctions up to annulment of the decision and termination of participation. This is a deliberate rejection of the "exchanges regulate themselves" model — the lesson of the CARC failure (2019–2022).

The total has three parts paid to different recipients and depends on segment and level; below are v0.2-draft indicative figures excluding VAT. Example for an exchange (C.3) targeting Level 2: Standard membership ~RUB 1.0M/year plus an LVCS L2 listing ~RUB 1.2M with the member discount — on the order of RUB 2.1M to the Council in year one. A smaller scenario — a non-custodial wallet vendor (C.2) at Level 1 — is on the order of RUB 0.58M to the Council. On top of this, the audit firm's (CCSAC) work is paid separately and depends on volume; carry-over reduces it. All figures are planned targets; the Council confirms the final estimate for your scenario.

There are three payment recipients with separated roles. The Council charges for Participating-Organization membership and for listing and maintaining a product in the LVCS registry (by level). The accredited audit firm (CCSAC) charges for the assessment itself and the report — that payment goes to the firm, not the Council. Audit firms and individual professionals in turn go through accreditation and a delta course. Separating recipients is part of the conflict-of-interest policy: the organization that runs the standard is not paid for any specific assessment.

The CCSA Council is a private standard-setting organization, not a government regulator, and the developer of the standard, not a guarantor. A certificate confirms conformance with the CCSA methodology at the time of assessment and reduces the risk of cryptographic-material compromise, but does not eliminate it and is not a guarantee against an incident. At this stage CCSA conformance is voluntary; the standard complements regulators' requirements and is intended as a recognized assessment methodology, not a replacement for them.

What is published now is the v0.2 draft: the full normative text is readable and under public consultation, but requirements may change before release. The v1.0 target date is 2026-12-01, taking effect 2027-01-01; the Council's commitments are fixed at v1.0. Substantive changes between versions and requirements under consultation are tracked in the changelog. You can already rely on the text to prepare — for final certification, target v1.0.