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.
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:
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.