SOC 2 Controls Checklist: 37 Criteria You Need to Meet

CC1: Control Environment (5 Criteria)

CC1.1 — COSO Principle 1: The entity demonstrates a commitment to integrity and ethical values. Evidence: written code of conduct, ethics policy, employee handbook with code of conduct acknowledgment signatures. CC1.2 — Board oversight: the board or equivalent body oversees security risk. Evidence: board meeting minutes showing security/compliance agenda items, security committee charter, risk committee structure documentation.

CC1.3 — Organizational structure and reporting lines are defined. Evidence: organizational chart, RACI matrix for security responsibilities, job descriptions for roles with security responsibilities. CC1.4 — Competence and commitment: HR processes ensure personnel are qualified and trained. Evidence: job descriptions with security competency requirements, security awareness training completion records, background check policy and completion records.

CC1.5 — Accountability is enforced. Evidence: documented performance management process, records of disciplinary action processes (anonymized), security violation tracking. For most startups, CC1 is addressed through a combination of HR documentation (offer letters, handbooks, training records) and board/leadership meeting records.

CC2: Communication and Information (3 Criteria)

CC2.1 — Relevant quality information is generated and used. Evidence: security dashboards, monitoring alert configurations, vulnerability scan reports showing security metrics are tracked and used in decision-making. CC2.2 — Internally, the entity communicates information necessary to support security objectives. Evidence: internal security communications (email/Slack announcements about security policies), security policy distribution records, all-hands meeting agenda items covering security updates.

CC2.3 — Externally, security information is communicated to relevant parties. Evidence: public privacy policy, security page, vendor contract security clauses, customer security questionnaire responses, SOC 2 report distribution tracking. CC2 is often addressed with minimal effort — the evidence exists across multiple channels, it just needs to be organized into a retrievable record before the audit.

CC3: Risk Assessment (3 Criteria)

CC3.1 — The entity specifies objectives clearly and identifies risks related to those objectives. Evidence: documented business and security objectives, risk register with identified risks tied to those objectives. CC3.2 — The entity identifies and assesses risks from fraud and other internal/external sources. Evidence: annual risk assessment records showing systematic identification of internal risks (employee error, insider threat) and external risks (cyber attacks, supply chain compromise).

CC3.3 — The entity assesses the potential for fraud and evaluates controls designed to address it. Evidence: fraud risk assessment section of the risk register, control descriptions addressing identified fraud scenarios (segregation of duties, transaction approval limits, audit trail requirements).

CC3 is the criterion group most commonly missing in first-time assessments. Startups rarely have formal risk management processes — risk discussions happen in engineering standups and leadership meetings but are not documented. Implementing CC3 requires creating a risk register (a living document), conducting an annual risk assessment meeting with leadership, and recording the outcomes. This can be done in a single day using a template, but must be done before the observation period begins.

CC4: Monitoring Activities (2 Criteria)

CC4.1 — The entity selects and develops ongoing and/or separate evaluations to verify controls are working. Evidence: automated control monitoring configurations (AWS Config rules, GitHub security alerts), compliance platform dashboard showing continuous control status, records of internal control testing or self-assessments conducted during the year. CC4.2 — Deficiencies identified by evaluations are communicated to appropriate parties and corrected. Evidence: records of control monitoring alerts and how they were investigated and resolved; deficiency tracking process documentation; examples of control gaps identified internally and remediated before the audit.

CC4 incentivizes continuous monitoring rather than point-in-time checks. Auditors look favorably on companies that have automated control health monitoring — it demonstrates that the company identifies and corrects failures proactively rather than waiting for the auditor to find them.

CC5: Control Activities (3 Criteria)

CC5.1 — The entity selects and develops general control activities. Evidence: documented control framework showing which controls address which risks; control descriptions in the system description; control testing results from internal reviews. CC5.2 — The entity selects and develops technology controls. Evidence: automated controls embedded in the tech stack (branch protection, CI/CD checks, IAM policies, security group rules) with configuration documentation.

CC5.3 — Control activities are deployed through policies and procedures. Evidence: documented policies for each control category; procedures showing how controls are operated (access review checklist, incident response playbook, change management process); evidence that procedures were followed during the observation period.

CC6: Logical and Physical Access (8 Criteria)

