Section D — Certification Levels

Section D — Certification Levels#

D.0. Introduction#

This section defines the three CCSA certification levels, the conformance assessment methodology (binary status per requirement), critical requirements, compensating controls, and re-assessment procedures.

Numeric scoring (5-point scales, weighted averages) is not used. For the detailed rationale behind the methodology, see Section 0.7.

D.1. Certification Levels#

D.1.1. Level 1 — Foundation#

Minimum conformance:

• ≥ 90% of the applicable mandatory requirements of the segment have status In Place (including In Place with Customized Approach)
• ≤ 10% of the applicable mandatory requirements may have status Compensating Control
• 0% of the applicable mandatory requirements in status Not in Place
• All Critical Requirements (see Section D.2.5) — mandatorily in status In Place via the Defined Approach. The Customized Approach is not permitted (Section 0.7.2). CC is entirely prohibited for B.1.1, B.1.2, B.5.2, B.7.3 (Section 0.8.2); CC is permitted only at Level 1 with Council Chief QA Officer approval for B.2.1, B.3.1, B.4.1, B.8.1 (Section 0.8.3)

Target audience:

• Early-stage startups
• MVP projects
• Test / pilot installations
• Small projects with AUM / market cap < $5M

Audit procedure characteristics:

• A full audit is conducted annually
• In the interim period between annual full audits — two self-assessment SAQs at 6-month intervals
• Compensating Controls are possible (≤ 10%) with CCSAC approval
• The Customized Approach is permitted for non-critical requirements
• Re-certification audit deadline: no later than 60 days before expiry of the current certificate

D.1.2. Level 2 — Standard#

Minimum conformance:

• ≥ 95% of the applicable mandatory requirements of the segment have status In Place
• ≤ 5% of the applicable mandatory requirements may have status Compensating Control
• 0% of the applicable mandatory requirements in status Not in Place
• All Critical Requirements (see Section D.2.5) — mandatorily in status In Place via the Defined Approach
• Applicable recommended (R) requirements have meaningful coverage (≥ 75% recommended; does not block certification, but is recorded in the ROC)

Target audience:

• Mature exchanges with a regular customer base
• Serious wallets with a large number of users
• Most custodians and issuers
• Regulated VASPs — the minimum required level

Audit procedure characteristics:

• A full audit is conducted annually
• The ROC is submitted to the Council for QA review (sampling 10% of all Level 2 certifications)
• Compensating Controls are possible (≤ 5%) with CCSAC approval + peer review by another accredited CCSAC
• Quarterly compliance review with CCSAC participation between annual audits
• Re-certification audit deadline: no later than 60 days before expiry of the current certificate

D.1.3. Level 3 — Advanced#

Minimum conformance:

• 100% of the applicable mandatory requirements of the segment have status In Place OR
• ≤ 2.5% of the applicable mandatory requirements may have status Compensating Control with Council (Chief QA Officer) approval
• 0% of the applicable mandatory requirements in status Not in Place
• All Critical Requirements (see Section D.2.5) — mandatorily in status In Place via the Defined Approach
• All applicable recommended (R) requirements — status In Place (recommended; does not block, but is recorded)

Target audience:

• Systemically significant players (top-10 exchanges, the largest custodians)
• Regulated VASPs in strict jurisdictions
• Issuers of large stablecoins (market cap > $100M)

Audit procedure characteristics:

• A full audit is conducted annually
• Unscheduled Council inspections (random sampling 100% of Level 3 certifications annually)
• Real-time compromise detection is mandatory (Section B.7.3)
• Geographic distribution of keyholders is mandatory (Section B.8.5)
• Compensating Controls — only in exceptional cases (≤ 2.5%) + Council approval
• Continuous monitoring between annual audits with quarterly review
• Re-certification audit deadline: no later than 90 days before expiry of the current certificate

D.2. Assessment Methodology#

D.2.1. Requirement Assessment Statuses#

Each applicable requirement of the standard is assessed by the CCSA-QSA auditor in one of the following statuses (full description — Section 0.7):

