The AICPA's Trust Services Criteria organize the SOC 2 Security category (the only required category) into nine Common Criteria groupings — CC1 through CC9. Most of the technical control failures that delay audits and produce exceptions in Type 2 reports cluster in two of them: CC6 (Logical and Physical Access Controls) and CC7 (System Operations).
Understanding why these two areas generate the most findings helps you prioritize readiness work before an auditor starts asking for evidence.
CC6: Logical and Physical Access Controls
CC6 covers the full lifecycle of access to systems, data, and facilities. It's where most organizations have the most ground to make up.
What Auditors Are Looking For
CC6.1 — Restricting access to authorized users: Your controls should ensure that only people with a legitimate business need can access systems containing customer data. The specific questions auditors probe:
- How is access provisioned? Is there a documented approval process, or do employees just ask IT informally?
- Is access granted based on role and least privilege, or do most people have broad access because it's easier?
- Is privileged access (admin accounts) separated from standard user access?
- Is multi-factor authentication enforced on critical systems, especially remote access?
CC6.3 — Access provisioning and deprovisioning: Access management has to be a documented process with evidence. A log showing when access was granted, by whom, and on whose approval. An equally important — and frequently worse — problem: deprovisioning. When an employee leaves or transfers, is their access removed immediately? Auditors will pull a sample of terminated employees from HR records and verify their system access was revoked. Former employee accounts that remain active are one of the most common CC6 exceptions in Type 2 reports.
CC6.5 — Access reviews: It's not enough to get provisioning right at the start. Accumulated privilege — accounts that gain access over time as roles expand, without ever having it removed — is a real risk and a CC6 finding. Periodic access reviews, typically quarterly or semi-annual, where managers confirm that current access reflects current roles, are expected. The evidence isn't just that you have a policy saying reviews happen — it's the completed review records.
CC6.7 — Transmission of confidential information: Encryption of data in transit. TLS for web applications, secure file transfer for bulk data, encrypted email or secure messaging for PHI or confidential customer data. The control exists for most organizations; the gap is often in completeness — a new API or integration that wasn't included in the encryption requirement, or legacy internal tools transmitting in plaintext.
The Pattern Behind Most CC6 Findings
Access management problems almost always have the same root cause: access is managed reactively and informally. Someone needs access; IT grants it. No one formally reviews whether the access is still needed six months later. When someone leaves, the ticket to revoke access competes with everything else in the IT queue.
The fix isn't a new tool — it's a defined, documented process with evidence of execution. Auditors aren't impressed by access management software; they're impressed by records showing it was used correctly and consistently over the period.
CC7: System Operations
CC7 covers how you detect, monitor, and respond to security events. Organizations consistently think they're doing better here than they are. The audit is usually the correction.
What Auditors Are Looking For
CC7.1 — Configuration and vulnerability management: Detecting changes to configurations and identifying security vulnerabilities. Do you have a documented baseline for system configurations? Do you know when configurations deviate from that baseline? Is there a process for identifying vulnerabilities — scanning cadence, CVE monitoring — and verifying that critical vulnerabilities are remediated within defined SLAs?
CC7.2 — Monitoring for anomalies: Logging and log review. Systems that could affect the service need to generate logs. Those logs need to be reviewed. This is where a lot of organizations discover the gap between capability and practice: logging is enabled, but no one is reviewing the logs. Alerts exist, but there's no documented process for triaging them.
The auditor question isn't "do you have logging?" — it's "show me evidence that logs were reviewed." That evidence is tickets, review records, alert triage documentation, or SIEM dashboards with a history of analyst engagement. A log system that no one looks at doesn't satisfy CC7.2.
CC7.4 — Incident identification and response: When a security event occurs, what's the process? Is it documented? Is there evidence it was followed? Auditors will look for incidents that occurred during the Type 2 period and ask to see the incident response documentation — timeline, containment actions, root cause, resolution.
No incidents during the period doesn't satisfy this criterion. Auditors want to see that the process exists and works, which means running tabletop exercises and documenting them, not hoping an incident happens conveniently before the audit.
The Jump from Type 1 to Type 2
SOC 2 Type 1 tests whether controls are designed correctly — does the control exist, and is it designed to achieve its objective? Type 2 tests whether controls operated effectively over the audit period (typically six to twelve months) — was the control actually applied, consistently, throughout the period?
This is where organizations are most frequently surprised. A company might achieve a Type 1 with reasonable effort, then discover during Type 2 evidence collection that:
- Access reviews were scheduled quarterly but only occurred once
- Vulnerability scanning was running but findings weren't being remediated within the policy-defined SLAs
- The security awareness training policy requires annual completion by all employees, but training records show 40% completion
- An access deprovisioning that should have happened in March finally happened in June
Type 2 failures aren't usually design failures — they're consistency failures. The control was designed correctly. It just wasn't applied every time it was supposed to be.
This is why building evidence-collection discipline during readiness — not just implementing controls but generating and retaining evidence of their operation — is the work that makes the difference between a clean Type 2 and one with exceptions.
CC3: Risk Assessment
One more criterion that's worth flagging because it's frequently underdone: CC3 requires a formal risk assessment process. Organizations typically have a risk management policy. They often don't have documented evidence of actually conducting risk assessments against that policy.
What auditors want to see: a risk assessment that was completed during or before the audit period, documented in a format that shows methodology, identified risks, ratings, and treatment decisions. Not a policy describing the process — evidence of the process being executed.
SOURCES
- AICPA, Trust Services Criteria (2017, updated 2022): aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
- AICPA, Mapping of AICPA Trust Services Criteria to NIST Cybersecurity Framework: aicpa-cima.com
- SSAE No. 18, Attestation Standards: Clarification and Recodification: aicpa-cima.com
Preparing for a SOC 2 audit and want to know where you actually stand? Schedule a consultation to walk through your readiness against the Common Criteria.
