SOC 2 Compliance Checklist (2026): Step-by-Step Audit Prep

Most first-time SOC 2 audits slip 4 to 8 weeks past their target window. The cause is usually sequence, not the controls themselves. Scope gets defined after controls are built. Evidence gets collected without ownership assignments. Auditors get engaged before any gap assessment runs. This guide puts the work in the right order.

Save as PDF: Use your browser’s File > Print > Save as PDF to download this checklist for your team. For a scored, interactive version that surfaces your top gaps, try the SOC 2 readiness assessment tool.

Auditor’s PBC list just arrived? You’re past prep. See the SOC 2 Audit Checklist for what auditors test during fieldwork, what evidence to stage, and what triggers an exception.

Before starting, use the free SOC 2 readiness assessment to see which phases below need the most attention. The SOC 2 compliance overview covers cost and timeline benchmarks by organization size.

---

Phase 1: Scope and Report Selection

Cost benchmarks from our directory of CPA firms: Specialist firms (regional CPA practices focused on SaaS/tech audits) run $15,000 to $35,000 for Type 1 and $25,000 to $55,000 for Type 2. Mid-tier national firms run $35,000 to $65,000 for Type 2. Big 4 and large nationals run $60,000 and up. Scope (specifically the number of TSC categories and infrastructure components) is the single largest cost variable decided in Phase 1. These are estimates based on public pricing data from our directory; individual firm quotes vary.

Getting scope wrong is the most expensive Phase 1 mistake. A boundary that is too wide inflates audit cost. One that is too narrow can leave buyers questioning whether the report covers what they care about. Everything in Phases 2 through 4 flows from what you decide here.

Step 1: Choose Type 1 or Type 2

Type 1: Point-in-time assessment. The auditor evaluates whether controls are suitably designed as of a specific date. No observation period. Timeline: 8 to 14 weeks from engagement to report. Typical cost: $15,000 to $35,000. Best for teams that need a report in the near term and will layer in Type 2 subsequently.

Type 2: Sustained assessment over an observation period, typically 6 to 12 months. The auditor tests whether controls operated effectively across every day of the window, sampling evidence from the full period. Timeline: 9 to 18 months total. Typical cost: $25,000 to $80,000 (see the SOC 2 Type 2 audit cost breakdown for what drives the range). Required by most enterprise buyers.

If you are closing a deal that needs a report in 90 days, a Type 1 can cover the short-term need while your Type 2 observation period starts. Auditors often begin the Type 2 window the day after a Type 1 audit.

Step 2: Select Your Trust Service Criteria

The AICPA defines five TSC categories:

• Security (Common Criteria / CC series): Required for every SOC 2 report. Covers logical and physical access, change management, risk assessment, monitoring, and incident response.
• Availability: Add if customers have SLA commitments or if uptime is a purchase criterion.
• Processing Integrity: Add if you process financial transactions or data where accuracy and completeness are contractually required.
• Confidentiality: Add if you handle trade secrets or NDA-governed business data.
• Privacy: Add if you collect, use, or retain personal information subject to privacy commitments.

Security alone covers most B2B SaaS use cases. Each additional criterion extends audit scope and cost. Add criteria only where customers are actively asking for them. For a full breakdown of what each criterion requires, see SOC 2 Trust Services Criteria.

Step 3: Define System Boundary and Get Sign-Off

The system boundary is the explicit list of infrastructure, software components, people, and processes the audit covers. Everything outside it is out of scope.

Document the boundary before engaging an auditor. Include: cloud environments and regions, third-party service providers with access to in-scope data, employee populations with system access, and physical locations if applicable. A boundary that names specific AWS regions, databases, and support tooling is specific enough for an auditor to evaluate. “Our SaaS product” is not.

Get written sign-off from engineering, legal, and the executive sponsor. Scope changes after auditor engagement cost time and money.

---

Phase 2: Build Controls

Each Trust Service Criterion maps to controls your team has to build and operate. The ten areas below cover the full Security criterion and the most common add-on criteria. For the complete mapping of all five TSCs to specific controls and evidence, see the SOC 2 controls list.

Build in this order: access and encryption first, then policy documentation and monitoring, then change management and incident response, then the remaining three. Do not begin evidence collection (Phase 3) until each control has a named owner and a documented operating cadence. Controls that run without an owner fail silently, and no evidence accumulates for the observation period.