Intermediate statuses (Partially In Place, Partial Compliance, partial conformance) are not used. Any material gap in implementation results in status Not in Place.

D.2.2. Calculation of the Conformance Level#

The conformance level is determined by the following formula:

Applicable mandatory requirements = all requirements of the segment with status M
                                    from the summary tables of Section C, minus those
                                    that received status Not Applicable
                                    during the audit per the Applicability Notes

In Place ratio = (number of In Place requirements +
                  number of In Place with Customized Approach requirements) /
                 number of applicable mandatory requirements

CC ratio = number of requirements with status Compensating Control /
           number of applicable mandatory requirements

Certification at level L is achieved if and only if:

• In Place ratio ≥ the threshold of level L (see Section D.1)
• CC ratio ≤ the limit of level L (see Section D.1)
• Number of Not in Place requirements = 0
• All Critical Requirements (see Section D.2.5) — status In Place

D.2.3. Applicability of Requirements to the Assessed Entity#

Before the calculation, the auditor must record in the ROC which requirements are applicable to the Assessed Entity:

• Applicability by segment: see the summary tables C.X.Y in Section C
• Applicability by level: some requirements have thresholds based on AUM / volume / user base (for example, B.6.4 time-locks)
• The Applicability Notes of a specific requirement may contain condition-based exclusions

Any requirement removed from scope as Not Applicable requires justification in the ROC.

D.2.4. Recommended Requirements#

Requirements with status Recommended (R) for a specific segment / level are not counted in the calculation of the In Place ratio for certification purposes, but are recorded in the ROC in a separate section. Their coverage is recommended to improve the quality of protection and to prepare for transition to the next level.

D.2.5. Critical Requirements#

The following requirements are Critical and are subject to stricter rules:

The following rules apply to Critical Requirements:

1. The Customized Approach is not permitted — only the Defined Approach.
2. A Compensating Control is not permitted for B.1.1, B.1.2, B.5.2, B.7.3 (see Section 0.8 "Prohibited CC").
3. A Compensating Control for the remaining Critical Requirements (B.2.1, B.3.1, B.4.1, B.8.1) is permitted only at Level 1 with mandatory approval of the Council Chief QA Officer (not only the CCSAC).
4. Status Not in Place in any Critical Requirement = automatic fail regardless of the overall In Place ratio.

D.3. Compensating Controls#

D.3.1. Conditions of Application#

A Compensating Control is applied when:

• A standard requirement (Defined Approach) cannot be met for a business / legal / technical reason
• The Customized Approach is also not applicable (the Customized Approach Objective is unattainable in the current architecture, or it is a Critical Requirement for which the Customized Approach is prohibited)
• An alternative measure exists that provides equivalent or superior protection of CCM
• The CCSA-QSA auditor confirms the adequacy of the CC through independent testing

D.3.2. Documenting the CC#

Each CC is documented in the following format (see Section 0.8):

Original Requirement:    [code and wording]
Constraint:              [reason for the impossibility of fulfillment via the Defined and Customized Approach]
Compensating Measure:    [alternative measure]
Risk Assessment:         [assessment of the residual risk]
Validation:              [how the auditor confirms effectiveness]
Re-validation:           [when the CC is reviewed]

D.3.3. CC Limits#

D.3.4. Prohibited CC#

A CC cannot be applied to the following requirements:

• B.1.1 (CCM Identification) — the foundation of the standard
• B.1.2 (CME Definition) — the foundation of the standard
• B.5.2 (Revocation) — without the possibility of revocation, protection of CCM is impossible
• B.7.3 (Watch-only compromise detection) — the primary mechanism for detecting compromise of CCM

For the remaining Critical Requirements (B.2.1, B.3.1, B.4.1, B.8.1), a CC is permitted only at Level 1 with Council approval.

D.3.5. CC Re-validation Cycle#

Each applied CC is reviewed:

• At every annual full audit
• Immediately upon any change to the infrastructure affecting the Compensating Measure
• Immediately upon the occurrence of an incident that could have been prevented by the original requirement

If a CC is found to be ineffective or the constraint has disappeared, the requirement reverts to status Not in Place until the deficiency is remediated.

