SOC 2 Type II Requirements: The Complete Control Checklist for SaaS

Most SaaS companies treat SOC 2 Type II as a checklist to survive. That is the wrong framing. Type II is proof that your security controls actually work over time, not just that someone designed them on paper. Enterprise buyers know the difference, and so do their security teams.

This guide breaks down every requirement by trust service criteria, covers the specific controls auditors test, and flags the findings that delay reports. If you are preparing for your first Type II or tightening up for a renewal, this is the reference you need. For the broader context on how SOC 2 fits into enterprise sales, start with the SOC 2 readiness guide.

Type I vs Type II: Why the Distinction Matters

Type I evaluates whether your controls are designed correctly at a single point in time. The auditor shows up, reviews your documentation, confirms that policies exist and controls are in place, and issues a report. It answers one question: did you build the right things?

Type II asks a harder question: did those controls actually operate effectively over a sustained period? The auditor examines evidence across your entire observation window, typically 3 to 12 months, and tests whether controls were consistently followed, not just written down.

The practical difference is significant. A Type I report tells a buyer you have policies. A Type II report tells them your team follows those policies every day, across months of operation. That is why enterprise procurement teams overwhelmingly prefer Type II. A Type I might get you through an initial gate, but for closing deals above six figures, Type II is the expectation. See our guide on how to pass procurement without slowing engineering for the full picture.

The Five Trust Service Criteria

SOC 2 is organized around five Trust Service Criteria (TSC) defined by the AICPA. You must include Security. The other four are optional based on your product, the data you process, and what your contracts require.

• Security (Common Criteria) — Required for every SOC 2 engagement. Covers access controls, system operations, change management, and risk mitigation. This is the baseline.
• Availability — Include this if you have SLA commitments or if uptime is critical to your customers. Covers monitoring, disaster recovery, and capacity planning.
• Processing Integrity — Relevant if you process transactions, calculations, or data transformations. Covers accuracy and completeness of system processing.
• Confidentiality — Required when you handle data classified as confidential under contracts or regulation. Covers encryption, access restrictions, and data lifecycle management.
• Privacy — Applies when you collect and process personal information from consumers. Covers notice, consent, use limitation, and data subject rights.

Most B2B SaaS companies start with Security plus Availability. Add Confidentiality if your contracts reference it. Processing Integrity and Privacy are less common for typical SaaS products but mandatory for fintech, healthtech, or consumer-facing platforms. For a deeper comparison of frameworks, see SOC 2 vs ISO 27001.

Security (CC1-CC9): The Required Baseline

The Common Criteria form the backbone of every SOC 2 report. Here is what each family covers and what auditors actually test.

CC1 — Control Environment. Governance structure, management oversight, board involvement, organizational accountability. Evidence includes org charts, job descriptions with security responsibilities, and board meeting minutes that reference security topics.

CC2 — Communication and Information. How you communicate security policies internally and externally. Auditors look for security awareness training records, policy acknowledgments, and documented communication channels for security incidents.

CC3 — Risk Assessment. Formal risk assessment processes, threat identification, and risk treatment decisions. You need a documented risk register that is reviewed and updated at least annually, with clear ownership for each identified risk.

CC4 — Monitoring Activities. Ongoing evaluation of controls, internal audits, and deficiency tracking. Evidence includes control testing results, management review meeting notes, and remediation tracking for identified gaps.

CC5 — Control Activities. Policies and procedures that support control objectives. This is where your information security policy, acceptable use policy, and operational procedures live. Auditors verify these are current, approved, and accessible.

CC6 — Logical and Physical Access Controls. User provisioning, access reviews, authentication mechanisms, and physical security. This is the most evidence-heavy category. Expect auditors to sample user access records, review MFA configurations, test role-based access controls, and verify quarterly access reviews were completed with documented decisions.

CC7 — System Operations. Monitoring infrastructure, incident detection, and incident response. Auditors want to see alerting configurations, incident response plans that have been tested, and evidence of actual incident handling including post-mortems.

CC8 — Change Management. How you manage changes to infrastructure, code, and configurations. Evidence includes change request records, approval workflows, testing documentation, and rollback procedures. Auditors will sample deployments and verify each followed the documented process.

CC9 — Risk Mitigation. How you address identified risks including vendor management and business continuity. This includes your vendor risk management process, business continuity plans, and insurance coverage documentation.