“The vast majority of first-time audit exceptions we issue come down to one of two things: access reviews that happened but were never saved as evidence, or change approvals that lived in Slack instead of the ticket. The controls were running. The proof wasn’t there.” Linford & Company, paraphrased from a public SOC 2 readiness webinar, 2025.

For a detailed breakdown of which controls auditors test first and exactly what evidence they request per area, see SOC 2 Controls Auditors Check First.

1. Access Control and Identity Management

Role-based access control, MFA enforcement, automated provisioning and termination workflows, and quarterly access reviews are the four controls auditors test first. An unexplained active account for a terminated employee is a qualifying finding in nearly every audit.

Full implementation guide: SOC 2 Access Control Policy Template

2. Data Encryption

AES-256 for data at rest and TLS 1.2 or higher for data in transit are the minimum standards. The most common gap is key management: keys co-located with the data they protect, or rotation schedules that exist in policy but run years behind in practice.

Use a managed KMS (AWS, GCP, or Azure), store keys separately from data, automate annual rotation, and document your encryption standard in a formal policy.

3. Information Security Policy Documentation

Every technical control requires a policy that governs it. Auditors verify policy existence, approval date, approval authority (C-suite or board, not an individual contributor), and distribution evidence (employee acknowledgment log). Without documented, version-controlled policies, there is no baseline against which operational effectiveness can be measured.

Build policies covering: acceptable use, data classification, encryption, access control, incident response, and vendor management. Store them centrally, version-control them, and collect annual acknowledgments from all employees.

4. System Access Logging and Monitoring

Implement a SIEM or centralized log platform aggregating logs from all in-scope systems. Configure automated alerts for critical events, retain logs for at least 12 months in immutable storage, and document weekly review cycles with a named reviewer.

Full implementation guide: SOC 2 Logging and Monitoring Controls

5. Change Management and Configuration Control

Every production change needs a documented approval trail: request, peer review, test result, and deployment record. Separation of duties is a tested control: the engineer who wrote the code cannot be the sole approver. Ad-hoc changes with no approval records are a qualifying finding.

Use a ticketing system with enforced workflow, integrate automated testing into CI/CD, and maintain a CMDB or infrastructure-as-code state for configuration tracking.

Full implementation guide: SOC 2 Change Management Controls

6. Incident Response

A plan that exists on paper but has never been tested fails. Auditors request tabletop exercise records with dated participants and findings. They also pull post-incident reviews for any incidents during the observation period.

Build a formal plan using NIST SP 800-61 as a template. Create playbooks for your three highest-probability scenarios. Run a documented tabletop exercise at least quarterly.

7. Vulnerability and Patch Management

Run authenticated scans on critical systems monthly. Track remediation from detection to resolution in a ticketing system. Document approved exceptions with risk acceptance sign-off.

8. Vendor and Third-Party Risk Management

Every vendor with access to in-scope data must be assessed before onboarding and reassessed at least annually, with SOC 2 Type 2 reports or ISO 27001 certificates collected as evidence. Contracts must include breach notification timelines and security requirements, or auditors flag the gap as a supply-chain control deficiency.

Classify vendors by data access and system criticality. Collect SOC 2 Type 2 or ISO 27001 certificates from critical vendors. Embed breach notification clauses and security requirements in all vendor contracts.

9. Employee Security Awareness Training

All employees must complete security awareness training at onboarding and annually thereafter, with completion records retained as audit evidence. Phishing simulation results add depth and are increasingly expected by auditors testing the Security criterion.

Maintain a training log with employee names, dates, course names, and completion status. Run simulated phishing quarterly and track click rates by department.

Full implementation guide: SOC 2 Security Controls

10. Business Continuity and Disaster Recovery

Each critical system needs a defined RTO and RPO, supported by automated backups stored in a separate geographic location, and an annually tested failover procedure. Auditors will not accept a BCDR plan that has never been executed. Documented test results with identified gaps and remediation steps are required evidence.

Full implementation guide: SOC 2 Business Continuity Controls

---

SOC 2 Control Areas: Build Time, Evidence, and Common Findings

