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