D.4. Re-assessment Cycles#

D.4.1. Full Audit#

All levels undergo a full audit annually. The two-year cycle applied in previous versions for Level 1 has been abolished — in crypto infrastructure, the rate of change is incompatible with a 24-month interval.

D.4.2. Interim Reviews#

Interim reviews do not replace the annual full audit, but are mandatory for maintaining certification status.

D.4.3. Unscheduled Inspections#

The Council may order unscheduled inspections upon the occurrence of any of the following events:

• A materialized significant CCM compromise incident
• Random sampling within the QA Program (10% of Level 2 certifications; 100% of Level 3 certifications annually)
• A regulatory request
• A substantiated complaint from a client / partner
• A change in the version of the standard requiring a compliance review before the end of the current term

D.4.4. Re-certification under prior major version during overlap period#

After the release of a new major version (see Section 0.10.4), the previous major version remains valid for re-certifications for a 24-month overlap period. Rules:

• Eligibility: the right to use the overlap belongs to an Assessed Entity whose previous certificate was issued under the prior major version and whose validity period expires within the overlap period
• ROC/AOC/SAQ template: the template of the major version under which the previous certification was issued is used
• CCSAC accreditation: an accredited CCSAC retains the right to conduct audits under both major versions during the overlap period
• Transition deadline: after the expiry of the 24-month overlap period, all re-certifications are conducted only under the new major version; organizations with a certificate under the prior version must migrate before the next scheduled re-assessment
• Notification: the Council notifies all certificate holders and CCSACs of the start and end of the overlap period no later than 6 months in advance

D.5. Status changes#

D.5.1. Certification Statuses#

D.5.2. Public Disclosure of Status#

• active / pending renewal: in the public LVCS registry
• expired: in the registry with a notice of expiry (90-day grace period)
• suspended: publicly flagged in the registry with the reason (without disclosing sensitive details of the investigation)
• terminated: removed from the registry + Council press release
• incident-flagged: flagged with a warning; incident details are disclosed after coordinated disclosure

D.6. Audit Documentation#

D.6.1. Documents Generated During the Audit#

1. ROC (Report on Compliance) — a detailed report by the CCSA-QSA. Template — Annex 3 (Section 15).
2. AOC (Attestation of Compliance) — the final public declaration. Template — Annex 5 (Section 17).
3. SAQ (for Level 1 interim self-assessments) — a self-assessment questionnaire. Template — Annex 4 (Section 16).
4. Compensating Controls worksheets (if applicable) — one document per CC.
5. Carry-over justifications (if applicable) — for each carried-over requirement.
6. Customized Approach documentation (if applicable) — a description of the implementation, risk assessment, and the procedure for testing effectiveness.

D.6.2. Document Retention#

Retention has been increased to 7 years (from 5 years in previous draft versions) to align with industry audit standards and regulatory requirements.

D.6.3. Public AOC#

The AOC must contain a public summary for publication in the LVCS registry:

• Assessed Entity
• Segment (C.1–C.4)
• Level (Level 1 / 2 / 3)
• Date of issue and validity period
• CCSAC and Lead Auditor names
• Scope of certification
• Compensating Controls (high-level summary without disclosure of sensitive details)
• Carry-over baselines (PCI DSS, GOST 57580, CCSS, SOC 2, ISO 27001 — which have been applied)

The full ROC is a confidential document; disclosure restrictions — see Annex 3 Section 14 (Confidentiality, Retention, Archival).

Related#

• 11 — Section C — Application Segments — previous section
• 13 — Annex 1 — Glossary — next section
• 01 — Front Matter — Scope, definitions, normative references — general assessment methodology (Section 0.7)

Sources#

See Section 0.4 Normative References in the Front Matter.

Conceptually related PCI DSS v4.0.1 requirements:

• ROC Reporting Template v4.0.1 — the structure of the audit report
• AOC v4.0.1 — the structure of the attestation of compliance
• PCI DSS v4.0 Customized Approach — the methodology of the alternative conformance path
• Compensating Controls Worksheet (Appendix B of PCI DSS) — the format for CC documentation