The Trust Service Criteria — published by the AICPA as the basis for SOC 2 audits — are organized into five categories: Security (Common Criteria), Availability, Confidentiality, Processing Integrity, and Privacy. Most SaaS companies pursue Security plus one or two additional categories depending on their customers' requirements.
But "pursuing Security" really means pursuing 33 distinct criteria under the CC designation, and within those, the ones that generate the most audit findings are often the ones whose scope isn't obvious from the criterion text alone.
This post walks through the CC criteria structure, explains what each cluster actually tests, and identifies where the evidence gap tends to appear in practice. We're not going to reprint the full TSC text — you can get that from the AICPA directly. What we're offering here is the operational interpretation we've built through building automated evidence collection for each of these criteria.
The CC1-CC2 Cluster: Control Environment and Communication
CC1 covers the control environment — the organizational governance layer. This is where your security policies live, where your background check procedures are documented, where your board-level risk oversight is articulated. CC2 covers information and communication: do you have documented security awareness training? Do employees know how to report security incidents?
The evidence auditors look for here is primarily document-based: policy documents with version dates, training completion records, org charts showing accountability for security functions. The challenge isn't that these documents don't exist — most teams have them. The challenge is that they go stale. A security policy last updated fourteen months ago is technically a finding under CC1 because it suggests the control environment isn't being actively maintained.
Automated evidence collection can flag policy staleness: if a document hasn't been reviewed since the start of the audit period, that's a gap signal worth surfacing before the auditor asks.
CC3: Risk Assessment
CC3 is where a lot of first-time SOC 2 programs stumble. The criterion requires that the organization specify objectives, identify risks to achieving those objectives, analyze risks, and consider fraud risk. In practice, this means you need a documented risk assessment — not a spreadsheet you made for the audit, but something with evidence of cadence and update history.
We're not saying you need a formal NIST RMF implementation for a CC3 finding to be avoided. A lightweight quarterly risk register that's been consistently updated, with documented ownership and dates, satisfies the spirit of the criterion. What doesn't satisfy it is a single undated "risk assessment" document that was clearly created the week before the audit window opened.
The audit trail for CC3 needs to show: when was the risk assessment last run, who ran it, what changed from the previous version, and what was done about identified risks. That's the evidence chain. If it's not documented, the control can't be demonstrated as operating.
CC4-CC5: Monitoring and Control Activities
CC4 is about monitoring — are you tracking whether your controls are actually working? CC5 is about control activities — the specific technical and procedural controls you've put in place to mitigate risks identified under CC3.
This is the heart of where continuous monitoring becomes directly relevant. CC4.1 requires that the organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether components of internal controls are present and functioning. "Ongoing evaluations" is the standard's way of describing continuous monitoring.
A scenario that illustrates this: a growing data infrastructure company at around $5M ARR, twelve engineers, running a SOC 2 Type II for the first time. Their CC4 evidence package consisted of a Slack channel where someone manually checked that their logging pipeline was running each Monday morning. The auditor accepted it — technically, that is an ongoing evaluation. But it's fragile. One missed Monday, one person sick, one Slack notification missed, and that control stops operating. The evidence quality is weak even if the control technically passes.
CC5 evidence tends to be more technical: encryption configuration states, IAM policy exports, network firewall rule exports, change management ticket histories. The question the auditor is asking is: do you have the controls in your system description, and can you demonstrate they were in place throughout the audit period?
CC6: Logical and Physical Access Controls
CC6 is typically the most evidence-dense section of a SOC 2 audit. It covers logical access (who has access to what, how access is provisioned and deprovisioned, MFA enforcement, privileged access management) and physical access (data center access controls, typically handled by your cloud provider's SOC 2 report via a subservice organization carve-out).
The specific criteria that generate the most findings in practice:
- CC6.2: Prior to issuing system credentials, the entity registers and authorizes new internal and external users. In plain English: do you have a documented provisioning process, and can you show it was followed for the users provisioned during the audit period?
- CC6.3: The entity removes access when access is no longer authorized. This is the access review criterion. You need evidence of periodic access reviews — who was reviewed, who was removed, and when. The frequency isn't specified but quarterly is the industry standard; anything less frequent invites scrutiny.
- CC6.7: Transmission and storage encryption. This is the technical control criterion — evidence that data in transit and at rest is encrypted using appropriate mechanisms. For cloud infrastructure, this typically means CloudTrail logs or equivalent showing encryption settings for S3 buckets, RDS instances, and data transmission endpoints.
CC7-CC9: System Operations, Change Management, Risk Mitigation
CC7 covers system operations — monitoring for security events, incident management, and anomaly detection. The evidence chain here includes: SIEM alert logs, incident response tickets, post-mortem documentation for any security events during the audit period.
CC8 is change management: does your organization have a documented process for changes to infrastructure and code? Do changes go through review and approval? Is there an audit trail in your ticketing system? This is where Jira or similar systems become compliance evidence sources — the ticket history for changes made during the audit period is the evidence that your change management process was operating.
CC9 is risk mitigation and vendor management — specifically CC9.2, which requires that the entity assesses and manages risks associated with vendors and business partners who have access to its systems. This means you need a vendor risk management process: a record of which vendors were evaluated, what due diligence was done, and whether you collected their SOC 2 reports or equivalent.
The Evidence Gap Pattern
The most common evidence gap we see across these criteria isn't missing controls — it's missing evidence of operating controls. The access reviews happened, but the results weren't documented anywhere retrievable. The change management tickets were created, but they were closed without the approval comment. The risk assessment was done, but the previous version wasn't retained for comparison.
This is why the format and retention of evidence matters as much as the existence of the control. An auditor sampling CC6.3 for access reviews needs to see: a list of users reviewed, dates, who performed the review, and what action was taken. A Slack message saying "reviewed users, looks good" doesn't meet that bar.
When we built Tenurex's evidence collection, we structured every check output to answer exactly these questions: what was checked, what was the result, what source system produced the data, and what timestamp. That structure isn't arbitrary — it's what the CC criteria evidence requirements actually demand.
Understanding the criteria at this level of specificity changes how you build your compliance program. You stop thinking "do we have this control?" and start thinking "can we produce the evidence that this control was operating on any day within the audit period?" That's a harder question, and a more useful one.