SOC 2 in 90 days: an engineering-first approach

SOC 2 Type II certification has become table stakes for any company selling software or services to the enterprise. Customers require it. Procurement teams check for it. And the absence of it kills deals. Yet for most organizations -- particularly fast-growing startups and mid-market companies -- the path to SOC 2 feels like a compliance marathon: months of policy writing, evidence gathering, consultant fees, and engineering time diverted from product development.

It does not have to be this way. An engineering-first approach to SOC 2 -- one that treats security controls as code, automates evidence collection, and builds compliance into the development lifecycle rather than bolting it on after the fact -- can compress the timeline from the typical 9 to 12 months to as little as 90 days. The key is recognizing that SOC 2 is fundamentally an engineering problem, not a paperwork problem.

Understanding What SOC 2 Actually Requires

Before optimizing the process, it is important to understand what SOC 2 actually evaluates. SOC 2 is organized around five Trust Services Criteria:

1. Security -- protection against unauthorized access (the only mandatory criterion)
2. Availability -- the system is available for operation and use as committed
3. Processing Integrity -- system processing is complete, valid, accurate, and timely
4. Confidentiality -- information designated as confidential is protected
5. Privacy -- personal information is collected, used, retained, disclosed, and disposed of properly

Most organizations pursuing SOC 2 for the first time include Security and Availability. The scope can be expanded later based on customer requirements.

The distinction between Type I and Type II matters:

• Type I evaluates the design of controls at a specific point in time -- a snapshot
• Type II evaluates the operating effectiveness of controls over a period (typically 3 to 12 months) -- evidence that controls work consistently

Type II is what customers actually want. It proves not just that you have controls but that they function reliably over time.

Security-as-Code: The Foundation

The engineering-first approach begins with a fundamental principle: every security control should be defined, enforced, and verified through code. This is not aspirational -- it is the specific practice that makes 90-day SOC 2 possible.

Security-as-code means:

• Infrastructure as Code (IaC) -- all infrastructure is defined in Terraform, Pulumi, or CloudFormation. No manually provisioned resources. Every configuration is version-controlled, reviewed, and auditable.
• Policy as Code -- security policies are expressed as code (Open Policy Agent, Sentinel, AWS Config rules) that automatically evaluates compliance. A resource that violates policy either cannot be deployed or is flagged in real time.
• Configuration as Code -- application security configurations (encryption settings, access controls, network policies) are defined in code and applied consistently across environments.

When security controls are code, they are inherently auditable. The auditor does not need to ask "do you encrypt data at rest?" and wait for someone to check. The Terraform configuration shows the encryption settings. The policy-as-code rule shows that unencrypted resources cannot be deployed. The CI/CD pipeline logs show that the policy was enforced on every deployment.

This collapses the evidence chain from weeks of manual documentation to seconds of automated reporting.

Automated Controls That Run Continuously

SOC 2 Type II requires evidence that controls operate effectively over time. In a traditional compliance approach, this means periodic manual reviews -- someone checks access lists quarterly, reviews firewall rules monthly, and verifies encryption settings during annual assessments. This is labor-intensive, error-prone, and fundamentally backward-looking.

The engineering-first alternative is continuous, automated control verification:

Access Control

• Automated provisioning and deprovisioning tied to identity provider events (hire, role change, termination)
• Access reviews run as automated scripts that compare current access to authorized access and flag discrepancies
• Privileged access managed through just-in-time elevation with automatic expiration and full audit logging

Change Management

• All changes flow through version control -- Git history provides a complete, immutable audit trail of who changed what, when, and why
• Code review requirements enforced by branch protection rules -- no change merges without peer review
• Automated testing validates that changes do not break security controls before deployment

Monitoring and Incident Response

• Centralized logging with automated alerting on security-relevant events
• Automated incident classification that routes alerts based on severity and type
• Incident response runbooks encoded in automation, with manual escalation for high-severity events

Vulnerability Management

• Automated dependency scanning in CI/CD pipelines, blocking deployments with critical vulnerabilities
• Container image scanning before registry push
• Infrastructure scanning on a continuous schedule with automated ticket creation for findings

Each of these automated controls generates evidence continuously. When the auditor arrives, the evidence is already collected, timestamped, and organized -- not scrambled together in a last-minute document sprint.

The 90-Day Playbook

Compressing SOC 2 to 90 days requires disciplined execution across three parallel workstreams.

Weeks 1-2: Foundation

• Select auditor and agree on scope (Trust Services Criteria, system boundaries, observation period)
• Implement identity provider with MFA enforcement for all users
• Establish infrastructure-as-code baseline for all cloud resources
• Deploy centralized logging and monitoring
• Set up automated vulnerability scanning in CI/CD

Weeks 3-6: Control Implementation

• Implement policy-as-code rules for critical security controls
• Automate access provisioning and deprovisioning
• Configure branch protection and code review requirements
• Deploy automated backup and recovery testing
• Establish incident response procedures with automated classification
• Write policies that accurately describe the automated controls already in place (not aspirational policies that describe controls you plan to build)

Weeks 7-12: Evidence Collection and Audit

• Begin the Type II observation period (some auditors accept periods as short as 3 months for initial audits)
• Automated controls generate evidence continuously throughout the period
• Conduct internal readiness review at week 9, addressing any gaps
• Auditor performs fieldwork, reviewing automated evidence and testing control effectiveness
• Receive report

The critical insight is that weeks 7-12 are not a separate "audit phase" -- they are simply the period during which the automated controls you built in weeks 1-6 generate the evidence the auditor needs. If the controls are working, the audit is a formality.

Continuous Compliance: Beyond the First Audit

The engineering-first approach delivers a benefit that extends far beyond the initial certification: continuous compliance. Because controls are automated, evidence is collected continuously, and policies are enforced through code, the organization is always audit-ready. The annual SOC 2 renewal becomes a review of continuously collected evidence rather than a scramble to reconstruct a year's worth of manual documentation.

Continuous compliance also enables:

• Real-time compliance dashboards that show control status at any moment
• Automated drift detection that identifies when configurations deviate from compliant baselines
• Compliance-as-a-feature for customer-facing security posture -- sharing real-time compliance status through trust pages and security questionnaire automation
• Extensibility to additional frameworks -- the same automated controls and evidence collection can be mapped to ISO 27001, HIPAA, PCI DSS, and other frameworks with minimal additional work

The Engineering Mindset

The fundamental shift in an engineering-first approach to SOC 2 is treating compliance as an engineering discipline rather than a governance exercise. Policies are code, not documents. Controls are automated, not manual. Evidence is continuous, not periodic. And the security posture improves as a result -- not because the organization wrote better policies, but because it built better systems.

For fast-growing companies, this approach has a second benefit: it scales. Manual compliance processes break as the organization grows. Automated controls do not. The investment in security-as-code and continuous evidence collection pays dividends not just in faster SOC 2 certification but in a security posture that improves with every deployment rather than degrading between audits.