SOC 2 Compliance Checklist

Getting SOC 2 compliant can feel overwhelming when you look at the full scope of work. Breaking the process into phases makes it manageable. This checklist walks through every major step from initial scoping through audit completion, organized so you can track progress and assign ownership.

Use this as a reference alongside the detailed SOC 2 requirements and audit process guide.

Phase 1: Scoping and planning

The foundation of a successful SOC 2 program is clear scoping. Mistakes here ripple through every subsequent phase.

Define the audit objective — decide whether to pursue Type I or Type II and set a target completion date.
Identify in-scope systems — list every application, database, cloud service, and third-party tool that stores, processes, or transmits customer data.
Select Trust Services Criteria — security is mandatory. Evaluate whether availability, processing integrity, confidentiality, or privacy apply based on your service commitments. See the Trust Services Criteria guide for details.
Identify subservice organizations — document any third-party providers (AWS, Stripe, Datadog) that are part of your service delivery and how they are handled in the audit (inclusive vs. carve-out method).
Assign a project owner — designate a compliance lead who owns the timeline, coordinates across teams, and serves as the auditor's primary point of contact.
Set a budget — use the SOC 2 cost guide to estimate auditor fees, tooling, and internal labor.
Establish a timeline — work backward from your target date and build in buffer for remediation.

Phase 2: Gap analysis and remediation

This phase determines how much work stands between your current state and audit readiness.

Policies and documentation

Information security policy — a foundational document covering the organization's approach to security, roles, and responsibilities.
Acceptable use policy — define what employees can and cannot do with company systems and data.
Access control policy — document how access is granted, reviewed, and revoked.
Change management policy — describe how changes to production systems are proposed, reviewed, approved, and deployed.
Incident response plan — define how security incidents are detected, reported, contained, and resolved.
Business continuity and disaster recovery plan — document recovery objectives, procedures, and testing schedules.
Vendor management policy — describe how third-party risks are assessed and monitored.
Data classification policy — define sensitivity levels and handling requirements for different data types.
Risk assessment procedure — document how risks are identified, evaluated, and treated on a regular cadence.
Privacy policy (if privacy criterion is in scope) — ensure your public privacy notice matches your actual data practices.

Technical controls

Multi-factor authentication — enforce MFA on all production systems, cloud consoles, and critical SaaS applications.
Single sign-on — implement SSO where possible to centralize authentication and simplify access reviews.
Endpoint management — deploy MDM to enforce disk encryption, screen locks, firewall settings, and OS patching.
Centralized logging — aggregate logs from applications, infrastructure, and security tools into a central platform.
Monitoring and alerting — configure alerts for anomalous activity, unauthorized access attempts, and system health metrics.
Encryption — verify encryption at rest and in transit for all customer data stores and communication channels.
Network security — configure firewalls, security groups, and network segmentation to restrict access to production environments.
Vulnerability management — implement automated vulnerability scanning and a process for triaging and remediating findings.
Backup and recovery — configure automated backups, verify restoration procedures, and document retention schedules.

People and processes

Background checks — perform background checks on new hires, especially those with access to customer data or production systems.
Security awareness training — deliver annual training covering phishing, social engineering, data handling, and incident reporting. Track completion.
Onboarding procedures — document how new employees receive access, equipment, and policy acknowledgments.
Offboarding procedures — document how access is revoked, equipment is recovered, and accounts are deactivated when employees leave.
Quarterly access reviews — establish a recurring process for reviewing who has access to what and removing stale accounts.
Risk assessment — conduct a formal risk assessment at least annually and document the results and treatment decisions.

Phase 3: Evidence collection

Evidence is the proof that your controls are not just designed but actually operating. Start collecting early — do not wait for the auditor to ask.

Create an evidence inventory — for each control, document what evidence demonstrates it is working (screenshots, exports, logs, tickets).
Assign evidence owners — each piece of evidence should have a named person responsible for collecting and refreshing it.
Set collection cadences — some evidence is collected once (policies), while other evidence recurs (quarterly access reviews, monthly vulnerability scans).
Establish naming conventions — consistent file naming makes it easy for auditors to find what they need.
Store evidence securely — use a structured evidence locker with access controls, not a shared Google Drive folder.
Test evidence completeness — before the audit, review your evidence inventory against the SOC 2 requirements to identify gaps.

For a Type II engagement, evidence must span the entire observation period. A control that was implemented halfway through the period will result in an exception for the uncovered months.

Phase 4: Auditor selection and engagement

Research CPA firms — identify two to four firms with SOC 2 experience relevant to your company size and industry.
Request proposals — compare scope, pricing, timeline, and communication approach.
Check references — talk to other companies that have worked with each firm.
Negotiate and sign the engagement letter — confirm scope, criteria, observation period (for Type II), fees, and timeline.
Schedule kickoff — align your team's availability with the auditor's timeline.

See the audit process guide for what to expect during each stage of the engagement.

Phase 5: Audit execution

Attend the kickoff meeting — review scope, criteria, and the auditor's request list with your team.
Fulfill evidence requests — respond to auditor requests promptly. Delayed responses are the number one cause of audit timeline slippage.
Prepare control owners for interviews — auditors will conduct walkthroughs with the people who operate each control. Ensure they can explain what they do and why.
Track open items — maintain a running list of auditor questions, outstanding requests, and items pending resolution.
Review draft findings — if the auditor identifies exceptions or gaps, understand the impact and discuss remediation options.
Review the draft report — check the system description for accuracy and ensure the report reflects your environment correctly.

Phase 6: Post-audit and continuous monitoring

The audit is complete, but SOC 2 is an ongoing commitment.

Distribute the report — share under NDA with customers and prospects through a trust center or compliance portal.
Remediate exceptions — address any findings from the audit and document corrective actions.
Plan the next period — schedule the next observation period to begin immediately after the current one ends to avoid coverage gaps.
Maintain continuous monitoring — keep collecting evidence, reviewing controls, and updating policies on the cadences you established.
Conduct an internal retrospective — document what went well, what caused delays, and what to improve for the next cycle.
Update risk assessments — incorporate lessons learned from the audit and any changes to the business or threat landscape.

Tips for staying on track

Start early — give yourself at least three months of preparation time before the audit. Six months is better for a first-time engagement.
Assign clear ownership — every control, policy, and evidence item should have a named owner, not a team.
Automate what you can — manual evidence collection is the biggest time sink. Automation reduces errors and frees your team.
Communicate broadly — SOC 2 is not just a security team project. Engineering, HR, IT, and legal all have roles to play.
Use a single source of truth — scattered spreadsheets and documents lead to confusion. Centralize everything in one platform.

How episki helps

episki turns this checklist into a live workspace. Every item above is pre-loaded as an actionable task with ownership, due dates, and linked evidence requirements. The platform maps your controls to Trust Services Criteria automatically, tracks evidence freshness, and surfaces gaps before your auditor finds them. Instead of managing SOC 2 in spreadsheets, you get a structured system that keeps your entire team aligned. Start a free trial and see the full SOC 2 checklist in action, or compare episki to Sprinto to see how the approaches differ.

SOC 2 Compliance Checklist