SOC 2 Compliance for SaaS — What to Build Into Your Software

SOC 2 compliance for SaaS requires building five Trust Services Criteria into your software architecture: Security (logical access controls, network firewalls, intrusion detection, MFA for all admin access), Availability (uptime monitoring, disaster recovery with documented RPO/RTO, incident response procedures), Processing Integrity (input validation, error handling, data reconciliation), Confidentiality (encryption at rest and in transit, data classification, retention policies), and Privacy (consent management, data subject access requests, deletion capabilities).

Most SaaS teams treat SOC 2 as a compliance project — something to handle six months before an enterprise prospect asks for the report. That approach costs 2-4x more than building the controls into the architecture from the start. The engineering decisions you make in the first three months of development determine whether SOC 2 compliance takes weeks or months when the audit arrives.

This guide covers what each Trust Services Criteria requires at the code level, the difference between Type I and Type II audits, what auditors actually check, the most common failures, and realistic cost and timeline expectations for SaaS products in 2026.

What does SOC 2 require for SaaS applications?

SOC 2 is an auditing standard developed by the AICPA (American Institute of Certified Public Accountants) that evaluates how a service organization manages customer data. For SaaS companies, it is the most common compliance requirement enterprise buyers demand before signing contracts above $50K ARR.

The standard is built around five Trust Services Criteria. Security is mandatory for every SOC 2 audit. The remaining four — Availability, Processing Integrity, Confidentiality, and Privacy — are included based on what the SaaS product does and what customers expect. A typical B2B SaaS product includes Security, Availability, and Confidentiality. Products that process financial transactions or PII typically add Processing Integrity and Privacy.

The table below maps each criterion to specific implementation requirements and what auditors verify during the assessment.

What's the difference between SOC 2 Type I and Type II?

Type I evaluates whether controls are designed correctly at a single point in time. Type II evaluates whether those controls operated effectively over a period — typically 6 or 12 months. The distinction matters because enterprise buyers almost universally require Type II. A Type I report says "the locks are installed." A Type II report says "the locks were installed, and we verified they stayed locked for the past year."

The practical path for most SaaS companies: get Type I within 3-4 months of deciding to pursue SOC 2, then immediately begin the Type II observation period. Use the Type I report to unblock pending enterprise deals while the Type II audit runs in the background.

What technical controls does SOC 2 mandate?

SOC 2 does not prescribe specific technologies. It defines control objectives — the outcomes your system must achieve — and your auditor evaluates whether your implementation satisfies them. This is different from PCI DSS, which prescribes exact technical requirements. SOC 2 gives you flexibility in how you meet each objective, which means the engineering decisions matter more, not less.

The controls that matter most for SaaS applications fall into seven categories:

Access control. Every user action must be authenticated and authorized. Implement RBAC (role-based access control) with least-privilege defaults — new roles get zero permissions and are granted access explicitly. Admin and production environment access requires MFA with no exceptions. Session tokens expire after inactivity (30 minutes is standard). Every authentication event — success and failure — is logged with timestamp, user ID, IP address, and action attempted.

Audit logging. Every data mutation (create, update, delete) must produce an immutable audit record. The log must capture who did what, when, to which record, and what the previous value was. Store audit logs in a separate data store that application-level users cannot modify or delete. Retain logs for the audit period plus one year minimum. This is the single control that generates the most evidence requests during an audit.

Encryption. TLS 1.2 or higher on every connection — enforce via HSTS headers with a minimum one-year max-age. Encrypt data at rest using AES-256 with keys managed through a cloud KMS (AWS KMS, GCP Cloud KMS, or Azure Key Vault) — never store encryption keys in application code or environment variables. Rotate keys annually at minimum.

Change management. Every production deployment must be traceable from code commit to release. This means pull request reviews (at least one reviewer who did not write the code), CI/CD pipelines with automated tests, and deployment logs that record what was deployed, when, and by whom. No direct production database modifications without a documented change request.

Vulnerability management. Run automated dependency scanning (Snyk, Dependabot, or equivalent) on every build. Conduct annual penetration testing by a qualified third party. Remediate critical vulnerabilities within 72 hours and high-severity within 30 days. Maintain a vulnerability register that tracks discovery date, severity, remediation status, and closure date.

Incident response. Document a response plan before you need it. The plan must define severity levels, escalation paths, communication templates, and post-incident review procedures. When an incident occurs, the response must be documented: when it was detected, who responded, what actions were taken, when it was resolved, and what was done to prevent recurrence. Auditors pull incident records and check response times against your documented SLAs.

Backup and recovery. Automated backups with documented RPO (Recovery Point Objective) and RTO (Recovery Time Objective) targets. Test backup restoration at least quarterly — an untested backup is not a backup. Store backups in a separate region from production. Document the restoration procedure step by step, and verify that someone other than the person who wrote it can execute it.

How long does SOC 2 compliance take for a SaaS product?

For a SaaS product built without compliance in mind, expect 4-9 months from decision to Type I report, and 12-18 months to Type II. For a product that builds controls into the architecture from the start, Type I can be ready within 6-8 weeks of engaging the auditor, and Type II within 9-12 months total.

The timeline breaks into three phases:

