SOC 2 Compliance Checklist: 8 Controls Auditors Test

Key Takeaways

• SOC 2 covers five criteria, but only Security (nine Common Criteria, CC1 through CC9) is mandatory. Many first audits start with Security only.
• The AICPA has not published an official SOC 2 compliance checklist. Every checklist is a practitioner interpretation of the Trust Services Criteria.
• Access controls (CC6) and change management (CC8) are common sources of findings in first-time audits. Self-approvals, undated access reviews, and slow offboarding are recurring failure modes.
• A focused preparation sprint can get a team to Type I audit-ready or to the start of a Type II observation period, but a completed Type II report usually requires several additional months of controls operating consistently.
• Technical controls are often more straightforward than the process scaffolding and people scaffolding that keep evidence, reviews, and workflows running across the audit period.

An enterprise prospect's security questionnaire just landed in your inbox. Somewhere on page three it asks for a SOC 2 Type II report, which stalls the deal until you can produce one. You need to know what SOC 2 requires, how long it takes, and what it costs.

Most tools already in your stack cover meaningful ground. The harder question is whether they're running across the fleet day after day. A compliance dashboard often shows green when the underlying tools have drifted off some endpoints. A focused sprint can reach audit-ready; the longer game is keeping those controls in place through the observation period the auditor reviews.

Need a SOC 2 stack live before the next audit? Get a quote from Zip and reach audit-ready in 14 days.

SOC 2 Scopes Narrowly for a First Audit

When an enterprise buyer asks for a SOC 2 Type II report, here's what you're committing to. SOC 2 is an attestation framework from the American Institute of Certified Public Accountants (AICPA). It covers five Trust Services Criteria, organized across nine Common Criteria series (CC1 through CC9): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security is mandatory, which is the practical reason most first audits at 15- to 200-person companies cover only that.

Each additional category multiplies auditor hours and evidence collection, so adding Availability or Confidentiality to your first report turns a focused engagement into a much larger one. Year two is the right time to expand, once your team has lived through a full cycle and knows what pace it can sustain.

SOC 2 has two report types, Type I and Type II. Type I assesses control design at a single point in time. Type II assesses whether controls operated consistently over months, which is why enterprise customers typically require it.

The SOC 2 Compliance Checklist

The point of the audit is to confirm controls operated through the audit period, with the evidence to prove it. Auditors sample logs, exports, and dated approvals, then trace each one back to the policy that requires it. Exceptions get written where documentation doesn't match operational reality.

1. Access Controls Generate the Most Findings (CC6)

CC6 commonly draws the largest share of audit exceptions in first SOC 2 audits. Auditors sample terminated employees from human resources (HR) records, cross-reference against system access logs, and verify the system owner reviewed and approved continued access with before-and-after documentation.

• Unique user IDs for every account; no shared credentials.
• Multi-factor authentication (MFA) enforced on production systems, cloud infrastructure, and admin consoles. Auditors test whether MFA is technically enforced at the infrastructure level. They probe for bypass paths: direct AWS console access, legacy app logins, database credentials that skip your identity provider.
• Role-based access control (RBAC) tied to job function and least-privilege principles.
• Production access restricted to designated personnel with documented approvals. For any new or changed access, auditors expect documented approval from the system owner, the date approved, the specific role requested, and the business purpose.
• Quarterly access reviews with a named reviewer and sign-off dates. Evidence must include the review date, the approver's name, and before-and-after access lists showing what changed. A review without remediation documentation is a finding.
• Offboarding with timestamped access revocation for every departed employee. Auditors compare the HR termination date against the IT revocation timestamp. Contractors must be included in the same process.

The thread across all six is documentation. A control without an evidence trail looks identical to no control at all when an auditor samples it.

2. Encryption Evidence Lives in Three Layers (CC6)

Encryption sounds simple until you break it into layers: transport, storage, and key handling. A team that audits one and assumes the rest carries over leaves exceptions on the floor.

• Transport Layer Security (TLS) 1.2+ enforced on all external-facing and service-to-service communication.
• Encryption at rest on databases, file storage, and backup media. Disk encryption must be verified as active via mobile device management (MDM) reports.
• Key management documented: ownership, rotation schedule, and access controls on key material.

Auditors verify each layer separately. Each one needs its own evidence trail.

3. Endpoint Evidence Outweighs Written Policies (CC6, CC7)

Most breaches enter through endpoints, which is why auditors weight endpoint controls heavily. The evidence they want is machine-generated: tool exports showing what's deployed, on which devices, and with what configuration.

