The Checklist You Wish You Had Six Months Ago
Every major outage in the history of technology has the same root cause: someone changed something. Usually on a Friday. Usually without telling anyone. SOC 2 exists, in large part, to make sure that when someone changes something, there's a documented trail explaining why it seemed like a good idea at the time.
If you're staring down a SOC 2 compliance checklist for the first time, you've probably noticed something: the AICPA doesn't actually hand you a checklist. They hand you a framework of Trust Services Criteria and wish you the best. What you do with it is between you and your auditor.
This guide fixes that. Below is a practical, organized SOC 2 compliance checklist broken down by each Trust Services Category, with timelines, cost expectations, and the specific mistakes that turn a manageable project into a twelve-month ordeal.
Type I vs Type II — Know What You're Signing Up For
Before you start checking boxes, decide which report you're pursuing. This decision shapes everything that follows.
| SOC 2 Type I | SOC 2 Type II | |
|---|---|---|
| Scope | Controls designed appropriately at a point in time | Controls operating effectively over 3-12 months |
| Observation period | None — it's a snapshot | 3-12 months (6 months is standard) |
| Audit cost | $20,000-$50,000 | $30,000-$100,000 |
| Time to complete | 4-8 weeks after controls are ready | 6-12 months total |
| Enterprise credibility | Acceptable as a first step | The actual standard |
| Renewal | One-time, no renewal | Annual re-audit required |
The pragmatic path: Get Type I to unblock sales conversations now. Start your Type II observation window the day after your Type I report is issued. Within 12-18 months, you'll have both. For a deeper look at the startup-specific calculus, see our SOC 2 for startups guide.
The Five Trust Services Criteria
SOC 2 is built on five categories defined by the AICPA's Trust Services Criteria. Security is mandatory. The rest are optional — include them when customer contracts or your risk profile demand it.
| Criteria | Also Known As | Required? | Include If... |
|---|---|---|---|
| Security | Common Criteria (CC1-CC9) | Yes, always | You exist |
| Availability | A1 | Optional | You have SLA commitments |
| Processing Integrity | PI1 | Optional | You process transactions or calculations |
| Confidentiality | C1 | Optional | You handle sensitive business data |
| Privacy | P1-P8 | Optional | You process personal information |
Most first-time audits cover Security plus one or two additional categories. Adding all five because it "looks better" is a strategy roughly equivalent to ordering the entire menu at a restaurant — expensive, wasteful, and you'll regret it by the third course.
The Complete SOC 2 Compliance Checklist
What follows is organized by Trust Services Category. Each item represents a control area your auditor will evaluate. Not every item applies to every organization — scoping is half the battle.
Security (Common Criteria) — Required
This is the foundation. If your SOC 2 were a building, Security would be the structural concrete. Everything else is interior design.
| # | Control Area | What to Document & Implement |
|---|---|---|
| 1 | Control environment | Board/management oversight of security, defined org structure, code of conduct |
| 2 | Risk assessment | Formal risk assessment process, annual review cycle, risk register |
| 3 | Information & communication | Security policies communicated to all employees, incident reporting channels |
| 4 | Monitoring activities | Regular review of controls, internal audit function, deficiency tracking |
| 5 | Logical access controls | RBAC implementation, least privilege, MFA on all remote access |
| 6 | Access provisioning | Documented approval workflows for new access, role-based templates |
| 7 | Access revocation | Revocation within 24 hours of termination, quarterly access reviews |
| 8 | Change management | Documented change process, peer review, approval gates, rollback procedures |
| 9 | System monitoring | Centralized logging, alerting, SIEM or equivalent, log retention policy |
| 10 | Incident response | Documented IR plan, defined roles, communication templates, post-incident review |
| 11 | Vulnerability management | Regular scanning, patching SLAs, penetration testing (annual minimum) |
| 12 | Encryption | Data encrypted in transit (TLS 1.2+) and at rest, key management procedures |
| 13 | Network security | Firewall rules, network segmentation, intrusion detection |
| 14 | Vendor management | Third-party risk assessments, security reviews, contractual requirements |
| 15 | Business continuity | BCP/DR plan, tested annually, defined RTO/RPO |
Each of these control areas can be expressed as one or more governance statements — discrete, testable requirements with assigned owners. That mapping is not incidental; it's the difference between controls that exist on paper and controls that actually function. More on this approach in our guide to SOC 2 governance statements.
Availability (A1)
| # | Control Area | What to Document & Implement |
|---|---|---|
| 1 | Uptime commitments | Defined SLAs, measurement methodology, public status page |
| 2 | Capacity planning | Resource monitoring, scaling procedures, threshold alerting |
| 3 | Disaster recovery | DR plan, geographic redundancy, tested failover procedures |
| 4 | Backup & restoration | Automated backups, tested restores (quarterly minimum), offsite storage |
| 5 | Incident communication | Customer notification process for outages, post-mortem publication |
Processing Integrity (PI1)
| # | Control Area | What to Document & Implement |
|---|---|---|
| 1 | Input validation | Data validation rules at point of entry, error handling procedures |
| 2 | Processing accuracy | Reconciliation controls, automated checks, exception reporting |
| 3 | Output completeness | Delivery confirmation, checksums, audit trails for processed data |
| 4 | Error correction | Documented procedures for identifying, reporting, and correcting errors |
Confidentiality (C1)
| # | Control Area | What to Document & Implement |
|---|---|---|
| 1 | Data classification | Classification scheme (public/internal/confidential/restricted), labeling |
| 2 | Access restrictions | Need-to-know enforcement, privileged access management |
| 3 | Secure disposal | Data destruction procedures, certificate of destruction, retention schedules |
| 4 | NDA & agreements | Confidentiality agreements with employees, contractors, vendors |
Privacy (P1-P8)
| # | Control Area | What to Document & Implement |
|---|---|---|
| 1 | Notice | Privacy policy, data collection disclosures, cookie consent |
| 2 | Choice & consent | Opt-in/opt-out mechanisms, consent records, preference management |
| 3 | Collection | Data minimization, purpose limitation, lawful basis documentation |
| 4 | Use & retention | Defined retention periods, automated purging, purpose-of-use records |
| 5 | Access & correction | Data subject request procedures, identity verification, response SLAs |
| 6 | Disclosure | Third-party data sharing agreements, transfer impact assessments |
| 7 | Security for privacy | Encryption of PII, access logging, breach notification procedures |
| 8 | Quality | Data accuracy controls, update mechanisms, completeness checks |
The SOC 2 Timeline — What Actually Happens
Everyone quotes "6-12 months." Here's what the months actually contain.
| Phase | Duration | Activities | Common Pitfall |
|---|---|---|---|
| Scoping | 2-3 weeks | Define TSC categories, system boundaries, select auditor | Scope creep — including systems that aren't in scope |
| Gap assessment | 2-4 weeks | Inventory current controls, identify gaps against criteria | Discovering you have no documented policies at all |
| Remediation | 6-12 weeks | Write policies, implement controls, deploy tooling | Underestimating engineering time by 3x |
| Evidence collection | Ongoing | Gather screenshots, exports, logs for every control | Manual evidence collection that takes 40+ hours |
| Type I audit | 4-6 weeks | Auditor reviews control design | Policies that exist but aren't followed |
| Observation period | 3-12 months | Controls operating, evidence accumulating | The controls you implemented in a rush breaking in month 4 |
| Type II audit | 4-8 weeks | Auditor tests operating effectiveness | Evidence gaps during the observation window |
Total timeline: 9-18 months from "we should do SOC 2" to a Type II report in hand. The biggest variable is the remediation phase. Organizations that start from a governance library with pre-built, auditor-ready statements can compress remediation from months to weeks.
Six Mistakes That Will Cost You Months
1. Writing policies nobody follows. A 40-page Information Security Policy that no one has read since it was copied from a template is worse than useless — it's evidence of a control failure. Write governance statements that are specific enough to be testable and short enough to be read.
2. Starting evidence collection too late. Your observation period starts when you begin collecting evidence, not when you decide to. If your logging wasn't turned on in January, those months don't count. Evidence collection infrastructure should be the first thing you build.
3. Treating SOC 2 as a one-time project. SOC 2 Type II requires annual re-audits. The controls you implement need to be sustainable — not just presentable for eight weeks. Think of it as building a compliance program, not passing an exam.
4. Ignoring the human controls. Technical controls get all the attention. Background checks, security training, acceptable use policies, and employee acknowledgments get forgotten until the auditor asks for evidence — and finds none. These "boring" controls are the ones that generate audit findings.
5. Choosing the wrong auditor. Not all CPA firms are created equal. Some specialize in SOC 2 for SaaS companies and will work with you. Others specialize in making the process as opaque and billable as possible. Ask for references from companies your size.
6. Gold-plating scope. Including all five Trust Services Categories in your first audit because a blog told you to (not this one, obviously). Start with Security. Add categories when specific customer requirements demand them.
What SOC 2 Compliance Actually Costs
Let's dispense with the fiction that SOC 2 is "just the audit fee."
| Category | Year 1 Range | Ongoing Annual |
|---|---|---|
| Audit fees | $20K-$100K | $20K-$80K |
| Compliance tooling | $8K-$50K | $8K-$50K |
| Engineering time | $15K-$60K | $5K-$20K |
| Policy development | $5K-$20K | $2K-$5K |
| Readiness assessment | $5K-$15K | — |
| Training & awareness | $2K-$5K | $2K-$5K |
| Total | $55K-$250K | $37K-$160K |
The wide range reflects company size (20-person startup vs 500-person scale-up), scope (Security only vs all five categories), and how much existing infrastructure you can leverage. The single biggest cost lever is engineering time, and the single biggest way to reduce it is starting with documented controls rather than building them from scratch.
How Statement-Based Governance Maps to SOC 2
Traditional compliance approaches produce monolithic policy documents. SOC 2 auditors then have to dig through them to find the specific requirements that map to each Trust Services Criterion. This is tedious for the auditor and error-prone for you.
A statement-first approach inverts this:
- One statement per control requirement — "All access to production systems must use multi-factor authentication" is a single, testable governance statement
- Direct TSC mapping — each statement maps to one or more Trust Services Criteria
- Assigned ownership — every statement has an owner responsible for compliance
- Evidence linking — evidence is attached to specific statements, not buried in shared folders
- Version control — when requirements change, the statement is updated with a full audit trail
This isn't theoretical. The Dictiva governance library contains pre-built statements mapped to SOC 2 Trust Services Criteria. Instead of writing policies from a blank page, you adopt the statements that match your scope, assign owners, and begin collecting evidence. The result is a compliance audit checklist that practically runs itself.
For organizations considering compliance automation tools, the statement-based model also integrates more cleanly with automated evidence collection — each statement becomes an API-addressable control point rather than a paragraph in a PDF.
Your SOC 2 Pre-Audit Readiness Checklist
Before your auditor arrives, confirm the following:
- Trust Services Criteria scope documented and agreed with auditor
- System description written (your system, boundaries, and infrastructure)
- All in-scope policies documented, approved, and communicated
- Control owners assigned for every in-scope requirement
- Evidence collection running for the full observation period
- Access reviews completed for the most recent quarter
- Vulnerability scans and penetration test results available
- Incident response plan tested within the last 12 months
- Employee security training completed with attendance records
- Vendor risk assessments current for critical third parties
- Change management logs complete with approvals
- Backup restoration test completed and documented
If more than two items on that list made you uncomfortable, you have work to do. The good news: it's all doable, and it gets dramatically easier the second year.
Start With What You Can Control
SOC 2 compliance is not a mystery — it's a project. A well-scoped project with clear deliverables, defined timelines, and measurable outcomes. The organizations that struggle are the ones that treat it as an ambiguous mandate rather than an engineering problem.
The most effective first step is also the simplest: document what you're already doing. Most growing companies have more controls in place than they realize — they just haven't written them down. Converting existing practices into governance statements is faster than building from scratch, and it gives your auditor something concrete to evaluate.
If you're starting from zero, the Dictiva governance library provides SOC 2-mapped statements you can adopt today — no blank-page anxiety required. And if you'd like to see how statement-based governance fits into a broader compliance strategy, take a look at our pricing plans to find the right starting point for your organization.
The audit is coming regardless. You might as well be ready.