SOC 2 Type II in 90 Days: The Architecture-First Approach

SOC 2 Type II in 90 days is achievable. It is not the default outcome of SOC 2 preparation, and it requires making the right architectural decisions at the start of the process rather than treating the audit as a documentation exercise. Organizations that miss the 90-day target almost always do so for one reason: they built the system first and then tried to retrofit the controls.

Type II audits cover operating effectiveness over a period — the AICPA's minimum audit period is six months, but many auditors will accept a 90-day window for a first-time Type II, particularly for organizations that have done the architectural groundwork. The key is that the evidence collection must be automated and continuous from day one of the audit period.

The Trust Service Criteria as Engineering Requirements

The SOC 2 Trust Service Criteria (TSC) are not policy requirements — they are engineering requirements that happen to be expressed in policy language. CC6.1 (Logical and Physical Access Controls) requires that access to systems is restricted to authorized users — this is implemented in your identity provider, your infrastructure IAM policies, and your application authorization layer. CC6.2 (Prior to Issuing System Credentials) requires a formal process for provisioning and deprovisioning access. CC7.2 (The Entity Monitors System Components) requires that monitoring of system components is implemented.

The Infrastructure-as-Code Advantage

The change management criteria (CC8) require evidence that system changes go through a formal change management process, are tested before deployment, and are approved by authorized personnel. The most efficient way to satisfy CC8 for cloud infrastructure is infrastructure-as-code (IaC) with pull request review gates and deployment pipeline approval steps. Every Terraform plan, every PR review, every pipeline run generates timestamped, attributable evidence of the change management process. Manual change management documentation — the kind that gets written retrospectively — fails Type II audits.

The same principle applies to vulnerability management (CC7.1): if you're running automated vulnerability scans through your CI/CD pipeline and collecting the results, you have continuous evidence of the vulnerability management process. If you're running scans manually and saving the output to a shared drive, you have gaps in the evidence record that the auditor will notice.

The 90-Day Architecture Checklist

1. Implement SSO and MFA across all in-scope systems before the audit period starts — access control exceptions are the most common Type II finding
2. Configure IaC for all infrastructure changes — every environment, not just production
3. Set up automated vulnerability scanning in CI/CD — SAST, DAST, and dependency scanning, with results stored and tracked
4. Implement centralized SIEM with alerting — the evidence requirement for monitoring is continuous, not periodic
5. Build automated access review processes — quarterly reviews via your IdP API, not spreadsheet exports
6. Configure automated backup and recovery testing — the availability criteria (A1) require tested recovery procedures
7. Establish an incident response runbook with defined severity levels, escalation paths, and post-incident review process

Common Type II Failure Points

The most common Type II failure points we see in fintech environments: (1) incomplete MFA coverage — MFA on the production console but not on the CI/CD platform or the database admin interface; (2) shared credentials for infrastructure access — service accounts with human access; (3) access reviews that were scheduled but not executed; (4) log retention gaps created by log rotation without archival.

Our compliance infrastructure practice has built SOC 2 Type II programs for fintech clients with a 90-day first audit window. The common thread: IaC from day one, automated evidence collection built into the pipeline, and no manual evidence collection processes.