PlainAudit

SOC 2 Readiness Assessment: The Control-Level Checklist Your Auditor Will Actually Test

Every SOC 2 readiness assessment checklist you find online lists the same high-level items: “implement access controls,” “create security policies,” “perform risk assessments.” That’s not wrong—it’s just not useful. When an auditor arrives, they don’t ask “do you have access controls?” They ask for your quarterly access review records, your terminated employee deprovisioning logs, and evidence that MFA is enforced on every privileged account.

This checklist works at the Common Criteria level—the nine control categories (CC1–CC9) that form the backbone of every SOC 2 examination. For each category, you’ll see what auditors specifically request and the evidence gaps that cause the most exceptions.

SOC 2 Readiness Assessment Checklist by Common Criteria

CC1 — Control Environment

This is governance, not technology. Auditors evaluate whether your organization has formal oversight of security controls. Having strong technical security but no governance structure still generates exceptions.

  • Board or management oversight: Documented evidence that leadership reviews security posture (meeting minutes, quarterly security reports to management)
  • Organizational structure: Clear security responsibilities assigned to specific roles, with an org chart showing security ownership
  • Code of conduct / ethics policy: Written policy signed annually by all employees, with completion records
  • HR policies: Background checks for new hires, onboarding security training with completion records, documented exit procedures
  • Accountability mechanisms: Documented consequences for policy violations
Tip CC1 is where organizations with strong technical security still get caught. Having no formal onboarding process, no annual policy sign-off, or no evidence of management oversight generates exceptions regardless of how good your firewalls are. Approximately 50% of a SOC 2 audit covers governance and operational controls, not technology.

CC2 — Communication and Information

  • Internal communication: Security policies distributed to all employees with read receipts or acknowledgment records
  • External communication: System description document, customer-facing security practices page, incident notification procedures
  • Security awareness training: Completed at onboarding and annually, with documented topics and attendance records

CC3 — Risk Assessment

  • Formal risk assessment: Documented methodology, conducted at least annually, covering all in-scope systems
  • Risk register: Maintained list of identified risks with likelihood, impact, and assigned owners
  • Fraud risk consideration: Documented assessment of fraud risk (even if the conclusion is “low risk,” auditors need to see you considered it)
  • Change identification: Process for reassessing risk when systems, personnel, or business processes change

CC6 — Logical and Physical Access Controls

This is the #1 failure area in first-time SOC 2 audits. Auditors test these controls with the most rigor, and access control deficiencies generate more exceptions than any other category.

  • User provisioning: Documented process for granting access, with approval records for each new account
  • MFA enforcement: Enabled on all privileged accounts and remote access, with configuration screenshots showing timestamps
  • Quarterly access reviews: Evidence of periodic reviews of user access rights, with revocation records for excessive or unnecessary privileges
  • Deprovisioning: Terminated employees removed within 24 hours, with timestamped evidence showing HR termination date compared against access removal date
  • Least privilege: Users have only the access needed for their role, documented in an access matrix or role-based access control (RBAC) configuration
  • Physical access: Badge access logs and visitor logs for on-premises infrastructure, or your cloud provider’s SOC 2 report if fully cloud-hosted
Common Mistake The most frequent CC6 exception: a multi-day gap between an employee’s termination date and their account deactivation. Auditors compare HR records against identity provider logs and flag any delay. Automate deprovisioning through your identity provider or build a same-day offboarding checklist with IT and HR coordination.

CC7 — System Operations

  • Vulnerability scanning: Regular scans (weekly or monthly) with documented remediation timelines for critical and high findings
  • Penetration testing: At least annual, performed by an independent third party, with a remediation report showing findings addressed
  • Incident response plan: Written plan with defined roles, communication procedures, escalation paths, and customer notification timelines
  • Incident response testing: At least one tabletop exercise per year, with documented scenarios and outcomes
  • Business continuity and disaster recovery: Written plans with defined recovery time objectives (RTOs), tested at least annually with documented results

CC8 — Change Management

  • Change authorization: All production changes require documented approval before deployment (pull request approvals, change tickets)
  • Testing before deployment: Evidence of testing for each change (QA records, staging environment validation, automated test results)
  • Segregation of duties: The person who writes code is not the same person who approves and deploys it. This is a frequent gap at small companies where one person wears multiple hats.
  • Rollback procedures: Documented ability to revert changes if issues arise post-deployment

CC4, CC5, CC9 — Monitoring, Control Activities, Risk Mitigation

  • Monitoring (CC4): Regular evaluation of control effectiveness through internal reviews or automated monitoring tools, with documented remediation of any deficiencies found
  • Control activities (CC5): Technology controls selected based on your risk assessment, deployed per written policy, with evidence they operate as intended
  • Vendor management (CC9): Inventory of critical third-party vendors with documented risk assessments, evidence of ongoing monitoring (collecting vendor SOC 2 reports annually, security questionnaire responses)

How to Use This Checklist

Work through each CC category and mark your status: evidence exists, evidence is incomplete, or control is missing entirely. Prioritize your remediation starting with CC6—it generates the most audit exceptions and every SOC 2 examination tests it rigorously. Then address CC7 (system operations) and CC8 (change management) before moving to governance categories.

For each gap you identify, note the specific evidence you need to create. “Implemented” without evidence is functionally identical to “not implemented” from an auditor’s perspective. The average SOC 2 Type II audit requires over 150 distinct pieces of evidence covering the full observation period—point-in-time screenshots are insufficient.

Tip Self-assessments consistently run 20–30% optimistic compared to professional readiness assessments performed by CPA firms ($3,000–$15,000). If your checklist shows 80% readiness, an auditor would likely find you closer to 55–65%. Budget remediation time and resources accordingly.

When a Checklist Isn’t Enough

A checklist identifies what to look at. A control-level assessment measures how ready you actually are, with weighted scoring that reflects how auditors prioritize findings. PlainAudit’s free SOC 2 gap assessment evaluates all 51 AICPA Trust Service Criteria with weighted scoring—so your CC6 access control gaps weigh more than your CC9 vendor management gaps, matching how auditors assess materiality. You get a readiness score, cost estimate, and prioritized gap list without creating an account.

For organizations with existing certifications like ISO 27001 or CMMC, the assessment also calculates framework overlap—showing how much of SOC 2 your current controls already cover, so you don’t remediate gaps that are already closed.