Control area	Avg build time	Evidence produced (what auditors request)	Most common finding	Guide
Access Control	3–6 weeks	Quarterly access review records with manager sign-off; MFA enforcement screenshots; provisioning/termination workflow logs	Undocumented reviews or active accounts for terminated employees	Access Control Policy
Data Encryption	2–4 weeks	Encryption standard policy (approved, versioned); KMS configuration screenshots; key rotation audit log	Keys co-located with data they protect; rotation schedule in policy but years behind in practice
Security Policies	4–8 weeks	Policy documents with version history; executive approval evidence; employee acknowledgment log (name, date, course)	Policy exists but no executive approval or acknowledgment log
Logging and Monitoring	3–5 weeks	SIEM configuration screenshots; 12-month log retention evidence; weekly review sign-off records	Log retention gaps or no evidence of periodic review by a named reviewer	Logging and Monitoring
Change Management	2–4 weeks	Change tickets with request, peer review, test result, and deployment record; CI/CD pipeline configuration	Emergency changes approved after-the-fact; no separation of duties on approvals	Change Management
Incident Response	3–6 weeks	Tabletop exercise records (dated, named participants, findings); post-incident review documents for any in-period incidents	Plan exists on paper but no tabletop exercise record
Vulnerability Management	3–5 weeks	Authenticated scan reports (monthly cadence); remediation tracking tickets; risk-acceptance records for approved exceptions	Critical findings aged past the policy’s own SLA with no risk-acceptance sign-off
Vendor Risk	4–8 weeks	Vendor inventory with risk classification; SOC 2 Type 2 or ISO 27001 certificates from critical vendors; contracts with security and breach notification clauses	Vendors onboarded without assessment; no security clauses in contracts
Employee Training	2–3 weeks	Training completion log (name, date, course); phishing simulation results by department	Completion records not tracked; no phishing simulation evidence	Security Controls
Business Continuity	6–12 weeks	RTO/RPO documentation per critical system; backup configuration evidence; annual failover test results with identified gaps and remediation steps	DR plan never executed; no documented RTO/RPO validation from a real test	Business Continuity

---

Phase 3: Readiness Assessment and Evidence Collection

Step 4: Run a Gap Assessment Against Your Chosen TSCs

Artifact produced: Gap assessment spreadsheet mapping each TSC sub-criterion to its control, owner, and evidence status. Owner: Security lead or compliance manager.

Map each TSC sub-criterion to the control or controls that satisfy it and verify each has documented evidence for at least 30 days of operation. A gap is any criterion with no corresponding control, no named owner, or no evidence. Prioritize gaps by the auditor finding rate in the table above. For a structured approach, the SOC 2 readiness assessment generates a scored gap report automatically.

Step 5: Build Your Evidence Repository

Artifact produced: Organized evidence folder (by control area and TSC criterion) with pre-staged documentation for auditor requests. Owner: Audit coordinator.

Create a central folder structure organized by control area and TSC criterion. Pre-stage: access review records, MFA configuration screenshots, policy approval logs, SIEM alert configurations, change tickets with approval trails, vendor assessment files, and training completion reports. Auditors issue a Prepared By Client (PBC) list during fieldwork and request evidence by population and sample. Pre-staged evidence cuts response time from days to hours and reduces the chance of last-minute scrambles that extend fieldwork.

Step 6: Assign Control Ownership and Run a Mock Audit

Artifact produced: Control ownership register; internal mock audit report with gap findings and remediation status. Owner: Security lead.

Name an owner for every control — the person responsible for generating evidence on the required cadence. Controls without named owners fail silently. Document the ownership map in your evidence repository.

Run an internal mock audit before engaging your external auditor: pick a sample of 10 to 15 controls, request evidence exactly as an auditor would, and identify any gaps in completeness, format, or timeliness. Remediate every gap before the observation window is finalized. Any gap you find here, the auditor will find later.

---

Phase 4: Auditor Selection, Fieldwork, and Post-Audit

Step 7: Select and Engage Your Auditor

Artifact produced: Signed engagement letter with observation period start date and fieldwork schedule. Owner: Executive sponsor or legal.

Engage 4 to 6 weeks before you want fieldwork to start. Evaluate: industry specialization (SaaS, FinTech, and healthcare have different audit norms), methodology (GRC platform integration vs. email evidence requests), report quality (ask for a sanitized sample), and references (talk to clients whose audit ran during a similar period of rapid growth, not just a steady-state year).

For a comparison of 180+ SOC 2 audit firms by price, timeline, industry focus, and client ratings, see the SOC2Auditors directory.

Step 8: Prepare for Fieldwork

Artifact produced: Completed PBC tracker with evidence staged per auditor request. Owner: Audit coordinator.

Your auditor issues a Prepared By Client (PBC) list — the full evidence request for the audit. Use the SOC 2 Audit Checklist to map each control area to exactly what auditors request, what triggers an exception, and how to stage evidence to minimize back-and-forth.