• Endpoint Detection and Response (EDR) on all company-managed endpoints, in active prevention mode. An EDR running in detection-only or audit mode satisfies detective control requirements. Preventive control requirements generally expect active prevention mode.
• Mobile device management (MDM) enforcing disk encryption, screen lock, and remote wipe.
• Full-disk encryption on all laptops (BitLocker, FileVault).
• Patch management with service-level agreements (SLAs) for OS and critical software updates.
• Vulnerability scanning at defined intervals with remediation tracking. Scans without remediation tickets are a gap. Auditors look for closure records.
• Asset inventory with ownership and configuration status.

MDM and EDR exports carry more weight than screenshots or self-attestations. One uncovered device is enough to compromise the fleet, so scope device coverage carefully and avoid pulling bring your own device (BYOD) or contractor hardware in unnecessarily.

4. Logging and Monitoring Prove Your Controls Work (CC7)

Monitoring tools should be actively reviewed and supported by evidence of that review to satisfy CC7 expectations. Auditors check three things: the policy defining monitoring requirements, tool configurations showing alert rules, and ticket records proving alerts were reviewed and dispositioned.

• Centralized log aggregation from production, cloud infrastructure, and security tools.
• Log retention policy enforced for a defined period.
• Alerts for anomalous activity, failed logins, privilege escalation, and configuration changes.
• Incidents logged with response activities, root cause, and remediation timestamps.
• Periodic review of privileged and contractor account logs.

Together these five pieces give auditors a reconstructable timeline. Missing any one weakens what the auditor can verify when they sample.

5. Auditors Expect Evidence of Incident Logging (CC7)

A documented incident response plan is enough for Type I. For Type II, the plan also needs to have been exercised during the audit period. Readiness assessments are often used before a SOC 2 audit to identify gaps.

• Incident Response Plan: detection, classification, containment, eradication, recovery, post-incident review.
• Incident classification matrix with severity levels and response SLAs.
• Internal escalation paths and external notification procedures.
• At least one tabletop exercise conducted and dated during the audit period. Undated documentation doesn't satisfy Type II.
• Incident ticketing tracking timestamps, severity, owner, and resolution.

Auditors require both the plan and the evidence it ran. The tabletop record, the incident tickets, and the dated post-incident reviews carry the second half.

6. Vendor Gaps Hide in Default Settings (CC9)

Vendor management lands among the most common findings in first audits, with later failures common when reviews stop happening. The scope of what qualifies as a subservice organization is broader than most lean teams assume: your cloud provider, your customer relationship management (CRM) platform, and your payroll platform all potentially qualify.

• Vendor inventory of all third parties with access to systems or customer data, with risk tiering distinguishing critical from non-critical.
• SOC 2 reports (or equivalent) collected from critical vendors during the current audit period. Pre-period reviews don't count.
• Evidence those reports were reviewed: covering the auditor's opinion, control environment, and findings.
• Annual vendor review schedule with a defined process.
• Vendor API tokens and access revoked when relationships end.
• Vendor configuration verification. Vendor security features often require explicit opt-in. A database provider may require you to enable encryption yourself; verify configurations rather than trusting defaults.

Vendor reviews look easy in year one because auditors just want to see the process exists. In year two, they want evidence the reviews happened, and teams who set the workflow up once and forgot it end up writing exception responses.

7. Training Without Records Becomes a Finding (CC1, CC6)

Most teams already run training and screening in some form. What auditors care about is whether the audit period contains per-employee records of each activity.

• Background checks for hires with access to sensitive systems or customer data. "We usually do that" without documented records is a gap.
• Awareness program at hire and annually, with per-employee completion records. Training that exists without evidence all employees completed it within the audit period is insufficient.
• Signed Acceptable Use Policy from every employee.

All three require per-employee evidence covering the audit period. Aggregate completion rates fail the sampling test.

8. Self-Approvals Are a Common Type II Finding (CC8)

Auditors apply a five-element change management standard covering authorization, documentation, testing, approval, and implementation. Every production change needs all five, which the auditor verifies by sampling changes and tracing them backward through the chain.

• Change request and approval workflow for all production changes.
• Separation of duties: no developer deploys their own code without a second approver. For lean teams, system-enforced branch protection rules are the achievable path.
• Code review with pull request approval before merge. The approver must be a different person from the committer.
• Testing in non-production before deployment, with evidence retained.
• Emergency change procedure with retroactive documentation in the ticketing system.
• Change records (tickets, approvals, deployment logs) maintained across the audit window.

