SOC 2 for Engineering Teams: The Evidence Plan
- SOC 2 is an evidence audit, not a controls audit. Most engineering practice already meets the spirit; the work is in producing the trail.
- Continuous evidence collection beats annual scrambles. Automate it once, harvest it forever.
- Access reviews are the most commonly failed control because they are usually not done at all.
- Type II audits cover a 6-12 month period; the work needs to start that far in advance.
A team came to us six weeks before their first SOC 2 Type II audit window. They had hired a compliance manager who had outlined the controls; the engineering team had said “we already do all this”. The compliance manager replied that the auditor would not accept “we already do this” as evidence; they needed logs, tickets, screenshots, signed approvals.
We spent the six weeks not implementing new controls (the team did roughly 80 percent of what was needed already) but installing the evidence pipeline. By audit time, every required control had a queryable evidence trail covering the audit period. The audit passed cleanly. The next year’s audit took two days of preparation instead of six weeks.
This piece is about that pattern. SOC 2 from an engineering perspective is mostly evidence work. The teams that pass smoothly are the ones that collect the evidence continuously; the teams that fail are the ones that go looking for evidence after the fact.
What SOC 2 actually checks
SOC 2 has five Trust Services Criteria (TSCs):
| TSC | What it covers |
|---|---|
| Security | Access controls, change management, incident response, vulnerability management, network security |
| Availability | Uptime, monitoring, capacity planning, business continuity |
| Confidentiality | Data classification, encryption, access restrictions on confidential data |
| Processing Integrity | Data processing accuracy, completeness, validity |
| Privacy | Personal information collection, use, retention, disposal |
Security is mandatory; the others are chosen based on what your customers care about. Most B2B SaaS in 2026 pursue Security + Availability + Confidentiality. Privacy is added when personal data is central to the product.
Within each TSC, the audit checks specific Common Criteria. Each criterion has a written control description, and the auditor needs evidence that the control operated effectively over the audit period.
What “evidence” means to an auditor
Evidence is artifacts the auditor can verify. The standard shapes:
Logs. Application logs, access logs, audit logs. Specific events captured at specific times. The auditor samples them and checks: was the event captured, does the timestamp match other systems, can you query for similar events across the audit period.
Tickets. Change-management tickets, incident tickets, access-request tickets. The auditor wants to see the workflow: requested by, approved by, implemented by, with timestamps and identities at each step.
Screenshots and reports. Configuration screenshots from infrastructure consoles, periodic reports (access reviews, vulnerability scans). The auditor wants timestamps, the system that produced them, and a clear chain of who reviewed them.
Signed approvals. Senior approvals on policy changes, access grants, change requests. The signature can be electronic but it must be attributable.
Documented policies. Written policies the team follows, reviewed and updated annually, signed by an owner.
The auditor’s job is to verify that the evidence is genuine, that it covers the audit period (no gaps), and that the controls were operating throughout. “We started doing this last week” does not pass a Type II audit.
The evidence pipeline
The engineering investment that makes SOC 2 ongoing rather than annual is the evidence pipeline: automation that collects the artifacts continuously and stores them in a queryable form.
A working pipeline:
[Source systems]
- GitHub: PR approvals, branch protection, code reviews
- Cloud provider (AWS/GCP/Azure): IAM changes, security groups, encryption
- Identity provider (Okta, Azure AD): user provisioning, deprovisioning
- Ticket system (Jira, Linear): change tickets, incident tickets
- CI/CD: deployment logs, test results
- Monitoring (Datadog, etc.): SLO breaches, incident timelines
- SaaS tools (Slack, Notion, etc.): access changes
[Evidence collector]
- Daily snapshots of critical configurations
- Continuous log shipping to a long-retention store (90+ days)
- Quarterly automated reports: access lists, change summaries, incident counts
- Tagging of audit-relevant events for fast retrieval
[Evidence store]
- Long-retention storage (S3 with lifecycle, Snowflake, BigQuery)
- Queryable by date range, control area, evidence type
- Read-only access for auditors during the audit windowCompliance platforms (Vanta, Drata, Secureframe, Sprinto) automate large parts of this pipeline. For teams in the 10-100 engineer range with standard cloud stack, they typically pay for themselves vs the engineering time to build custom collection.
For larger teams or unusual stacks, custom evidence pipelines can be more efficient. The build-vs-buy line is around the team having dedicated security engineering capacity.
The three controls most teams fail
After auditing readiness for a number of teams, three controls consistently surface as the gaps:
Quarterly access reviews. A required control: every user’s access to production systems is reviewed quarterly by a designated owner who confirms the access is still appropriate. Most teams do not do this. Some do it informally, but without written sign-off and a documented review cycle.
The fix: a quarterly process where a list of users-and-permissions is generated, sent to designated reviewers, and signed off. The artifact is the signed review, archived. Some platforms automate this; otherwise it’s a 4-hour quarterly task for one named person.
Vendor risk assessments. SOC 2 expects you to assess the risk of your sub-processors and vendors that touch customer data. Most engineering teams do not have a formal process for this; they sign vendor contracts ad-hoc.
The fix: a vendor inventory, a per-vendor risk assessment template, and a review cadence (annual at minimum). Compliance platforms often include this; otherwise a spreadsheet maintained by the security or compliance lead.
Security awareness training. All employees with access to production must complete annual security training. Many teams skip this for engineers (“they know”) but the auditor wants completion records.
The fix: pick a vendor (KnowBe4, Proofpoint, Curricula, internally-built), assign the training, track completion, archive the records. Annual cadence; usually 2-4 hours per employee.
How long the work takes
For a team with no prior SOC 2 work:
- Readiness assessment: 1-2 weeks (gap analysis against the criteria)
- Policy work: 2-4 weeks (writing the policies the auditor will read)
- Evidence pipeline: 4-8 weeks (depending on stack and platform choice)
- Process changes: 4-8 weeks (access reviews, vendor reviews, training)
- Pre-audit testing: 2-3 weeks (have someone internal try to find evidence as if they were the auditor)
- Type I audit: 1-2 weeks (the actual audit)
- Type II observation period: 6-12 months
- Type II audit: 1-2 weeks
Total elapsed time for first Type II: 9-18 months. Subsequent annual audits: 4-8 weeks of focused work, mostly the audit itself.
What teams over-invest in
Counterintuitive but consistent patterns of waste:
Custom security tooling. A team builds a custom secrets scanner, custom dependency vulnerability detector, custom IAM enforcement layer. The auditor accepts standard tools (Trivy, Dependabot, AWS native controls) without complaint; the custom work was for the engineering team’s preferences, not for the audit.
Overly strict change management. “Every production change requires three approvals” is a control the auditor will accept and that engineers will silently work around. A simpler “every production change requires one approval and is logged” passes the audit and stays followed.
Encrypting things that do not need encrypting. Encryption at rest is required for sensitive data. Some teams encrypt everything, including data that has no sensitivity, on the theory that more is safer. The cost is operational complexity (key management, performance overhead) without compliance benefit.
What we install on engagements
For a team starting SOC 2 fresh:
- Gap analysis against the chosen TSCs (1-2 weeks)
- Policy authoring for the controls without existing documentation (2-4 weeks)
- Evidence pipeline via compliance platform or custom (4-8 weeks)
- Process implementation for access reviews, vendor reviews, training (3-4 weeks of distributed work)
- Pre-audit dry run (2 weeks)
- Type I audit for an interim certification, optional but useful
For a team renewing or maintaining: the pipeline is already in place; quarterly process discipline keeps the evidence current; the audit is a periodic check rather than a project.
The teams that treat SOC 2 as ongoing engineering hygiene pass annually with minimal disruption. The teams that treat it as a project pay the cost in full every year. The work is the same; the timing is different.
Questions teams ask
Do we need a compliance platform like Vanta or Drata?
Useful but not essential. They automate evidence collection across cloud providers and SaaS tools. For a small team, the time savings often justify the cost. For a larger team with existing tooling, custom evidence pipelines may fit better.
What's the difference between Type I and Type II?
Type I is a point-in-time snapshot ('these controls existed on date X'). Type II is a period audit ('these controls operated effectively from date X to date Y', usually 6-12 months). Customers almost always want Type II; Type I is an interim step.
Which Trust Services Criteria do we actually need?
Security is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional and chosen based on customer needs. Most B2B SaaS pursue Security plus Availability and Confidentiality; Privacy if you handle personal data heavily.