During a CryptoCurrency Security Standard (CCSS) audit, requirements are evaluated based on whether the system sufficiently meets the intent and expectations of the control being audited.
If a system only partially meets a requirement, auditors will evaluate the nature and significance of the gaps, the effectiveness of any existing compensating controls, and the overall impact on the security posture of the system.
In some cases, a partially implemented control may result in a finding that must be remediated before certification can be granted or maintained. In other situations, compensating controls or additional evidence may demonstrate that the underlying security objective is still being effectively achieved.
Ultimately, certification decisions are based on the system’s ability to satisfy the applicable CCSS requirements at the audited certification level, not simply whether documentation or controls exist in a limited or incomplete form.
CryptoCurrency Security Standard (CCSS) certified systems are audited annually in order to maintain certification.
Because a CCSS audit is a point-in-time assessment, annual audits help verify that the system continues to meet the applicable requirements and certification level as the environment, infrastructure, personnel, and operational processes evolve over time.
In addition to the annual audit cycle, significant architectural or operational changes may require additional review or reassessment to determine whether the certified controls and security posture are still accurately represented.
A CCSS audit is a point-in-time assessment of the system as it existed during the audit period. If the system changes substantially afterward, the original audit may no longer accurately reflect the current security posture of the environment.
Examples of changes that could impact certification include modifications to wallet architecture, key management processes, signing workflows, custody models, access control structures, infrastructure providers, or other security-critical components.
Organizations are therefore expected to evaluate how changes affect the controls and requirements that were originally assessed. Depending on the nature and scope of the changes, additional review, updated evidence, or a reassessment may be necessary.
To remain certified, systems must also undergo annual audits to verify continued compliance with the applicable CCSS requirements and certification level. Maintaining certification requires ongoing operational discipline, change management, and continued alignment with the Standard over time.
Organizations interested in working toward CryptoCurrency Security Standard (CCSS) certification should start by gaining a clear understanding of how the Standard applies to their systems, operations, and custody model.
A common first step is reviewing the CCSS requirements and identifying which systems fall within scope for certification. From there, organizations typically perform a gap assessment to compare their current controls and operational practices against the requirements of the desired CCSS level.
Many organizations also choose to work with experienced CCSS Implementers or enroll team members in CCSS training to better understand the Standard and how to apply it in practice.
Before pursuing a formal audit, it is important to establish and document operational procedures, security controls, governance processes, and evidence collection practices. Organizations that prepare thoroughly before the audit process generally have a smoother certification experience.
Because every environment is different, the path to certification can vary depending on the complexity of the system, the organization’s existing security maturity, and the target certification level.
Auditors evaluating a system against the CryptoCurrency Security Standard (CCSS) look for evidence that security controls are not only documented, but actually implemented, followed, and operating effectively in practice.
The specific evidence requested depends on the system architecture and the CCSS requirements being evaluated, but commonly includes:
Auditors also conduct interviews and walkthroughs with personnel to verify that operational practices match the documented procedures.
The goal of a CCSS audit is not just to confirm that controls exist on paper, but to determine whether they are consistently implemented and functioning as intended within the live environment.
A key material inventory is a foundational tool for any CCSS assessment. It documents all key material, including where it exists, how it is used, who has access, and what systems depend on it. This directly supports scoping, evidence collection, incident response, and compliance with CCSS aspect requirements.
A key material inventory enables assessment of key lifecycle controls, including:
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.