Self-approvals are a common Type II finding because separation of duties fails when one person both commits and approves. Infrastructure-as-code and console changes are in the same scope. Change management is the process scaffolding that trips up teams who focused only on technical controls in year one.

The Policy Library You Need

A first SOC 2 audit usually requires roughly 16 policy documents, with auditors often requesting additional supporting policies. Every policy needs a visible effective date, version number, named owner, and review frequency.

Policy	Primary Criteria
Information Security Policy	CC1, CC2
Access Control Policy	CC6
Data Classification Policy	CC5, CC6
Encryption Policy	CC6
Endpoint Security Policy	CC6, CC8
Logging and Monitoring Policy	CC7
Incident Response Policy	CC7
Change Management Policy	CC8
Vendor Management Policy	CC9
HR Security / Acceptable Use Policy	CC1, CC6
Risk Assessment + Register	CC3, CC9
Business Continuity / Disaster Recovery Policy	CC7, CC9

Your stated frequency defines management's evidence review schedule, while the auditor determines how to test and sample. If your access control policy says quarterly access reviews, auditors require quarterly evidence confirming they occurred. A consistent quarterly approach outweighs an aspirational monthly one. Write what you can sustain.

The 12-Week Sprint to Audit-Ready

Most companies start SOC 2 work the day the enterprise questionnaire arrives, with the deal already on hold. A structured 12-week sequence can reach Type I audit-ready or begin the Type II observation period. Compressing further than that usually means accepting compromises in policy quality or evidence depth.

Weeks 1 to 2: Scope and kick off. Pick your Trust Services Criteria (Security only for your first audit), define the system boundary, engage the auditor early, and assign internal control owners. The scope decisions made here set the size of every later sprint week, so the auditor conversation should happen before you start building.

Weeks 3 to 4: Gap assessment. Map current controls against the Common Criteria. Build a control matrix with gap owners and deadlines. Common readiness gaps often include areas such as offboarding, change management, separation of duties, user access reviews, vendor management, and policy documentation.

Weeks 5 to 10: Build and implement. Draft and approve core policies. Implement technical controls across the checklist categories. Policy approvals, training, and operating the controls long enough to generate evidence fill the rest of the window. The Type II observation clock starts when controls are running.

Weeks 11 to 12: Prepare for the auditor. Consolidate documentation, prepare architecture and data flow diagrams, brief the team, begin Type I fieldwork.

A Built and Managed Security Platform (BMSP) changes the math on the technical layer of this sprint. In Weeks 3 to 4, the platform's existing connections to MDM, EDR, identity, and infrastructure surface what's deployed and how it's configured, accelerating the technical portion of gap assessment. In Weeks 5 to 10, it compresses technical deployment to roughly 14 days by enforcing the configurations SOC 2 requires across each connected tool. That leaves the team's time for policy and process work, the layer that determines whether year two stays on track.

After readiness work is complete, the Type II observation period begins and evidence accumulates over the defined review window. A completed Type II report typically takes six to nine months from this point.

Your Tools Already Map to SOC 2

Most SOC 2 technical controls already live in your stack; the audit question is what evidence those tools produce when an auditor samples. The tools sort into three buckets: evidence collection tools (ECTs) like Vanta and Drata; endpoint security tools like Jamf, Microsoft Intune, and CrowdStrike, covering device management and endpoint protection; and production and infrastructure (P&I) tools.

SOC 2 Criteria	Identity and Access Management (IAM)	MDM	EDR
CC6.1	Multi-factor authentication (MFA) enforcement, single sign-on (SSO)	Disk encryption, screen lock	N/A
CC6.2	Provisioning, deprovisioning	N/A	N/A
CC6.3	Role assignments, reviews	N/A	N/A
CC6.6	N/A	Firewall, patching	Vulnerability detection
CC6.7	N/A	Device enrollment	N/A
CC6.8	N/A	App controls	Prevention policies
CC7.1 to CC7.4	Anomalous login detection	N/A	Alert triage, incident response integration

An MDM only counts as a control when devices are fully enrolled and the compliance policy is enforced via conditional access. EDR running in detection-only mode satisfies only the detective control requirement; auditors generally expect prevention mode for preventive controls. When prevention isn't feasible, document the gap and the compensating controls.

Auditors collect two kinds of evidence from your stack. Compliance platforms like Vanta and Drata produce one kind, aggregated reports showing which controls exist. The kind that carries more weight is tool-native exports from MDM, EDR, identity, and infrastructure, which show live configuration and coverage at sample time. A green compliance dashboard doesn't satisfy an auditor if the underlying MDM export shows half the fleet unenrolled or the EDR report shows agents in detection-only mode.

