What qualifies as valid evidence for a CCSS requirement?

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.

How is the scope of a system under CCSS defined?

Scope is the boundary of what’s being audited.
Anything that interacts with key material is part of the scope of a CCSS trusted environemnt.
In practice, scoping means identifying:
Where keys are generated, stored, accessed, and used
Who can interact with them
What systems or services are involved
During an audit, the scope often gets refined as the auditor asks more detailed questions and learns how things actually work in the system being audited.
A good rule:
If it could impact the key material, it’s in scope.