The first thing most engineering teams discover during a SOC 2 audit is how much of their daily workflow suddenly counts as evidence. Every pull request, every IAM change, every production deploy is now something an auditor can ask you to produce proof of — and "we did it, I promise" is not proof.
This catches teams off guard not because SOC 2 is technically hard, but because almost nobody explains what auditors are actually checking before the first evidence request lands in an inbox. Most of it is less mysterious, and more achievable, than the compliance-industrial-complex makes it sound.
Type I vs. Type II — The Distinction That Actually Matters
A Type I report evaluates whether your controls are designed correctly at a single point in time — essentially, "do you have a lock on the door?" A Type II report evaluates whether those controls actually operated effectively over an observation window, typically 3 to 12 months — "did you actually keep the door locked the whole time?"
Most enterprise customers and procurement teams want Type II, because Type I only proves intent. If you're selling into mid-market or enterprise accounts, budget for Type II from the start rather than treating Type I as a stepping stone — it saves you from explaining the distinction to a prospect's security team six months from now.
The Five Trust Services Criteria
SOC 2 is built around five categories, though only the first is mandatory — the rest are selected based on what your business actually does:
| Criterion | Mandatory? | Covers |
|---|---|---|
| Security | Yes, always | Access control, change management, vulnerability management |
| Availability | If uptime is a customer commitment | Monitoring, incident response, disaster recovery |
| Confidentiality | If you handle sensitive business data | Data classification, encryption, access restriction |
| Processing Integrity | If you process transactions | Data accuracy, completeness, authorization |
| Privacy | If you handle personal data at scale | Collection, use, retention, disposal of PII |
Most SaaS startups scope to Security plus Availability. Adding criteria you don't need adds audit time and evidence burden without adding sales value — scope deliberately, not defensively.
The Controls Auditors Actually Test
Strip away the compliance language and auditors are testing a short list of genuinely practical things:
Access provisioning and deprovisioning. Can you prove that when someone joined, they got access to exactly what their role needed — and when someone left, their access was revoked within a defined window (usually 24 hours)? This is the single most commonly failed control, almost always because offboarding isn't automated.
Change management. Does every production change go through review and approval before deployment? Your pull request history and required-reviewer branch protection rules are your evidence here — if you don't already enforce this, it's a one-day fix with a lasting payoff.
Encryption in transit and at rest. TLS everywhere, encrypted storage volumes and databases, and — this is the part teams miss — documented key management. "We use RDS encryption" is not a control; "here is our key rotation policy and the last rotation date" is.
Vulnerability management. Regular dependency scanning, a documented severity-to-remediation-SLA mapping, and evidence that criticals actually got fixed within your stated SLA — not just that a scanner ran.
Incident response. A written incident response plan, and — critically — evidence that it's been tested, even informally, via a tabletop exercise. An untested plan is a document, not a control.
Where Engineering Teams Get Tripped Up
- Shared admin accounts. A shared "deploy" or "admin" login with no individual accountability fails access-control testing immediately — every account needs to map to an individual.
- No offboarding checklist. Access revocation that depends on someone remembering to do it manually, across six different systems, will eventually be missed — and auditors sample for exactly this.
- Undocumented emergency changes. The 2 a.m. hotfix that skipped code review because production was down needs a documented emergency-change exception process, used and logged — not silently bypassed review.
- Backup restores that have never been tested. A backup policy with zero evidence of a successful restore test is a control on paper only.
Building Your Evidence Trail as You Go
The expensive way to do SOC 2 is to scramble for evidence in the final weeks before the audit. The cheap way is to make your CI/CD pipeline generate the evidence as a byproduct of normal work:
# Example: a release workflow step that archives its own audit trail
- name: Archive deployment evidence
run: |
echo "Deploy: $(date -u +%Y-%m-%dT%H:%M:%SZ)" >> audit-log.txt
echo "Approved by: $" >> audit-log.txt
echo "PR: $" >> audit-log.txt
if: github.event_name == 'pull_request'
Six months of this running automatically is a complete, timestamped change-management evidence trail with zero manual effort at audit time — compared to reconstructing it retroactively from Slack messages and memory.
A Practical SOC 2 Prep Timeline
| Phase | Focus |
|---|---|
| Months 1–2 | Readiness assessment — gap analysis against the chosen Trust Services Criteria |
| Months 3–4 | Remediation — automate offboarding, enforce PR review, document policies |
| Month 5 | Type I audit (optional but common for first-timers) |
| Months 6–12 | Observation window — controls operate continuously, evidence accumulates automatically |
| Month 12+ | Type II audit |
SOC 2 rewards teams that already practice reasonable engineering discipline — code review, least-privilege access, tested backups — and penalizes teams that have been informally "doing the right thing" without ever writing it down or proving it happened. The gap between those two states is usually smaller, and cheaper to close, than the audit-prep industry would have you believe.
If you're heading into your first SOC 2 audit and aren't sure where your actual gaps are, talk to us — a focused readiness assessment is usually a day of work, not a quarter.