SOC 2 auditors don’t take your word for it. They want evidence each time. The companies that fail their audits didn’t lack controls — they lacked documentation that those controls operated.
Most SOC 2 content online is either too generic or too formal. This is neither. It’s the actual work plan from a gap assessment we completed for our own platform — the specific steps, the specific documents, and the specific infrastructure decisions that move an AI SaaS company from zero to Type 1.
Walk through this once. It doesn’t need to be mysterious.
Step 1 — The Gap Assessment
Before you build anything, you need to know what you’re missing. A SOC 2 gap assessment evaluates your current state across 8 compliance domains.
Access Control
Who has access to what, how it’s granted, reviewed, and revoked.
Audit Logging
What actions are logged, at what granularity, for how long, and with what protections.
Encryption
Data at rest and in transit, key management.
Incident Response
Documented process for detecting, responding to, and reporting security incidents.
Risk Assessment
Formal process for identifying and prioritizing security risks.
Vendor Management
How third-party vendors are evaluated and monitored.
Change Management
How infrastructure and code changes are reviewed, approved, and deployed.
Monitoring
Continuous monitoring of system health and security events.
The gap assessment produces a prioritized list of what’s missing. Focus first on the controls that show up most clearly in the auditor’s review of your design documentation.
Step 2 — The 7 Policy Documents You Actually Need
SOC 2 requires documented policies. The auditor will read them. The first trap: writing policies that are aspirationally long but operationally hollow. A 40-page security policy that nobody reads and that doesn’t match how you actually operate is worse than a 4-page policy that’s accurate.
Security Policy
The foundational document describing your overall security posture, risk tolerance, and control objectives. Keep it short. Make it true.
Access Control Policy
How access is granted, what roles exist, how access is reviewed and revoked. This document must match your actual Keycloak or IAM configuration.
Incident Response Plan
Specific, actionable steps for detecting, containing, and reporting security incidents. Name the people responsible. Define the timelines. Make it something you’d actually follow.
Change Management Policy
How infrastructure and code changes are reviewed, tested, and approved before deployment. Your CI/CD pipeline should enforce this, not just document it.
Data Classification Policy
What categories of data you handle, how each category is protected, and who can access each category.
Vendor Management Policy
How you evaluate and monitor third-party vendors who have access to your systems or data. List your actual vendors.
Business Continuity Plan
What happens if critical systems go down. Minimum: defined RTO/RPO targets and documented recovery procedures.
Step 3 — Infrastructure Controls That Map to SOC 2
Policy documents describe your controls. Infrastructure controls implement them. The gap between the two is where Type 2 audits get difficult.
Authentication-as-Code
Keycloak configured through Terraform means every access control change is version-controlled and auditable. Your access control policy says roles are defined in code and changes require a pull request. Your deployment history proves it.
Secret Rotation
Infisical or equivalent with 90-day rotation schedules for all API keys, service account credentials, and tokens. The rotation is automated and logged. Your auditor doesn’t have to take your word that credentials are rotated — the rotation log is evidence.
Audit Logging
Every significant system action logged to a tamper-evident destination with a defined retention period. For AI agent platforms: proxy-layer logs that capture every agent action independently of the agent’s execution context.
Encryption at Rest and in Transit
TLS for all external communications, encrypted volumes for all persistent storage. Configuration enforced at the infrastructure layer, not just the application layer.
Monitoring
Automated alerting for anomalous access patterns, failed authentication attempts above threshold, and system availability events.
Step 4 — Automated Evidence Collection
SOC 2 Type 2 requires evidence that your controls operated consistently over the observation period. Collecting that evidence manually is labor-intensive and error-prone. Automated evidence collection tools — Drata, Vanta, SecureFrame — monitor your infrastructure continuously and collect evidence on your behalf.
Deploy one of these tools before the observation period starts. The earlier you deploy, the longer the evidence collection period, and the stronger your Type 2 case.
The tools differ in focus: Vanta is developer-friendly with strong AWS/GCP integration; Drata has more robust workflow automation for compliance operations; SecureFrame offers deeper customization for non-standard environments. For most AI SaaS companies on AWS or GCP, Vanta or Drata is the right starting point.
The Type 1 to Type 2 Transition
Type 1 is the beginning, not the destination. An unqualified Type 1 report tells enterprise buyers your controls are designed correctly as of audit day. Type 2 tells them those controls have been operating correctly for the past year.
The transition isn’t automatic. The observation period that leads to Type 2 starts running as soon as your controls are in place. Every gap in the evidence record — a period where logging was down, a credential rotation that was late, an access review that was skipped — shows up in the Type 2 report.
The implication: Type 1 is the moment to fix your processes, not to declare victory. The observation period immediately follows, and the evidence collector sees everything.
Get the architecture right before the observation period starts. The SOC 2 path is entirely manageable with the right foundation. The companies that struggle are the ones who try to build the foundation after the observation period has already begun.
FINdustries builds the Sofia AI platform for wealth management and financial advisory. We’re on the SOC 2 Type 1 path, and the content in this post comes directly from our own gap assessment and compliance work. If you’re on the same path and want to compare notes, we’d like to talk.
