SOC 2 readiness is not mysterious -- it is a structured process of implementing controls, gathering evidence, and making sure your documentation reflects reality. This guide walks through all nine Common Criteria (CC) categories, explains what auditors actually look for in each one, and flags the gaps that generate the most findings. If you are preparing for your first SOC 2 audit, start here.
New to SOC 2? If you are not sure what SOC 2 is yet, read What is SOC 2? first, then come back to this guide. This article assumes you know what SOC 2 is and are ready to start preparing for it.
Readiness means your controls exist, are documented, and are operating -- and you have evidence proving all three. Auditors do not take your word for it. They ask for proof, and "proof" means records: configuration screenshots, log exports, signed policy acknowledgments, access review sign-offs, vulnerability scan reports.
The biggest mistake companies make in SOC 2 preparation is implementing controls but not generating evidence that the controls are running. A firewall that logs everything is useless for audit purposes if nobody reviews those logs and those reviews are not recorded. Monitoring without records is the same as not monitoring, at least from an auditor's perspective.
An auditor approaches every control with the same question: "How would I know this is actually happening if I could not ask anyone?" If the answer is "you just have to trust us," that is a gap. If the answer is "here is the log, here is the report, here is the signed record," that is evidence. Build for evidence, not just for controls.
The Security Trust Services Criterion is organized into nine categories (CC1-CC9), each covering a different area of your control environment. Here is what each one requires and where the common gaps are.
CC1 is the "does management care about security?" category. Auditors are evaluating whether your organization has the cultural and structural foundation for effective security -- not just whether technical controls are configured correctly. It covers the COSO Principle framework: integrity, board oversight, org structure, competence commitments, and accountability.
What auditors look for:
Common gap: Security responsibilities exist in practice but are not written into job descriptions or acknowledged in hiring documents. Auditors want to see it in writing, not just assumed as part of the role.
CC2 covers how your organization communicates about security -- both internally (do employees know the policies?) and externally (do customers know how their data is handled?). This is often treated as a formality, but it generates findings more often than people expect.
What auditors look for:
Common gap: Training happens verbally or via a video that nobody logs. Auditors need dated records of who completed what. Annual security training with a completion log is the minimum bar.
CC3 requires a formal risk assessment process -- not just an awareness that risks exist, but a documented approach to identifying them, evaluating their likelihood and impact, and deciding what to do about them. This does not have to be a 50-page document. A structured risk register with clear methodology is sufficient for most SOC 2 engagements.
What auditors look for:
Common gap: Risk assessment exists as a document but has not been updated in 18 months and was never reviewed after the company migrated to a new cloud provider. Stale risk assessments are a finding.
CC4 covers how you monitor whether your controls are working -- through internal audits, penetration tests, vulnerability assessments, and management reviews. The key requirement is that you have a formal process for evaluating your controls, not just implementing them and hoping for the best.
What auditors look for:
Common gap: Annual pen test is conducted but findings are not remediated before the next audit. A list of unaddressed critical findings from a year-old pen test is not a good look.
CC5 is where your policy library comes in. Auditors verify that you have documented, approved, and deployed controls to mitigate your identified risks. This means written policies and procedures -- not just technical configurations. A firewall that blocks port 22 is a control. A policy that says "port 22 must be blocked except via jump host" is the documented control that makes it auditable.
What auditors look for:
Required policies for most SOC 2 engagements: Information Security Policy, Access Control Policy, Acceptable Use Policy, Change Management Policy, Incident Response Plan, Risk Assessment Policy, Business Continuity Plan, Disaster Recovery Plan, Vendor Management Policy, Data Classification Policy, Password / Authentication Policy, Encryption Policy.
Common gap: Policies exist but are three years old and describe a technology environment the company no longer uses. Policies need to reflect your actual current state, not your 2022 environment.
CC6 is where most SOC 2 findings live. It covers every aspect of who can access what: user provisioning and deprovisioning, MFA, privileged access, physical facility access, data transmission controls, and software restriction. It has eight sub-criteria (CC6.1 through CC6.8), each requiring specific evidence.
Most access control problems are not technical -- they are process failures. The firewall works. MFA is configured. But the former employee from six months ago still has an active account because offboarding was done informally. Or the quarterly access review happened once and then was forgotten. The technical controls are fine. The human processes around them are not.
Key evidence requirements for CC6:
Most common finding: Access not revoked within 24 hours of termination, or no documented quarterly access reviews. Both are almost guaranteed findings if your offboarding process is informal.
CC7 covers how you detect threats, respond to incidents, and recover from disruptions. It is essentially your security operations capability -- vulnerability management, monitoring, incident response, and business continuity. Five sub-criteria, each needing evidence that the activities actually happen.
What auditors look for:
Common gap: Monitoring tools are configured and generating alerts, but there is no evidence that anyone reviews them. Alerting without review is not monitoring -- it is just generating unread emails.
CC8 has a single sub-criterion (CC8.1) but it covers a lot of ground: how you authorize, design, develop, test, and implement changes to systems and infrastructure. This trips up engineering-heavy companies that move fast and document later -- or never.
What auditors look for:
Common gap: Engineers deploy directly to production without formal change records. "We use GitHub" is not sufficient on its own -- auditors want to see pull request reviews, approvals, and deployment records tied to specific changes.
CC9 has two sub-criteria: managing residual risk (the risk that remains after controls are applied) and vendor risk. The vendor risk component (CC9.2) has grown in prominence as supply chain attacks have become more common. Auditors now scrutinize vendor relationships carefully.
What auditors look for:
Common gap: The company uses 15 SaaS tools with access to customer data but has assessed 3 of them. Partial vendor assessment coverage is a finding. Build and maintain a vendor inventory, then assess each one based on data access and criticality.
Once you know what controls you need and what evidence they require, the practical task is collecting and organizing that evidence. An auditor typically requests evidence via a client portal or shared folder. Being disorganized here -- submitting the wrong file, not knowing where a specific record is, scrambling to find a log from nine months ago -- wastes everyone's time and signals that your processes are informal.
| Evidence Type | Examples | How to Collect It |
|---|---|---|
| Configuration screenshots | MFA enabled, firewall rules, SSO setup | Screenshot at a point in time; re-capture if settings change |
| Log exports | Access logs, auth logs, admin activity | Export from SIEM, IdP, or cloud provider; store with timestamps |
| Signed records | Policy acknowledgments, access review sign-offs | DocuSign, HRIS system, or a dated email confirmation |
| Reports | Vulnerability scan reports, pen test results | Export from scanning tool; retain full reports not just summaries |
| Tickets / records | Change requests, access requests, incident records | Export from your ticketing system (Jira, ServiceNow, etc.) |
| Training records | Who completed security awareness training and when | LMS export or a signed completion log |
| Vendor assessments | Completed vendor questionnaires, SOC 2 reports for vendors | Request from vendors; store with your vendor inventory |
Practical tip: Set up a shared folder organized by CC category before you start collecting evidence. As you implement each control, drop the evidence in the right folder immediately. By the time the observation period ends, your evidence package is mostly ready rather than being built in a panic the week before fieldwork starts.
If you have 90 days before starting your observation period, here is a realistic priority order:
By the end of 90 days, you should have controls in place and be generating evidence. The observation period then documents that those controls continued to operate consistently -- not that you scrambled to implement them right before fieldwork.
A structured Word document mapping all 33 Common Criteria controls to their evidence requirements. Includes a Readiness Summary Scorecard, Required Policy Library tracker, and Gap Remediation table. Fill in the brackets and you have a readiness plan.
Get the Checklist → $29All 110 NIST SP 800-171 practices organized by domain. Free PDF, instant access.