SOC 2 for Engineers
What SOC 2 Actually Is
SOC 2 is not a certification. It is an attestation. An independent auditor looks at your controls against the AICPA Trust Service Criteria and writes a report on whether those controls are designed properly (Type I) or operating effectively over time (Type II). Enterprise buyers care about SOC 2 because it has become the standard proof that a SaaS vendor takes security seriously.
What Auditors Actually Look At
Auditors do not read your code. They examine evidence that your controls work. That means access review screenshots, change management tickets, deployment logs, monitoring alert configurations, and incident response records. The five Trust Service Criteria map to concrete engineering concerns:
- Security - Are production systems protected from unauthorized access? Think IAM policies, MFA enforcement, network segmentation, vulnerability scanning.
- Availability - Do you have SLAs, uptime monitoring, capacity planning, and disaster recovery procedures that you actually test?
- Processing Integrity - Does data get processed completely and accurately? This covers input validation, data pipeline monitoring, and reconciliation.
- Confidentiality - Is sensitive data encrypted at rest and in transit? Are access controls scoped to least privilege?
- Privacy - How do you handle PII? Consent mechanisms, retention policies, and deletion procedures.
Making Evidence Collection Automatic
The teams that struggle with SOC 2 are the ones scrambling to collect evidence manually before an audit window. The teams that breeze through it have continuous compliance baked into their infrastructure.
- Infrastructure as Code - Every Terraform plan is a versioned, reviewable change record. Auditors love this.
- Automated access reviews - Pull IAM roles from AWS/GCP monthly, pipe them into a review workflow, and store approvals.
- Deployment audit trails - CI/CD pipelines with required approvals, signed commits, and immutable build artifacts create evidence automatically.
- Monitoring as evidence - Datadog, PagerDuty, or Grafana dashboards and alert configurations prove you monitor availability.
- Compliance automation platforms - Vanta, Drata, or Secureframe connect to your cloud providers, identity providers, and ticketing systems to continuously collect evidence and flag gaps.
What Passes vs. What Fails
You do not need perfect security to pass SOC 2. You need to do what your policies say you do. If your access review policy says quarterly reviews, you must have evidence of quarterly reviews, not annual ones. If your incident response plan says a 1-hour acknowledgment SLA, your PagerDuty data must show that. The most common audit failures come from policies that were written aspirationally and never actually followed. Write policies that match your real practices, then improve both over time.
Key Points
- •SOC 2 has five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy
- •Type I audits assess design at a point in time; Type II audits assess operating effectiveness over 6-12 months
- •Most startups only need Security and Availability criteria to start
- •Evidence collection is the hard part, so automate it from day one with tools like Vanta or Drata
- •SOC 2 is about proving you do what you say you do, not about being perfect
Common Mistakes
- ✗Treating SOC 2 as a one-time project instead of an ongoing compliance program
- ✗Waiting until the audit to gather evidence instead of automating collection continuously
- ✗Writing policies that describe aspirational practices rather than actual practices
- ✗Ignoring the shared responsibility model for cloud services