SOC 2: Engineering Controls, Not Collecting Screenshots
Your 18-person engineering team just landed a deal that changes the trajectory. The procurement team sends a security questionnaire and one non-negotiable requirement: SOC 2 Type II before contract signature. Six weeks to audit.
The health inspector is coming. The kitchen has no logbook.
You take inventory. No audit logs in immutable storage. Access reviews done manually via reply-all email chain from Q3 that nobody archived. Zero deployment audit trail because the senior engineer who deploys to production does it from his laptop via kubectl apply. Three engineers yanked from feature work for four weeks. Screenshots collected from eight different systems into a shared Google Drive folder. Cramming for an exam. The report arrives, barely. Three months later, every control has drifted back to its previous state. (The kitchen cleaned up for the inspection. It’s a mess again.)
- Engineers collecting screenshots for weeks is compliance theater. Months later, every control has drifted. The audit was waste, not assurance.
- SOC 2 TSC maps directly to engineering practices mature teams already maintain: audit logging, access reviews, change management, incident response.
- Compliance-as-code means controls enforce themselves. IaC policies prevent non-compliant resources. CI/CD audit trails write themselves. Access reviews run from IAM metadata.
- Continuous evidence collection eliminates the audit scramble. Stream control state to immutable storage. The audit trail stays current without anyone touching it.
kubectl applyfrom a laptop is a SOC 2 finding. All production changes must flow through a pipeline with audit logging, approval gates, and artifact signing.
SOC 2 Trust Service Criteria map to engineering practices mature teams already maintain. The difference between a clean audit and a panicked scramble is whether those controls were built year-round or bolted on before the auditor’s visit.
What the Security TSC Actually Covers
The Security Trust Service Criterion (required for every SOC 2 report) covers nine control families. Most map naturally to technical controls that also make you more secure. Not hoops dreamed up by bored auditors. Genuinely useful security practices you should want whether an auditor visits or not.
Logical access controls require that access is restricted to authorized users and revoked on departure. In practice: SSO with MFA enforced at the IdP, access provisioning tied to HR via SCIM, automated deprovisioning within 24 hours of offboarding, quarterly access reviews. If you don’t want these independent of an auditor, your security posture has bigger problems than SOC 2.
Change management requires changes to be authorized, tested, and documented. In practice: infrastructure changes via code with PR review, code changes via PR with CI gates, deployment logs stored as immutable evidence. Your CI/CD pipeline is the evidence generator. Every merge becomes a documented, approved, tested change with an audit trail that writes itself.
| TSC Category | Automated Control | Evidence Source | Collection Frequency |
|---|---|---|---|
| CC6.1: Logical access | IAM policy enforcement, MFA required, least-privilege validation | AWS IAM Access Analyzer, CloudTrail auth events | Continuous |
| CC6.2: System boundaries | Network segmentation, security group rules, WAF config | VPC Flow Logs, AWS Config rules | Continuous |
| CC6.3: Encryption | Encryption at rest enforced (EBS, S3, RDS), TLS in transit | AWS Config conformance pack, certificate monitoring | Daily scan |
| CC7.1: Monitoring | Centralized logging, anomaly detection, alert pipeline | CloudWatch, GuardDuty findings, SIEM dashboards | Continuous |
| CC7.2: Incident response | Automated triage, runbook execution, escalation | PagerDuty audit log, incident timeline, post-mortem records | Per incident |
| CC8.1: Change management | PR review required, CI/CD pipeline gates, deployment approval | GitHub audit log, pipeline execution records | Per change |
| A1.2: Availability | Auto-scaling, health checks, DR validation | CloudWatch metrics, DR test results, uptime records | Continuous + quarterly DR test |
Infrastructure That Generates Its Own Evidence
Most of the evidence problem disappears when infrastructure produces audit records as a side effect of normal work. The shift from compliance-as-sprint to compliance-as-practice cuts evidence prep from weeks to days. The engineering team barely notices the audit is happening.
AWS CloudTrail, GCP Cloud Audit Logs, and Azure Activity Logs capture every API call to cloud infrastructure: timestamp, actor identity, request parameters, response. Archive these to S3 with Object Lock enabled, and they become immutable evidence of who accessed what and when. An auditor asking “do you log access to production systems?” gets answered with a CloudTrail export and a date range filter.
VPC flow logs prove network segmentation works. Automated scanner reports (Qualys, Nessus, or Trivy running on schedule) prove scanning cadence. Endpoint enrollment records from Jamf or Intune prove devices are managed and encrypted. GitHub or GitLab audit logs prove PR approval workflows. Each of these is an engineering investment that satisfies SOC 2 requirements as a byproduct of doing your job well. For how this integrates at the infrastructure layer, a cloud-native platform engineering approach makes these controls native to the deployment process.
Don’t: Collect SOC 2 evidence via manual screenshots saved to a shared drive. This produces stale data, inconsistent formatting, and evidence that auditors immediately question.
Do: Stream control state to immutable storage continuously. CloudTrail to Object Lock S3, SSO logs via API export, scanner reports on automated schedule. Evidence that generates itself is always current and tamper-proof.
If you already have a well-instrumented DevSecOps practice , most of the evidence problem is solved before the auditor even shows up.
Access Reviews Without the Quarterly Scramble
Access reviews keep showing up as SOC 2 findings for teams that run them by hand. Always the same way. Quarterly calendar reminder fires. Someone exports a spreadsheet of user accounts from each system. Managers reply-all with approvals. Half the replies say “looks fine” with no real review. Security reconciles responses. This takes 2-3 weeks per quarter, produces stale data, and generates evidence that auditors have gotten very good at spotting as rushed.
- Single Sign-On covers 95%+ of your application estate
- SCIM provisioning connects your IdP to critical SaaS applications
- Offboarding process revokes access within 24 hours of HR action
- Access review tooling integrates directly with your identity provider
- Reviewers can approve or revoke access inline without spreadsheet exports
Automated access review tools (or compliance platforms like Vanta and Drata that plug into your identity provider and SaaS apps) run continuous monitoring and kick off structured reviews on schedule. Reviewers see current access data and approve or revoke right in the workflow. Audit-ready evidence falls out automatically.
The prerequisite is SSO coverage. Teams that get broad SSO coverage before pursuing SOC 2 complete access reviews in hours instead of weeks. If you have dozens of separate user stores across legacy applications, automation is much harder and quarterly manual reviews remain necessary until SSO coverage improves. Make SSO migration the first investment before engaging an auditor. Every application behind SSO is one fewer manual access review, and the time saved compounds with every audit cycle.
Vendor Risk Management at Scale
Vendor risk assessment is a SOC 2 requirement that doesn’t scale by hand. Each vendor needs a risk assessment, a look at their security docs, and ongoing monitoring. With 50 SaaS vendors and annual review cycles, 10-15 assessments will quietly expire every year if you’re tracking them manually. Nobody notices until the auditor does.
The practical approach: pick vendors who have their own SOC 2 Type II reports and share them. For vendors without SOC 2, use a standardized security questionnaire (SIG Lite is the standard) and set review intervals based on data sensitivity and access level. Automate renewal reminders so assessments don’t expire without anyone noticing. The security program tie-in is direct: vendor risk becomes a tracked obligation with a deadline, not a calendar item someone might remember.
One trick that saves real time: during vendor evaluation, check if the vendor shares their SOC 2 report through a trust center portal. This cuts out the manual NDA and report request cycle that adds 2-3 weeks to vendor onboarding.
When SOC 2 Should Wait
| Invest in SOC 2 now | Defer it |
|---|---|
| Prospects require it before contract signature | No customer has asked for it |
| You process or store customer data at scale | Your product handles no sensitive data |
| SSO covers most of your application estate | Dozens of apps with separate user stores |
| CI/CD pipelines already enforce change management | Engineers deploy from laptops via kubectl |
| You have budget for a compliance platform | The security team is one person wearing four hats |
Going for SOC 2 before SSO coverage and CI/CD discipline are in place turns the audit into theater instead of documentation. Get the foundations right first. The controls should already be useful before the auditor shows up.
What the Industry Gets Wrong About SOC 2 Compliance
“Buy a compliance platform and check the box.” Compliance platforms collect and organize evidence. They don’t create the controls. A platform that ingests screenshots of manually configured resources just automates the documentation of non-compliance. You have to build the controls into your infrastructure first.
“SOC 2 is a security certification.” SOC 2 is a trust framework covering security, availability, processing integrity, confidentiality, and privacy. Security is one of five Trust Service Criteria. Teams that treat SOC 2 as purely a security exercise miss availability and processing integrity requirements entirely.
“You need a dedicated compliance team.” What you need is engineering discipline. If your CI/CD pipeline already enforces PR review, your IdP already logs access events, and your scanners already run on schedule, the compliance team’s job shrinks to organizing evidence that already exists. Hiring more people isn’t the answer when the infrastructure can do the work.
Six weeks to audit, and this time nobody scrambles. Access reviews run automatically through the IdP integration. The deployment trail is immutable in Object Lock storage. The evidence platform already has everything the auditor needs. Three engineers stay on feature work instead of collecting screenshots. The contract signs on schedule because the controls were running all year, generating evidence as a side effect of doing the job well.