CC6.1 — Logical access security controls restrict access to information assets. Evidence: identity provider configuration showing SSO enforcement, MFA enforcement report, network access controls (VPC, security groups), encryption-at-rest configuration. CC6.2 — Provisioning and removal of access are authorized and timely. Evidence: access provisioning records tied to onboarding tickets; de-provisioning records showing access removed within SLA of termination; HR-to-IT offboarding process documentation.

CC6.3 — Role-based access is implemented consistent with segregation of duties. Evidence: access matrix showing role definitions; screenshots of RBAC configurations in production systems; evidence that developers don't have direct production database write access. CC6.4 — Physical access to data centers is restricted. Evidence: AWS's SOC 2 report (covers AWS data center physical access) or your data center provider's physical security documentation if co-located.

CC6.5 — Logical access to system resources is authorized. Evidence: quarterly access review records showing all user access is reviewed and approved by managers; records of access removed following review. CC6.6 — Logical access is managed for new, changed, and terminated personnel. Evidence: onboarding checklist with access provisioning steps; offboarding checklist with access removal steps and completion timestamps. CC6.7 — Unauthorized internal and external network access is restricted. Evidence: firewall rules documentation, VPN configuration, network segmentation diagram, no public-facing admin consoles. CC6.8 — Malware and unauthorized software are detected and prevented. Evidence: EDR/AV deployment on all employee devices, configuration showing auto-update, malware detection logs.

CC7: System Operations (5 Criteria)

CC7.1 — Vulnerabilities in system components are detected and monitored. Evidence: vulnerability scanning tool configuration (Snyk, Dependabot, AWS Inspector), scan reports from during the observation period, vulnerability remediation tracking records. CC7.2 — Environmental threats are detected and mitigated. Evidence: GuardDuty findings and investigation records, WAF configuration and block logs, DDoS protection configuration.

CC7.3 — Incidents are identified and responded to. Evidence: incident log covering all incidents during the observation period; incident response runbook; post-incident review records for significant incidents; mean time to detect (MTTD) and mean time to respond (MTTR) tracking. CC7.4 — Incident response is addressed and communicated. Evidence: customer breach notification procedures; regulatory notification procedures; records of communications with affected parties during any incidents.

CC7.5 — Recovery from identified incidents is performed. Evidence: incident recovery checklists; records of system restoration following incidents; lessons learned documentation incorporated into runbook updates.

CC8: Change Management (1 Criterion)

CC8.1 — Changes to infrastructure, data, software, and procedures are authorized, tested, and approved. This single criterion covers the entire change management process and is one of the most evidence-intensive criteria in the Common Criteria.

Evidence required: change management policy; branch protection rules showing required reviewers before merge; CI/CD pipeline configuration showing automated tests run before deployment; deployment logs for the observation period; records of infrastructure change approvals (Terraform PRs, AWS Change Manager requests); emergency change procedure with after-the-fact approval records; records of change advisory board or equivalent review for significant changes.

The most common CC8.1 exceptions: (1) developers with direct push access to main/production branch bypassing PR review requirements; (2) infrastructure changes made via the AWS console without a corresponding change ticket; (3) emergency changes with no documentation or retroactive review. All three are preventable with branch protection policies and IaC enforcement.

CC9: Risk Mitigation (2 Criteria)

CC9.1 — The entity identifies, selects, and develops risk mitigation activities. Evidence: risk treatment decisions in the risk register; controls documentation showing how identified risks are mitigated; risk acceptance decisions for risks that are accepted rather than mitigated; evidence that risk treatment plans are implemented and monitored.

CC9.2 — The entity assesses and manages risks from business partners and third parties. Evidence: vendor inventory listing all critical third-party vendors; completed vendor risk assessments for each vendor (including review of their SOC 2 reports or completion of security questionnaires); vendor contract security clauses (DPA, security addendum); records of ongoing vendor monitoring (annual review of vendor SOC 2 reports, re-assessment when vendor scope changes).

CC9.2 is the vendor management criterion. Companies need to demonstrate that before granting a vendor access to customer data or critical systems, they assessed that vendor's security posture. The assessment doesn't have to be elaborate — downloading and reviewing a vendor's SOC 2 report, recording the review date, and noting any concerns is sufficient for most vendors.