SOC 2 is the most common deal-breaker in B2B sales. A prospect loves your product, then procurement asks for your SOC 2 report, and the deal stalls for six months while you figure out what a “control environment” even is. For a 5–15 person team, the standard advice — hire a GRC consultant, buy a compliance platform, spend a year collecting screenshots — sounds like a death sentence.
Here is the secret the compliance industry does not advertise: SOC 2 is roughly 20% policy and 80% evidence, and evidence is something DevOps teams are already excellent at generating automatically. If you treat compliance as an engineering problem instead of a paperwork problem, a lean SMB can reach a SOC 2 Type I report in about 90 days using the tools you already run. This guide shows you exactly how, with scripts and configs you can copy.
Why SOC 2 Feels Impossible (and Why It Isn’t)
First, the scope. SOC 2 covers five Trust Services Criteria — security, availability, processing integrity, confidentiality, and privacy — but the vast majority of SMBs only need the security criteria (the “common criteria” CC1–CC9) to satisfy customers. You can add availability or confidentiality later without redoing the foundation.
Second, the real cost driver is manual evidence: someone exporting IAM users into a spreadsheet every month, screenshotting the backup job, digging out last quarter’s access review. Auditors do not require expensive tools — they require consistent, timestamped, tamper-evident evidence that controls actually ran. That is a cron job, not a consulting engagement.
Third, Type I (controls designed properly) versus Type II (controls operated over a period, usually 6–12 months). For landing enterprise customers, Type I unlocks most deals; Type II is the follow-up. The 90-day plan below gets you to Type I, with the evidence pipeline already running so Type II is just a matter of waiting.
Map Every Control to a Tool You Already Have
Before writing a single policy, build a control matrix and map each control to an automated evidence source. If a control has no machine-generated evidence, replace the control — not the evidence. A starter matrix for a typical SMB running AWS and GitHub:
| Common control | Evidence source | Automation |
|---|---|---|
| Access reviews (quarterly) | IAM user list + last-login export | Script + calendar reminder |
| Change management | Git history, CI/CD runs | GitHub Actions audit log |
| Backup & restore testing | Backup job logs + restore test report | Nightly cron + alert on failure |
| Vulnerability scanning | Trivy / OpenSCAP JSON reports | Scheduled CI job |
| Least privilege | IAM policy JSON + Terraform plan | OPA policy in CI |
| Incident response | On-call rotation + incident timeline export | Alerting tool API |
| Logging & monitoring | CloudTrail / audit logs | Log shipping to S3 |
Keep the matrix itself in your repo as a simple YAML file so it is versioned, reviewed in PRs, and never lost in a shared drive:
# controls.yaml
controls:
- id: CC6.1
name: "Access to systems is restricted"
evidence: "iam_access_review/"
schedule: "quarterly"
owner: "platform-team"
- id: CC7.2
name: "Vulnerabilities are identified and remediated"
evidence: "vuln_scan/"
schedule: "weekly"
owner: "platform-team"Automate Evidence Collection with a Cron Job
This is the heart of the whole strategy. One script, run nightly, that collects every piece of evidence into a versioned, encrypted S3 bucket with a date prefix. Auditors love this because it is immutable, timestamped, and impossible to “forget”.
#!/usr/bin/env bash
# /usr/local/bin/collect-evidence.sh
set -euo pipefail
DATE=$(date +%F)
BUCKET="s3://acme-evidence-bucket/$DATE"
# 1. IAM access review snapshot (users, keys, last activity)
aws iam generate-credential-report
sleep 3
aws iam get-credential-report --query 'Content' --output text \
| base64 -d > iam-credential-report.csv
# 2. CloudTrail audit log tail for the day
aws cloudtrail lookup-events --lookup-attributes \
AttributeKey=EventSource,AttributeValue=iam.amazonaws.com \
--max-results 500 > cloudtrail-iam.json
# 3. Backup verification report (Velero or your DB dumps)
velero get backups --output json > velero-backups.json
velero backup describe --details latest > velero-latest.txt
# 4. Vulnerability scan summary
trivy fs --scanners vuln,misconfig --format json . \
> vuln-scan.json 2>/dev/null || true
# 5. Upload with server-side encryption; keep 400 days
aws s3 cp --sse aws:kms . "s3://$BUCKET/" --recursive
aws s3 ls "s3://$BUCKET/" && echo "EVIDENCE COLLECTED: $DATE"Schedule it with cron (or a scheduled GitHub Actions workflow for the same effect):
# crontab -e
15 2 * * * /usr/local/bin/collect-evidence.sh >> /var/log/evidence.log 2>&1That single script covers access reviews, change management evidence, backup testing proof, and vulnerability management — four of the most-audited control families. When your auditor asks “show me your access review,” you point at a folder of dated reports, not a spreadsheet someone forgot to update.
Enforce the Controls as Code So the Evidence Is Always True
Evidence is only worth something if the control actually holds. The trick is to enforce controls in Terraform so that non-compliant infrastructure cannot be created in the first place. A few HCL fragments that auditors love to see:
# Evidence bucket: versioned, encrypted, locked
resource "aws_s3_bucket" "evidence" {
bucket = "acme-evidence-bucket"
}
resource "aws_s3_bucket_versioning" "evidence" {
bucket = aws_s3_bucket.evidence.id
versioning_configuration { status = "Enabled" }
}
resource "aws_s3_bucket_server_side_encryption_configuration" "evidence" {
bucket = aws_s3_bucket.evidence.id
rule {
apply_server_side_encryption_by_default {
kms_master_key_id = aws_kms_key.evidence.arn
sse_algorithm = "aws:kms"
}
}
}
# CloudTrail: audit logging everywhere, cannot be disabled by accident
resource "aws_cloudtrail" "all" {
name = "org-audit-trail"
s3_bucket_name = aws_s3_bucket.evidence.id
include_global_service_events = true
is_multi_region_trail = true
enable_log_file_validation = true
}Pair the infrastructure with policy checks in CI: use OPA policies to block S3 buckets without encryption or IAM roles with wildcard permissions, run terraform plan in every PR to catch drift, and schedule CIS benchmark scans with OpenSCAP or trivy --scanners misconfig monthly. Our DevSecOps guide and the secrets management playbook cover the CI and credential side of the same story.
One more control worth automating before the audit: quarterly access reviews. A script that emails every manager a list of their team’s IAM users with last-login dates, and archives the reply as evidence, converts the most commonly failed audit finding into a non-event.
The 90-Day Runway (and What It Actually Costs)
Here is a realistic plan for a team of 5–10:
- Days 1–30 — Gap analysis. Build the control matrix, identify the 10–15 controls you will certify, and fix the two or three real gaps (usually: no MFA policy, no evidence bucket, no backup restore tests).
- Days 31–60 — Automate. Deploy the evidence collector, Terraform the guardrails, wire OPA into CI, and let the nightly job build two weeks of evidence.
- Days 61–90 — Dry run. Hire a freelance SOC 2 auditor (typically $3k–$8k for a Type I readiness review, versus $30k+ for a full GRC engagement) to review your evidence pipeline and fix findings. Then run the real Type I audit — usually $8k–$15k for a small company.
The total out-of-pocket cost lands around $15k–$25k, most of it the audit itself, and the ongoing cost is one cron job. Compare that with a compliance platform at $10k+/year plus a consultant at $200/hr, and you can see why treating compliance as an engineering problem wins.
Want help scoping your control matrix or building the evidence pipeline? Book a free 30-minute session and we will map your current stack to a 90-day SOC 2 plan: reserve your slot here.
English 
Español