SOC 2 Compliance Checklist: The Developer's Practical Guide
SOC 2 is the compliance framework that enterprise customers ask about first. But for developers, the standard is written in auditor language that is hard to map to actual technical controls. This guide translates SOC 2 Trust Service Criteria into a practical checklist of things you need to implement, monitor, and document.
What Is SOC 2?
SOC 2 (Service Organization Control 2) is a compliance framework developed by the AICPA that evaluates how organizations protect customer data. It is not a certification — it is an audit report that attests to the design and operating effectiveness of your security controls over a period of time.
SOC 2 Type I
Evaluates the design of controls at a single point in time. Answers: “Are the right controls in place?”
- Faster to achieve (4–8 weeks)
- Good starting point
- Snapshot assessment
SOC 2 Type II
Evaluates the operating effectiveness of controls over 3–12 months. Answers: “Do the controls actually work?”
- Required by most enterprises
- Continuous evidence needed
- Stronger trust signal
The Five Trust Service Criteria
Security (CC)
Protection against unauthorized access. This is the only required TSC — all SOC 2 reports must include it. Covers access control, encryption, monitoring, and incident response.
Availability (A)
System uptime and disaster recovery. Covers SLAs, backup procedures, capacity planning, and business continuity.
Processing Integrity (PI)
Data processing is complete, valid, accurate, and authorized. Covers input validation, error handling, and output reconciliation.
Confidentiality (C)
Protection of confidential information. Covers data classification, encryption, access restrictions, and secure disposal.
Privacy (P)
Handling of personal information per privacy notices. Covers collection, use, retention, disclosure, and disposal of PII.
The Developer's SOC 2 Checklist
Security Controls
Availability Controls
Confidentiality & Privacy Controls
Automating SOC 2 Evidence Collection
The hardest part of SOC 2 is not implementing controls — it is proving they work continuously. Type II audits require evidence that controls operated effectively over the entire observation period. Manual evidence collection (screenshots, spreadsheets) does not scale. Modern teams automate evidence collection using:
CSPM for Cloud Controls
Continuous cloud scanning produces audit-ready evidence of encryption settings, IAM policies, network rules, and logging configuration across AWS, GCP, and Azure.
eBPF for Runtime Evidence
Runtime monitoring provides continuous evidence of binary execution control, file integrity, network monitoring, privilege management, and secrets protection.
CI/CD Pipeline Logs
SAST, SCA, and container scan results from every build provide evidence of vulnerability management and secure development practices.
Identity Provider Logs
SSO and MFA enforcement logs from your identity provider (Okta, Azure AD) provide evidence of access control and authentication policies.
Inside the Security TSC: The Common Criteria (CC1–CC9)
The required Security criterion is organized into nine Common Criteria series, and auditors structure their testing around them. Knowing which series a control belongs to makes audit preparation dramatically easier, because you can map every piece of evidence to the criterion it satisfies before the auditor asks.
CC1 – Control Environment
Governance fundamentals: an information security policy, defined security roles, background checks, and security awareness training. Auditors want to see the policy is approved by leadership and reviewed at least annually.
CC2 – Communication and Information
How security obligations are communicated internally and externally — employee handbooks, customer-facing security pages, and internal channels for reporting concerns.
CC3 & CC4 – Risk Assessment and Monitoring
A documented annual risk assessment, tracking of identified risks to remediation, and ongoing monitoring of whether controls remain effective. Penetration test reports and vulnerability scan trends live here.
CC5 – Control Activities
The policies and procedures that put risk decisions into practice, including how controls are designed, implemented, and assigned to owners.
CC6 – Logical and Physical Access
The largest series for engineering teams: MFA, RBAC, least privilege, credential management, onboarding and offboarding workflows, encryption at rest and in transit, and physical datacenter controls (usually inherited from your cloud provider).
CC7 – System Operations
Vulnerability management, intrusion detection, security event monitoring, and incident response. Runtime monitoring, SIEM alerts, and post-incident reviews are the core evidence. This is where eBPF-based detection maps most directly.
CC8 – Change Management
Every production change must be authorized, tested, and reviewed. Pull request approvals, CI pipeline results, and deployment logs are your evidence — auditors will sample specific changes and trace them end to end.
CC9 – Risk Mitigation
Vendor and business-partner risk management: maintaining a vendor inventory, reviewing subprocessor SOC 2 reports, and carrying appropriate contractual and insurance protections.
A Realistic SOC 2 Timeline for a Startup
Compliance vendors advertise “SOC 2 in two weeks,” but that only describes tooling setup. A defensible path from zero to a Type II report typically takes six to twelve months. Here is how the phases break down for a typical 20–100 person engineering organization.
Weeks 1–4: Scoping and Gap Assessment
Decide which Trust Service Criteria to include (most startups start with Security plus Availability), define the system boundary, and run a gap assessment against the Common Criteria. Output: a prioritized remediation backlog.
Weeks 5–16: Remediation
Close the gaps — roll out MFA and SSO everywhere, formalize access reviews, write the policy set, wire vulnerability scanning into CI/CD, and stand up centralized logging and alerting. This phase is where automation platforms save the most time.
Weeks 12–20: Type I Audit (Optional)
Many companies get a Type I report to satisfy early enterprise deals while the Type II observation window runs. The auditor tests control design at a point in time.
Months 4–10: Type II Observation Window
Controls must operate continuously for the chosen period (three months minimum; six to twelve is typical). Every missed access review or unlogged change during this window becomes a potential exception in the report.
Months 10–12: Fieldwork and Report
The auditor samples evidence across the window, interviews control owners, and issues the report. Expect four to eight weeks from fieldwork start to a signed report.
Common SOC 2 Mistakes to Avoid
Most first-time audits fail in predictable ways. None of these mistakes are about missing exotic controls — they are about operational discipline slipping during the observation window.
The unifying theme is continuity. A Type II report attests to months of consistent operation, so the winning strategy is to make each control the path of least resistance: automated deprovisioning tied to your HR system, access reviews generated from identity provider exports, and scanner-driven evidence that accumulates without anyone remembering to collect it.
What SOC 2 Costs and How to Choose an Auditor
Budget for three cost categories. First, the audit itself: Type I engagements typically run $10,000–$20,000 and Type II $20,000–$60,000 depending on scope, criteria count, and firm size. Second, tooling: compliance automation platforms, security scanners, and monitoring infrastructure. Third — and usually largest — internal engineering time spent on remediation and evidence workflows, which automation exists to compress.
When selecting an audit firm, verify the CPA firm is registered and peer-reviewed, and ask how they consume evidence. Auditors who integrate with your compliance platform (Vanta, Drata, Secureframe, or a security platform like TigerGate that feeds evidence into them) shorten fieldwork significantly. Ask for a sample report, confirm who will actually perform testing, and clarify how exceptions are handled — a good auditor discusses potential exceptions during fieldwork rather than surprising you in the draft report. Finally, remember that the report reader is your customer's security team: a clean report from a reputable mid-size firm carries more weight than a rubber-stamp report from an unknown one.
Frequently Asked Questions
Do we need SOC 2 if we already have ISO 27001?
Often yes, if you sell into North America. The frameworks overlap heavily — both cover access control, change management, and incident response — but US enterprise procurement teams usually ask for a SOC 2 report specifically. The good news: controls and evidence built for one map largely onto the other, so pursuing both is far cheaper than the first one alone.
How long must the Type II observation window be?
Three months is the practical minimum auditors will accept, and it is common for a first report. Subsequent reports typically cover twelve months so customers have continuous coverage year over year. Gaps between report periods raise questions during security reviews.
What happens if the auditor finds an exception?
An exception does not fail the audit — SOC 2 reports are not pass/fail. The exception is documented alongside management's response, and customers judge its severity. A missed access review with a documented remediation is survivable; systemic failures in access control are not. The goal is to catch issues yourself before fieldwork.
Can a small startup pass SOC 2?
Yes. SOC 2 scales with organization size, and auditors evaluate whether controls are appropriate for your environment, not whether you run an enterprise security program. A five-person team with SSO, branch protection, automated scanning, and a lightweight policy set can achieve a clean report — automation matters far more than headcount.
Automate SOC 2 Compliance with TigerGate
TigerGate maps your security controls to SOC 2 Trust Service Criteria automatically. eBPF runtime monitoring and CSPM provide continuous compliance evidence — no more screenshots.