For a detailed breakdown of what evidence maps to each control family, see the SOC 2 evidence checklist.

Availability, Confidentiality, and Processing Integrity: When to Include

Adding criteria beyond Security increases audit scope, cost, and the evidence you need to produce. Only add what your customers and contracts require.

Availability is the most commonly added criterion. If you publish an SLA, your customers expect you to prove you can meet it. Controls include uptime monitoring, automated failover, disaster recovery testing, and capacity management. Auditors will review your incident history against SLA commitments and verify DR tests are conducted at least annually.

Confidentiality applies when contracts or regulations classify data you handle as confidential. Controls include data classification schemes, encryption at rest and in transit, access restrictions based on classification, and secure disposal procedures. Auditors test that data classified as confidential actually receives the protections your policies promise.

Processing Integrity matters when your system performs calculations, transformations, or transaction processing that your customers rely on for accuracy. Controls include input validation, reconciliation checks, error handling, and output verification. If you are a payments platform or analytics tool, this criterion is likely non-negotiable.

The Observation Period: How Long and What Happens

The observation period is the window during which your controls must operate effectively. For Type II, this period must be at least 3 months. First-time audits commonly use a 3 to 6 month window. Subsequent audits typically cover 12 months.

During the observation period, the auditor is not sitting in your office. Your team operates controls as documented, collects evidence continuously, and the auditor reviews that evidence at the end of the period. They will sample across the entire window, not just the beginning or end.

What auditors sample: user access reviews, change management records, incident response activities, vulnerability scan results, training completion records, vendor assessments, and backup verification logs. The sample size depends on population size and control frequency. Daily controls get larger samples than annual ones.

The critical rule: if a control was not operating for any portion of the observation period, the auditor must note it. Gaps in evidence are treated as control failures, even if the control was working but nobody documented it. Evidence collection is not optional. It is the audit.

Common Findings That Delay Reports

After working with dozens of SaaS companies through SOC 2 audits, these are the findings we see most often.

Incomplete access reviews. You ran quarterly reviews but did not document the decisions. Or you documented approvals but skipped termination verification. Auditors need evidence that reviewers examined each account, made a decision, and that inappropriate access was revoked within a defined timeframe.

Missing evidence timestamps. Screenshots without dates, policies without version history, training records without completion dates. Every piece of evidence needs a verifiable timestamp.

Unpatched systems. Vulnerability management policies promise patching within 30 days for critical vulnerabilities, but scan results show systems with 90-day-old critical patches. Auditors will flag the gap between your policy and actual performance.

Change management gaps. Emergency changes that bypassed the approval process without documented justification. Or changes that were approved but lacked evidence of testing before deployment.

Vendor risk gaps. Your vendor inventory is incomplete, risk assessments are outdated, or you cannot demonstrate that critical vendors were reviewed within the last 12 months.

Training records. Security awareness training was conducted but completion records do not cover all in-scope personnel, or new hires completed training outside the required onboarding window.

From Readiness to Report: The Typical Timeline

A realistic SOC 2 Type II timeline for a SaaS company looks like this:

Months 1-2: Readiness assessment. Gap analysis against the Trust Service Criteria you plan to include. Identify missing controls, incomplete documentation, and evidence collection gaps. This is where you decide scope and build your remediation plan.

Months 3-4: Remediation and implementation. Write or update policies, implement technical controls, configure monitoring, deploy a GRC platform, and begin evidence collection. Train your team on control execution and evidence requirements.

Months 5-7: Observation period begins. Controls must operate consistently from day one. Evidence collection runs continuously. Conduct an internal mock audit at the midpoint to catch issues before the auditor does.

Months 8-9: Auditor fieldwork. The auditor reviews evidence, conducts walkthroughs, performs sample testing, and identifies any exceptions. You respond to requests and remediate any findings that can be addressed within the period.

Month 10: Report issuance. The auditor drafts the report, you review management assertions, and the final SOC 2 Type II report is issued.

Total timeline from zero to report: roughly 10 months. Companies that have already completed Type I can compress this by starting the observation period immediately after the Type I report.

If you want to accelerate this process or need help identifying gaps before they become audit findings, CertifyOps handles the operational side of SOC 2 so your engineering team stays focused on product. Get in touch to scope a readiness assessment.