CCSS uses system designations to describe how a system is structured in relation to key material management and responsibility. They help clarify whether a system holds its own keys, provides services to other systems, or relies on other systems as part of its design.
The system designations are as follows:
Systems that hold all keys to the system that controls the entity’s own funds.
A CCSS Qualified Service Provider (QSP) is a system that meets many of the requirements for CCSS certification with the exception of the few requirements that another system has control over. A QSP is a system that facilitates a subset of custody services to other systems and therefore is only required to meet certain requirements. This means that if a system uses a QSP, the audit focus is only on the few remaining requirements to become certified.
An information system that meets all applicable CCSS requirements in totality. In situations where an information system utilizes a CCSS certified Qualified Service Provider (QSP) information system (e.g. a wallet infrastructure provider’s wallet software) as part of their information system, some CCSS requirements may be met by the QSP information system, as determined by the CCSSA conducting the CCSS audit.
Third parties are not automatically out of scope. If they touch key material or affect how it’s managed, they are part of the system.
The scope of a CCSS audit is defined by the CCSS Trusted Environment. That includes any people, processes, or technology that can impact the security of key material. If a provider is involved in key material generation, storage, access, usage, or could impact the key material in any way, they are in scope.
This often includes custodians, wallet providers, cloud infrastructure, signing services (multi-sig or MPC), and managed security or DevOps providers.
Using a third party does not shift responsibility. The system being audited is still responsible for meeting CCSS requirements.
In practice, this means either the third party is in scope and their controls are assessed, or the system relies on a Qualified Service Provider (QSP), where responsibilities are clearly defined.
If a third party is in scope, there needs to be visibility into how their controls work. Without that, it becomes difficult to show requirements are met.
Using a well-known provider is not enough on its own. What matters is whether the controls can be understood, evidenced, and audited as part of the system.
Yes.
A single entity can have multiple systems, and each system can be scoped and audited independently.
For example, an organization might have:
A custody platform
A trading or exchange system
An internal treasury system
Each of these could be treated as a separate system if the key management processes, infrastructure, or teams differ.
Each system would:
Define its own Trusted Environment
Be assessed against CCSS requirements
Receive its own certification level
This allows organizations to certify specific parts of their environment without needing to include everything under one scope.
An entity is the organization. A system is what gets audited.
The entity is the company, business unit, or organization that owns or operates the CCSS trusted environment. The system is the specific set of people, processes, and technology that handle key material that make up the CCSS trusted environment.
CCSS certification applies to the system, not the entity.
This means the audit focuses on how key material is managed within a defined environment, not everything the organization does. An entity may have multiple systems with different designs, controls, and risk profiles, and each one is considered separately.
Evidence needs to show two things: the control is defined, and the control is actually followed.
In a CCSS audit, evidence is gathered using four methods: review, inspect, observe, and interview. These are used together to understand how a system actually operates.
Review focuses on documentation. This includes policies, standards, and procedures. Policies define the goal, standards describe how the goal is met, and procedures outline the steps. One common issue is relying on external documentation, like an open-source guide, instead of maintaining internal policies and standards. That is not sufficient on its own.
Inspect is checking system configurations and technical components directly. This is a “trust but verify” step. If documentation says MFA is required, inspection confirms it is implemented, configured correctly, and applied across the environment.
Observe is watching a process take place. This could include reviewing logs or adding a new user. If observing in real time is not practical, the process should be walked through step by step. The goal is to confirm that processes are carried out as defined.
Interview is speaking with personnel responsible for the system. This often reveals how work is actually done, including gaps not reflected in documentation. The focus is whether policies, standards, and procedures are being followed or bypassed.
No single method is enough on its own. Documentation without implementation does not hold up. Configurations without defined processes do not hold up. If interviews or observations do not match what is documented, that raises concerns. Valid evidence comes from consistency across all four: what is defined, what is implemented, what is demonstrated, and what is actually happening in practice.
CCSS uses three levels to show how a system meets the Standard: Level 1, Level 2, and Level 3. Each level builds on the one before it. A system is certified at a level based on the requirements it meets across all applicable aspects. To achieve a higher level, the system must meet that level’s requirements in addition to the requirements from the lower levels.
Level 1 establishes the foundation for key material management. At this level, controls are defined, processes are documented, and there is evidence that those processes are followed. This includes core controls across the key lifecycle such as generation, storage, access, and usage, along with supporting documentation and operational evidence. Level 1 shows that key material management is structured, implemented, and operating in practice.
Level 2 builds on Level 1 by strengthening how controls are enforced. Controls are applied more consistently across the environment. Additional requirements expand coverage across the key lifecycle. Level 2 includes all Level 1 requirements.
Level 3 builds on Levels 1 and 2 and reflects a high level of operational maturity. Controls are consistently applied across the full key lifecycle, with stronger technical safeguards in place to protect key material. Processes are repeatable and hold up under normal operations and stress scenarios. Risk from single points of failure or compromise is reduced. Level 3 includes all requirements from Levels 1 and 2.
Each level is assessed through an audit. A system either meets the requirements for a level or it does not. The levels are cumulative, so moving up means meeting more requirements and applying controls with greater consistency across the system.