Compliance automation platforms — Vanta, Drata, Secureframe, Tugboat Logic — have transformed SOC 2 preparation in one important way: they have made it easier to see what evidence exists and what evidence is missing. They have not changed the underlying reality that if the controls are not in the system, no amount of evidence collection automation will produce passing evidence. A system with inadequate access controls generates evidence of inadequate access controls efficiently. The platform automates the observation; it does not change what is observed.
The architecture-first approach to SOC 2 builds systems that generate compliant evidence as a byproduct of their normal operations. Access logs are generated by the access control implementation. Change records are generated by the infrastructure-as-code pipeline. Incident records are generated by the incident management workflow. The SOC 2 evidence collection is then an extraction exercise, not a construction exercise. This distinction determines whether the 90-day Type II timeline is achievable or aspirational.
The Trust Service Criteria in Engineering Terms
SOC 2 is assessed against the AICPA Trust Service Criteria. The CC (Common Criteria) controls that most engineering decisions touch: CC6.1 (logical access controls), CC6.2 (registration and authorization for new users), CC6.3 (access removal for terminated or transferred users), CC7.1 (detection of deviations from baselines), CC7.2 (evaluation of security events), CC8.1 (change management). CC6.1 requires RBAC with least-privilege policies and access review records; CC6.3 requires automated deprovisioning triggered by HR system events; CC7.1 requires a SIEM with configured baselines and deviation alerts; CC8.1 requires infrastructure-as-code with all changes approved via pull request with required reviewers.
The SOC 2 Type II audit period is typically six months. The auditor will request evidence from throughout the audit period — not just from the day before the audit. An access review conducted once, the week before the audit began, does not satisfy CC6.1's continuous monitoring requirement. Access reviews must be conducted at the frequency specified in your control description and evidenced for the entire audit period. Build the access review cadence into your operational calendar at the start of the audit period, not at the end.
Compliance Automation vs. Compliance Architecture
Vanta and Drata operate by integrating with your infrastructure — AWS, GCP, GitHub, Okta — and querying those systems for evidence of control operation. The controls they can observe are limited to what those integrations expose. Vanta can observe that MFA is enabled on your GitHub organization. It cannot observe whether MFA is enforced for all privileged access to production infrastructure. Mapping each TSC criterion to the specific technical evidence it requires, and verifying that your infrastructure generates that evidence, is the architecture exercise that determines Type II readiness.
The 90-Day Type II Architecture
A 90-day Type II requires a six-month audit period that begins when the controls are operational — meaning the controls must be in production at month zero, not month three. The 90-day timeline is the time from engagement start to audit period start — not from engagement start to audit completion. The prerequisite: all CC6 through CC8 controls operational and generating evidence before the clock starts. The most common timeline failure: treating the 90 days as the audit period rather than the pre-audit implementation window.
- Map each TSC criterion to the specific technical evidence required before selecting a compliance automation platform
- Implement CC6.1 with automated access reviews on a defined cadence — quarterly at minimum for privileged access
- Build CC6.3 deprovisioning automation triggered by HR system events — manual deprovisioning is a Type II finding waiting to happen
- Deploy a SIEM with defined baselines for CC7.1 — without baselines, deviation detection is not configured
- Implement infrastructure-as-code with required reviewers for CC8.1 — direct infrastructure changes without code review fail CC8.1
- Start the audit period clock only after all controls are operational and generating evidence — not when implementation begins
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.