SOC 2 Common Criteria (CC) Framework Explained for Engineers
A technical breakdown of the SOC 2 Common Criteria (CC1–CC9) — what each category covers, how it maps to AWS and GitHub controls, and which criteria show up most in audit findings.
What Are the SOC 2 Common Criteria?
The Common Criteria (CC) are the organizational and operational security controls that form the foundation of every SOC 2 report. Unlike the Trust Service Criteria that may be optionally included (Availability, Privacy, etc.), the Common Criteria are evaluated in every SOC 2 engagement — they represent the minimum security requirements the AICPA deems necessary for any attestation.
There are nine CC categories (CC1–CC9). Understanding what each covers helps engineering teams know which controls to prioritize and why specific failing checks matter for their report.
CC1 — Control Environment
What it covers: The foundation of your security program — management's commitment to security, the organizational structure supporting it, and the standards of conduct for personnel.
What auditors evaluate: Does senior management demonstrate commitment to security? Is there a designated security role or owner? Is there a code of conduct or acceptable use policy that employees acknowledge?
AWS/GitHub relevance: Low direct relevance — this is organizational, not technical. The evidence is a written security policy, an org chart, and employee acknowledgments.
CC2 — Communication and Information
What it covers: How security policies and responsibilities are communicated to internal and external stakeholders.
What auditors evaluate: Are security policies written and accessible to employees? Are they reviewed and updated? Do employees receive training?
Evidence: Policy documents, training completion records, policy acknowledgment signatures.
Common finding: Policies exist but employees haven't acknowledged them. Training completion is undocumented.
CC3 — Risk Assessment
What it covers: How your organization identifies, assesses, and prioritizes security risks.
What auditors evaluate: Is there a documented risk assessment process? Has it been run during the observation period? Are identified risks tracked and remediated?
Evidence: Annual risk register with documented findings, risk owners, remediation status, and a date-stamped review.
Common finding: No formal risk assessment exists — risk management is ad-hoc and undocumented.
CC4 — Monitoring Activities
What it covers: How management monitors that controls are operating effectively.
What auditors evaluate: Do you have ongoing monitoring of your control environment? Are deficiencies identified and addressed?
AWS relevance: AWS Config, Security Hub, and SecureSpect's continuous checks are direct implementations of CC4. Automated monitoring that surfaces control failures satisfies this criterion better than periodic manual review.
CC5 — Control Activities
What it covers: The specific policies and procedures that mitigate identified risks — the operational controls.
What auditors evaluate: Do documented controls match operational reality? Are controls actually implemented?
AWS relevance: High. Most technical controls — IAM, encryption, CloudTrail, GuardDuty, network security — fall under CC5 as the operational implementation of your security commitments.
CC6 — Logical and Physical Access
What it covers: How access to systems, data, and facilities is controlled and monitored. This is typically the most tested criterion in SOC 2 audits.
Key sub-criteria:
- CC6.1 — Logical access requires identification and authentication
- CC6.2 — Prior to issuing system credentials and granting access, authorized management approves access
- CC6.3 — Access is modified based on personnel and role changes
- CC6.4 — Access credentials are revoked when access is no longer needed
- CC6.6 — Logical access controls over transmission (encryption in transit)
- CC6.7 — Logical access controls over encryption at rest
- CC6.8 — Controls to prevent or detect unauthorized or malicious software
SecureSpect checks for CC6: 26 of SecureSpect's 49 checks map to CC6. This is the highest-weight criterion.
CC7 — System Operations
What it covers: The processes to monitor security events, respond to threats, and recover from disruptions.
Key sub-criteria:
- CC7.1 — Detection of threats and anomalies
- CC7.2 — Monitoring and evaluation of security events
- CC7.3 — Response to identified security incidents
- CC7.4 — Evaluation of security incidents and their impact
Common finding: GuardDuty is enabled but findings are not reviewed or documented as resolved. Monitoring without response doesn't satisfy CC7.2 and CC7.3.
CC8 — Change Management
What it covers: How changes to system components are authorized, tested, and tracked.
Key sub-criteria:
- CC8.1 — Changes are authorized, designed, developed, configured, documented, tested, approved, and implemented in a way that maintains security
AWS relevance: Infrastructure changes via Terraform/CDK with PR review, deployment pipeline controls, immutable infrastructure patterns.
CC9 — Risk Mitigation
What it covers: Risk mitigation activities including vendor/third-party risk management and insurance.
Key sub-criteria:
- CC9.1 — Risk mitigation activities are identified and selected based on risk
- CC9.2 — Vendor and partner risks are identified and managed
Prioritizing Your SOC 2 Work
Based on audit frequency data, the criteria ranked by finding frequency:
If you have limited preparation time: focus on CC6 first, then CC7 and CC8. These three categories account for roughly 70% of SOC 2 audit findings for AWS-native SaaS companies.