Zip operates at the tool-native layer. Its native connections to Jamf, Microsoft Intune, CrowdStrike, and Okta produce the MDM enrollment reports, EDR coverage exports, and conditional access evidence auditors sample. When a device drops out of MDM enrollment or an EDR agent goes unhealthy, the platform corrects it before the next evidence sample.

All of that is technical-layer evidence. The process and people evidence (policy approval records, training completion logs, named control owners) comes from a fractional CISO or internal lead.

For the full deployment treatment, see SOC 2 for Startups; for what drifts between audits, see Compliance Drift.

The Cadence That Keeps It Alive

Operating posture requires evidence collection year-round. Later audits cover a much longer period of control operation than the first one. Missed activities can't be remediated retroactively once they fall inside the audit window. Keep the trail running across all twelve months so it's already in place when auditors sample.

Frequency	Task
Continuous	Log collection, evidence aggregation, control monitoring
Weekly	Vulnerability scans
Quarterly	Access reviews, tabletop exercises, risk assessments
Annual	Penetration testing, training refresh, full policy review, vendor assessments

Automated drift detection closes the technical side of ongoing compliance. When a device drops out of MDM enrollment, an EDR agent goes unhealthy, or an encryption key fails to escrow, the platform self-heals or routes an actionable alert. BD Emerson, a fractional CISO firm running compliance across a portfolio of client companies, standardized on Zip to keep technical controls running between audits in every client account. The firm reports 100% audit success across SOC 2, ISO 27001, GDPR, and NIST and saves clients over $200,000 per year on compliance costs.

For fractional CISOs and vCISOs running compliance across multiple client environments, the portfolio problem compounds. Every client has its own tooling state, evidence trail, and audit cycle. Zip lets a fractional practice operate one configuration across every client account, with drift detection running in parallel for each. See why vCISOs use Zip for the operating model.

Start Before the Questionnaire Arrives

An audit tests whether your systems match what your policies say they do across the entire observation period. Most teams already own the tools that satisfy SOC 2. The audit comes down to active enforcement, documented processes paired with evidence, and a people layer that holds up to per-employee sampling.

Timing is the variable you control. Start SOC 2 preparation twelve weeks before your first enterprise request. That window lets you scope to Security only, set sustainable review schedules, deploy technical controls in weeks, and build the operational rhythm for year two. The companies that struggle hardest are the ones who treated year one as a sprint and year two as coasting.

Get a quote and see how lean teams get audit-ready in 14 days.

FAQs About SOC 2 Compliance

What Is the Difference Between SOC 2 Type I and Type II?

Type I assesses whether controls are designed correctly at a single point in time, like a snapshot of your environment when the auditor arrives. Type II assesses whether those controls operated consistently across an observation period, typically three to twelve months, with auditors sampling logs, exports, and approvals from across the window. Most enterprise customers require Type II because design alone doesn't show how the controls behave over time.

Should a First SOC 2 Audit Include All Five Trust Services Criteria?

No. Scope your first audit to Security only, the one criterion that's mandatory. Each additional Trust Service Criterion (Availability, Processing Integrity, Confidentiality, Privacy) multiplies auditor hours, evidence collection, and control surface area. The right approach is to have direct conversations with customers about which criteria they need for their use case before committing to a broader scope, then expand in year two if necessary.

How Long Does SOC 2 Preparation Take?

A 12-week sprint can reach Type I audit-ready: policies approved, technical controls deployed, evidence-collection processes running. A completed Type II report typically takes six to nine months from that point because it requires the observation period (three to twelve months of operational evidence) plus the auditor's fieldwork. Some teams begin Type II observation immediately after Type I to compress the overall timeline.

What Creates the Most Findings in First-Time SOC 2 Audits?

Access control failures generate most findings. The patterns are usually undated user-access reviews, terminations where IT revocation lags HR by days or weeks, and MFA enforced in policy but not at the infrastructure level. The second consistent flag is change management, specifically self-approvals where committer and approver are the same person. Subservice organizations missing from the vendor inventory, or vendor SOC 2 reports collected outside the audit period, round out the top three.

How Does a Built and Managed Security Platform Support SOC 2?

A BMSP deploys, configures, and continuously enforces the technical controls SOC 2 requires: MDM enrollment, EDR coverage, MFA enforcement, encryption, and audit logging. Where compliance platforms stop at reporting whether controls exist, a BMSP continues into enforcement by detecting drift and remediating when devices fall out of compliance. The result is an audit trail that reflects what's actively deployed across the fleet.