Assign a single audit coordinator to manage the PBC tracker and own all auditor communications. When multiple people respond to the same RFI with different versions of the same evidence, it creates audit exceptions that didn’t need to exist.

Step 9: Support Fieldwork

Artifact produced: Closed RFI log; any management comments on preliminary exception notes. Owner: Audit coordinator.

Fieldwork for a Type 2 runs 3 to 6 weeks. The auditor samples from the populations you staged, follows up on exceptions, and tests controls directly. Respond to every RFI within 24 to 48 hours. Delays extend fieldwork and compress your post-draft review window — the window where you can still correct factual inaccuracies before the report is issued.

Step 10: Review Draft Report and Issue Bridge Letters if Needed

Artifact produced: Signed management response letter; finalized SOC 2 report. Owner: Executive sponsor (signatory) and audit coordinator (content review).

The auditor issues a draft for management response before finalizing. Read every exception description carefully. If your team disagrees with how a finding is characterized, respond formally during the management response window — it is your only opportunity to correct factual inaccuracies. Silence is taken as agreement.

If the report covers a period that ended 6 or more months ago, customers may request a bridge letter: a signed statement confirming no material control environment changes since report issuance. Build this into your planning — drafting one under customer pressure is harder than having a template ready.

Step 11: Set Up Annual Renewal

SOC 2 Type 2 reports are typically issued annually. The next observation period starts the day the current one ends.

For the renewal cycle: update policies annually, run a new vendor risk reassessment, re-test BCDR, and schedule tabletop exercises for the new observation window before the period is 60 days old. Auditors sample evidence from the full period; gaps in the first 60 days are as auditable as gaps in month 11.

Budget 15 to 20% less time for the second-year audit. Scoping and evidence organization are already done. The main variable is whether control changes — new infrastructure, new vendors, team turnover — require additional documentation.

---

Frequently Asked Questions

What are the SOC 2 compliance standards?

SOC 2 is governed by the AICPA and tested against the Trust Services Criteria, last updated with revised points of focus in 2022 (TSP Section 100). The five TSC categories are Security (required for every report), Availability, Processing Integrity, Confidentiality, and Privacy. The Security category covers 33 common criteria points across nine categories (CC1 through CC9). Most first-time audits scope to Security only.

Is there a free SOC 2 compliance checklist template?

Yes. This page is free and covers all 10 control areas mapped to TSC evidence requirements. Print it to PDF using File > Print > Save as PDF. For a scored, interactive version, use the free SOC 2 readiness assessment tool.

What is the difference between a SOC 2 Type 1 and Type 2 checklist?

A Type 1 checklist focuses on control design at a point in time. Evidence needs are policies, configurations, and design documentation. A Type 2 checklist adds operating effectiveness evidence across the full observation window (6 to 12 months): dated access reviews, change tickets, incident logs, and training records spanning the entire review period.

How long does a SOC 2 audit take?

A Type 1 audit runs 8 to 14 weeks from engagement to report. A Type 2 runs 9 to 18 months total: 3 to 6 months of preparation, a 6 to 12 month observation period, and 6 to 12 weeks of fieldwork and reporting. GRC platforms (Vanta, Drata, Secureframe) cut prep time by 60 to 80% but cannot shorten the observation window.

What evidence do SOC 2 auditors actually request?

Auditors issue a Prepared By Client (PBC) list that typically includes access review records with manager sign-off, MFA configuration screenshots, policy approval logs, SIEM alert configurations, change tickets with approval trails, vulnerability scan reports with remediation tracking, vendor SOC 2 or ISO 27001 certificates, employee training completion logs, and tabletop exercise records with dated participants.

Can I do SOC 2 without a GRC platform like Vanta or Drata?

Yes. Many organizations complete SOC 2 using spreadsheet-based evidence trackers, GitHub for policy version control, and their existing ticketing system for change management. GRC platforms reduce manual effort but add $12,000 to $30,000 per year in licensing. The right choice depends on team size and how complex your control environment is.

---

Related Resources

• SOC 2 Compliance Overview
• SOC 2 Audit Checklist: Fieldwork Evidence Guide
• SOC 2 Trust Services Criteria
• SOC 2 Compliance for Startups
• What Auditors Check First

---

Compare 180+ SOC 2 audit firms by price, timeline, and specialization in the SOC2Auditors directory. If you want quotes instead, use Find My SOC 2 Auditor.