Preparing for SOC 2: A DevOps Team's Checklist

Your biggest prospect just asked for your SOC 2 report. You don't have one. The board is asking when you'll be "SOC 2 compliant." Your engineering team is overwhelmed with feature work and has no idea where to start.

We've taken more than a dozen companies through SOC 2 Type II preparation. The infrastructure side — which is 60–70% of the work — follows a predictable pattern. Here's the checklist we use.

What SOC 2 actually requires

SOC 2 is based on five Trust Service Criteria. Most startups pursue Security and Availability first (the minimum viable scope), then add Confidentiality and Processing Integrity later.

The audit examines your controls — the policies and technical measures you have in place — not your code quality. An auditor doesn't read your source code; they check whether you have access controls, encryption, monitoring, and incident response procedures in place and can prove they've been working.

The infrastructure checklist

Access control

• SSO with MFA enforced for all production systems (cloud console, Kubernetes, CI/CD, monitoring)
• Role-based access control (RBAC) in Kubernetes — no cluster-admin for developers
• Principle of least privilege — service accounts with scoped permissions, not shared credentials
• Access reviews — quarterly audit of who has access to what, with documented approvals
• Offboarding process — automated revocation within 24 hours of departure

Encryption

• TLS 1.2+ for all data in transit (no exceptions — internal service-to-service included)
• Encryption at rest for all datastores (databases, object storage, volumes)
• Secret management via a dedicated tool (Vault, AWS Secrets Manager, or Sealed Secrets) — no secrets in code, no secrets in environment variables visible in CI logs
• Certificate rotation automation (cert-manager for Kubernetes)

Logging & monitoring

• Centralized log aggregation (ELK, Loki, or a managed service) — all application and system logs in one place
• Audit logging for all administrative actions (kubectl commands, cloud console changes, CI/CD pipeline runs)
• Log retention — minimum 90 days, ideally 1 year for audit purposes
• Alerting on security events (failed logins, privilege escalations, unusual API patterns)
• Uptime monitoring with documented SLAs

Network security

• Network policies in Kubernetes — default-deny ingress, explicit allow rules
• Private subnets for databases and internal services
• WAF or equivalent for public-facing endpoints
• VPN or zero-trust access for administrative access (no SSH from the internet)
• Egress filtering — know what your services are connecting to

Change management

• All infrastructure changes through code (Terraform, Helm, GitOps) — auditable Git history
• Pull request reviews required for production changes
• Separate CI/CD pipelines for staging and production with approval gates
• Rollback procedures documented and tested

Incident response

• Written incident response plan with defined severity levels
• On-call rotation with documented escalation procedures
• Post-incident review process (blameless postmortems)
• Customer notification procedure for data breaches

Vulnerability management

• Container image scanning in CI/CD (Trivy, Snyk, or equivalent)
• Dependency scanning for known CVEs
• Runtime vulnerability scanning on a scheduled basis
• Patch management process with defined SLAs (critical: 48 hours, high: 1 week)

The 6-week timeline

For a typical startup with existing Kubernetes infrastructure:

• Week 1: Gap assessment — audit current controls against the checklist above
• Weeks 2–3: Technical implementation — SSO/MFA, RBAC, encryption, network policies, logging
• Week 4: Documentation — policies, procedures, architecture diagrams
• Week 5: Internal audit dry run — simulate the audit process
• Week 6: Remediation and final review

After these 6 weeks, you're ready to engage an auditor for your Type I report (point-in-time). Type II (over a period, usually 6–12 months) starts from that point, during which the auditor verifies your controls remain effective.

"We thought SOC 2 would take 6 months and a dedicated security hire. DevOps Team had us audit-ready in 6 weeks. The auditor said our infrastructure controls were among the best they'd seen at our stage."