1. Readiness assessment and gap remediation (4-16 weeks). Identify which controls exist, which are missing, and which need modification. Write or update policies. Implement missing technical controls. This is where most of the engineering time goes — and where building compliance in from the start saves months.
2. Type I audit (4-6 weeks). The auditor examines your controls at a point in time. If gaps are found, they issue exceptions. Fix the exceptions, and the report is issued. Most SaaS companies pass Type I with minor exceptions on documentation rather than technical controls.
3. Type II observation period + audit (6-12 months + 4-8 weeks). Controls must operate effectively for the observation period. The auditor samples evidence throughout — pulling access logs, change records, incident reports, and backup test results. The final audit tests a representative sample of the entire period.

The biggest variable is phase one. A 50,000-line SaaS codebase with no audit logging, no RBAC, and no documented change management process needs 12-16 weeks of engineering work before the auditor even starts. A codebase that ships with audit logging on every model, RBAC from day one, and CI/CD with enforced code review needs 2-4 weeks to prepare policy documents and schedule the audit.

How much does SOC 2 compliance cost for SaaS?

Total cost breaks into three categories: audit fees, tooling, and engineering time. Audit fees are the most visible but least significant cost. Engineering time to retrofit controls into an existing codebase is where budgets go wrong.

Audit fees run $20K-$50K for Type I and $30K-$100K for Type II, depending on scope (number of Trust Services Criteria included) and company size. A SaaS company with 20 employees and Security + Availability typically pays $25K-$40K for Type I and $40K-$60K for Type II. Adding Processing Integrity or Privacy increases fees by $5K-$15K each.

Compliance automation tooling (Vanta, Drata, Secureframe, or similar) costs $10K-$30K per year. These platforms automate evidence collection, monitor control effectiveness continuously, and prepare the evidence packages auditors request. They cut internal compliance labor by 60-70% compared to managing evidence collection manually via spreadsheets.

Engineering time is the cost most teams underestimate. Retrofitting SOC 2 controls into a 50,000-line SaaS codebase — adding audit logging to every model, implementing RBAC where none exists, adding encryption at rest, building DSAR workflows, setting up automated vulnerability scanning — takes 3-6 months of dedicated engineering time. At $150/hour fully loaded, that is $40K-$80K in engineering cost alone. Building these controls in from sprint one adds roughly 10-15% to the initial development cost, but eliminates the retrofit entirely.

Total first-year cost for a mid-size SaaS company: $80K-$180K if retrofitting, $50K-$100K if compliance was built into the architecture from the start. The delta — $30K-$80K — is the cost of treating compliance as an afterthought.

What are the most common SOC 2 audit failures?

SOC 2 audits do not pass or fail in the binary sense — the auditor issues a report with or without exceptions (qualified opinions on specific controls). But exceptions delay enterprise deals and erode buyer confidence. These are the five exceptions we see most frequently in SaaS audits:

Incomplete audit logging. The application logs authentication events but not data mutations. Or it logs creates and updates but not deletes. Or the logs exist but are stored in the same database the application uses, meaning an admin could theoretically modify them. The fix: audit logs must cover every data mutation, be stored immutably (append-only data store or separate write-once bucket), and be retained for the full audit period.

Missing access reviews. SOC 2 requires periodic review of who has access to what — quarterly at minimum. The auditor asks for evidence that someone reviewed the access list and confirmed it was still appropriate. Most SaaS teams never do this because access is managed in code (environment variables, IAM policies) and no one thinks to review it formally. The fix: schedule quarterly access reviews, document them, and keep the records.

Untested backups. Backups run automatically every night, but no one has ever tested whether a restore actually works. The auditor asks for evidence of restoration testing. "We've never needed to restore" is not acceptable evidence. The fix: test backup restoration quarterly, document the results (what was restored, how long it took, whether data integrity was verified), and keep the records.

No documented incident response plan. The team handles incidents well in practice — Slack channel, fast response, root cause analysis. But nothing is written down. The auditor needs a documented plan with defined severity levels, escalation procedures, and communication templates. The fix: write the plan before the audit. It does not need to be complex — a 3-5 page document covering severity classification, response procedures, communication templates, and post-incident review process is sufficient.

MFA gaps. MFA is enforced for the application but not for cloud infrastructure access, CI/CD pipelines, or third-party tools that access production data. One unprotected access point creates an exception. The fix: enforce MFA on every system that can access production data or production infrastructure, with no exceptions for "developer convenience."

Every one of these failures is cheaper to prevent than to remediate. The audit logging architecture that takes two days to build correctly at the start of a project takes two months to retrofit into 80 models with existing production data. Access reviews that take 30 minutes per quarter when established early become a multi-day project when deferred until audit preparation.

We build SOC 2 controls into the software architecture from sprint one — not retrofitted before the audit. The difference: retrofitting a 50,000-line SaaS codebase for SOC 2 takes 3-6 months and costs $40K-$80K in engineering time alone. Building it in from the start adds 10-15% to the initial build cost but saves the retrofit entirely. The SaaS development engagements we run include audit logging, RBAC, encryption, and change management controls as standard infrastructure — the same way we include CI/CD and automated testing. Compliance is not a feature you add later. It is an engineering decision you make on day one.