SOC 2 Type II Compliance Checklist for SaaS Companies: 2026 Audit Guide

SOC 2 Type II is now a baseline procurement requirement for SaaS companies selling to enterprise buyers, and this SOC 2 Type II checklist covers everything your team needs to prepare: Trust Service Criteria selection, pre-audit control design, observation period evidence collection, and the most common audit findings that cause qualified reports. The AICPA (American Institute of Certified Public Accountants — the standards body that publishes the SOC 2 framework) evaluates whether your security controls operated effectively over a sustained observation period, not just whether they are documented on paper. Without a current Type II report, enterprise deals stall at the security review stage and procurement teams demand questionnaire responses that a valid report would replace entirely.

// 01 SOC 2 Type II Checklist for SaaS Companies: What the Audit Actually Covers

SOC 2 (System and Organization Controls 2) is an auditing framework that evaluates service organizations against five Trust Service Criteria (TSC) — the categories of controls an auditor tests. The five criteria are:

| TSC | Code | Required? | Relevant SaaS Scenario | |—|—|—|—| | Security | CC | Yes — always | Infrastructure hardening, access control, incident response | | Availability | A | Optional | SLAs, uptime guarantees, disaster recovery | | Processing Integrity | PI | Optional | Financial data processing, transaction accuracy | | Confidentiality | C | Optional | IP protection, B2B data handling | | Privacy | P | Optional | PII collection, GDPR/CCPA obligations |

Security is the only mandatory TSC. Most SaaS companies scope their first Type II audit to Security + Availability + Confidentiality. Adding Privacy is typically necessary only if you collect consumer personal data at scale or operate under GDPR (General Data Protection Regulation — the EU's primary data privacy law) or CCPA (California Consumer Privacy Act) compliance requirements.

SOC 2 Type I vs. Type II: The Difference That Matters

Understanding the Type I and Type II distinction is essential before you invest in either:

• Type I evaluates whether your controls are suitably designed at a single point in time. The auditor examines your policies, configurations, and documented processes as of a snapshot date. A Type I audit typically takes four to eight weeks from audit start and costs less than Type II — but it provides limited assurance to enterprise buyers because it does not prove that controls actually ran day to day.

• Type II evaluates whether your controls operated effectively throughout an observation period of at least three months, typically six to twelve. The auditor samples evidence from across the full period — access review records, log exports, change tickets, vendor assessments — to confirm that controls ran consistently, not just on the audit date. Enterprise security teams give meaningful weight only to Type II reports. Type I is an acceptable interim milestone for early-stage startups seeking a first foothold in procurement conversations.

The operational implication: you cannot start a Type II observation period until your controls are already running. Controls implemented after the observation start date produce no evidence for that period.

// 02 Phase 1: Pre-Audit Readiness Checklist (Months 1–3)

Before scheduling your observation period, every control below must be designed, implemented, and documented. Auditors note the exact date each control was placed in operation — retrofitting evidence after the fact is not possible.

Governance and Policy Controls

• [ ] Publish an Information Security Policy that documents your organisation's security commitment, defines roles and responsibilities, and sets an annual review schedule (maps to CC1.1 — the AICPA control category for Control Environment)
• [ ] Document a Risk Assessment Process: identify threats to your systems and customer data, estimate the likelihood and impact of each, and record your mitigation decisions in a risk register (CC3.1, CC3.2)
• [ ] Establish a Change Management Policy that defines who can approve changes to production systems, how changes are tested before deployment, and how rollbacks are handled (CC8.1)
• [ ] Write and approve an Incident Response Plan (IRP) with defined severity levels, escalation contacts, response SLAs, and a mandatory post-incident review process (CC7.3, CC7.4)
• [ ] Produce a Business Continuity and Disaster Recovery Plan (BCP/DRP) with documented RTOs (Recovery Time Objectives — the maximum acceptable downtime) and RPOs (Recovery Point Objectives — the maximum acceptable data loss window) if Availability is in your scope

Access Control (CC6 — the Highest-Finding Criteria)

CC6 and CC7 together account for 68% of exceptions in qualified SOC 2 reports. Prioritise these controls above all others:

• [ ] Implement a formal access provisioning workflow: every account creation must be initiated by a ticketed request with a named approver; no informal Slack-based provisioning
• [ ] Eliminate all shared admin and root accounts in production; every privileged identity must map to a named individual — shared accounts are an automatic finding
• [ ] Enforce MFA (Multi-Factor Authentication — requiring a second proof of identity beyond a password) on all production systems, cloud consoles, and identity providers; screenshot the policy configuration as evidence
• [ ] Document your RBAC (Role-Based Access Control) model with least-privilege principles — each role should have only the permissions needed for its function, documented and reviewed
• [ ] Schedule quarterly access reviews for all production systems; every review must produce a record containing the reviewer's name, the date, the full user list evaluated, and any access removed — access reviews performed once and never repeated are among the most cited Type II findings
• [ ] Implement automated account deprovisioning triggered on employee or contractor offboarding; if fully automated isn't possible, a documented manual checklist completed within 24 hours of departure is acceptable but harder to evidence at scale

Logging and Monitoring (CC7)

• [ ] Enable centralised logging for all production infrastructure: cloud trail logs (AWS CloudTrail, GCP Audit Logs, Azure Activity Log), application logs, and authentication logs routed to a single SIEM (Security Information and Event Management — a platform that aggregates and analyses security log data)
• [ ] Define and enforce log retention periods: 90 days minimum online, one year archived; document the retention policy explicitly
• [ ] Configure alerting for: failed authentication spikes, privilege escalation events, anomalous data access patterns, and unexpected infrastructure configuration changes
• [ ] Document the alert triage process: who receives each alert type, what the response SLA is, and where triage decisions are recorded — alerts with no triage record are a finding
• [ ] Deploy an IDS/IPS (Intrusion Detection/Prevention System — tools that watch network and host activity for known attack patterns and either alert or block) or equivalent threat detection tooling on production hosts

Vulnerability Management

• [ ] Run authenticated vulnerability scans against all production hosts at least monthly; export and store scan results with timestamps (a single undated scan report does not satisfy the auditor)
• [ ] Establish a patch SLA: Critical vulnerabilities (CVSS v3 score 9.0–10.0 — the highest severity tier in the Common Vulnerability Scoring System) applied within 15–30 days; High (7.0–8.9) within 60 days
• [ ] Maintain an open vulnerability risk register with assigned owner and target remediation date for every tracked finding

Vendor Risk Management

• [ ] Maintain a vendor inventory: every third party with access to your production environment or customer data must be listed, categorised by risk tier, and reviewed on a defined schedule
• [ ] Obtain and review SOC 2 reports or equivalent (ISO 27001, CSA STAR) for all Tier 1 vendors — those with direct access to customer data — at least annually; store the review record
• [ ] Execute DPAs (Data Processing Agreements) with all vendors that handle personal data; required for GDPR compliance and increasingly reviewed by SOC 2 auditors
• [ ] Maintain a documented vendor offboarding process with evidence that access is revoked when an engagement ends

// 03 Phase 2: Observation Period Evidence Checklist

The observation period is where Type II compliance is won or lost. Auditors sample evidence from across the full period — a six-month audit means they may pull records from month one, month three, and month five. Every control listed below must produce dated, attributable artefacts throughout the period, not just at the start.

Monthly Recurring Evidence

• [ ] Vulnerability scan reports with timestamps confirming scans ran on schedule (not a one-time baseline)
• [ ] Patch application records or change tickets closing known vulnerabilities, traceable to the open risk register
• [ ] Alert review logs: proof that security alerts were received, triaged by a named individual, and either resolved or formally risk-accepted
• [ ] Infrastructure configuration snapshots, particularly IAM (Identity and Access Management) policy exports, firewall rules, and security group change logs

Quarterly Recurring Evidence

• [ ] Access review records: exported user lists with system-level permissions, reviewer sign-off with date, and a record of any access removed as a result — this is the single most frequently requested evidence artefact in a Type II audit
• [ ] Security awareness training completion rates: 100% completion is required; even one employee who missed a training session is a finding; automate assignment for new hires and track via your LMS (Learning Management System)
• [ ] Penetration test or vulnerability assessment report (annual is the minimum; quarterly is preferred for Type II audit coverage)
• [ ] Vendor risk review records for all Tier 1 vendors: date reviewed, findings, any risk exceptions documented

Per-Incident Evidence

• [ ] Incident tickets for every security event regardless of severity: capture detection time, assigned responder, containment actions taken, and post-incident notes
• [ ] Change tickets for every production change: approver name, test evidence, rollback plan documented before deployment

// 04 Evidence Collection by Trust Service Criteria

| Control | TSC Code | Evidence Type | Typical Collection Method | |—|—|—|—| | Access provisioning | CC6.1 | Ticketed requests with named approver | ITSM export (Jira, ServiceNow, Linear) | | Quarterly access reviews | CC6.2 | Reviewer sign-offs with user lists | GRC platform screenshot or spreadsheet | | MFA enforcement | CC6.3 | IdP policy screenshots, login audit logs | Okta, Azure AD, or Google Workspace report | | No shared admin accounts | CC6.8 | IAM user export showing named individuals | AWS IAM, GCP IAM export | | Alert monitoring | CC7.1 | SIEM rule inventory + alert review logs | Splunk, Datadog, Elastic export | | Incident records | CC7.3 | Incident tickets with full timeline | ITSM or GRC export | | Change management | CC8.1 | Change tickets with approvals + test evidence | Git history + ticketing system | | Risk assessment | CC3.2 | Risk register with threat ratings + mitigations | GRC tool or spreadsheet | | Vulnerability scans | CC7.1 | Timestamped scan reports with CVE findings | Qualys, Tenable, AWS Inspector export | | Security training | CC1.4 | Completion certificates with employee names + dates | LMS export (Rippling, BambooHR, Workday) |

// 05 Common SOC 2 Type II Audit Findings — and How to Fix Them

The following findings appear repeatedly in qualified Type II reports. A qualified report — one that contains auditor exceptions — significantly weakens the report's value to enterprise buyers. These are preventable.

Finding 1: Access reviews performed once, not quarterly The team treats the initial access review as a one-time setup activity rather than an ongoing control. Auditors sample across the full observation period and flag any quarter with no review record. Fix: Assign a named control owner; put quarterly reviews in the calendar as a recurring event; store records in your GRC (Governance, Risk, and Compliance) platform so artefacts accumulate automatically without manual tracking.

Finding 2: Shared admin accounts in production Legacy root or admin accounts created before the compliance programme was established. These violate individual accountability — if a change is made under a shared account, there is no way to identify who made it. Fix: Audit all IAM users before your observation period begins; convert or delete every shared account; document that each privileged identity maps to a named individual with a business need on file.

Finding 3: Security training completions below 100% A single employee — a new hire who was missed in onboarding, a contractor not enrolled in the training system, a returning employee from parental leave — produces an exception. Fix: Automate training assignment in your HRIS (Human Resources Information System) to trigger on day one of employment or contract start; run weekly completion reports and chase non-completers before the quarter closes.

Finding 4: Vendor risk management done informally Vendor relationships managed via email or institutional memory, with no documented review records. In 2026, auditors increasingly require continuous monitoring and formal risk scoring for third-party vendors, not just a one-time onboarding review. Fix: Build vendor risk assessments into your vendor onboarding checklist; use your GRC platform's vendor management module or a dedicated tool like ProcessUnity or Whistic; schedule calendar reminders for annual Tier 1 re-reviews.

Finding 5: Incident response plan exists but was never tested The IRP was written to satisfy the policy requirement and has never been exercised. Type II auditors look for tabletop exercise records or real incident tickets. Fix: Run a tabletop exercise — a structured walkthrough of a simulated incident scenario — during your pre-observation phase and document it formally; treat every real security event, even low-severity, as an evidence opportunity by opening a formal incident ticket.

Finding 6: Log continuity gaps mid-observation period A cloud resource spun up without logging enabled, or a logging agent disabled during an infrastructure change, creates a gap that auditors detect when they sample logs across the full period. Fix: Enforce logging configuration at the infrastructure-as-code layer using policy-as-code tools (Open Policy Agent, AWS Config rules, Terraform Sentinel); use SCPs (Service Control Policies — AWS organisational guardrails that prevent resources from being created without required configurations) to block unlogged resources from being deployed.

Finding 7: Missing evidence for off-boarded employee accounts Access was removed, but no ticket or record exists to prove it happened within the required window. Fix: Every offboarding must produce a ticket that lists each system access removed, the date removed, and the person who actioned it; automate where possible using your IdP's SCIM (System for Cross-domain Identity Management — a protocol for automatically provisioning and deprovisioning user accounts) integration.

// 06 Compliance Automation Tooling: Vanta, Drata, and Alternatives

Manual evidence collection — screenshots, spreadsheet exports, calendar reminders — does not scale past a first audit and introduces the human error that produces the findings above. Compliance automation platforms connect to your cloud infrastructure, identity providers, endpoint management tools, and CI/CD pipelines to pull evidence automatically and map it to TSC controls in real time.

Vanta — 375+ integrations, 1,200+ automated control tests running hourly. Optimised for speed-to-audit-readiness and has broad auditor familiarity among CPA firms that specialise in SaaS audits. The onboarding flow is designed to get teams from zero to audit-ready as quickly as possible. Best fit for startups that want the fastest path to a first Type II report.

Drata — 250+ integrations, daily automated testing, cross-mapped evidence for over 20 frameworks simultaneously (SOC 2, ISO 27001, HIPAA, PCI-DSS, GDPR). Provides a built-in auditor access portal that eliminates the back-and-forth of evidence sharing. Best fit for engineering-heavy teams that want control depth and need to satisfy multiple compliance frameworks from a single evidence base.

Secureframe — Strong policy template library and a large pre-built control set. Competitive pricing for growing teams; popular for first SOC 2 audits with limited compliance staff.

Sprinto — Strong Jira and GitHub integrations; supports automated HR-driven access review workflows. Popular with Series A and B SaaS companies that have engineering-first cultures.

Key evaluation questions before selecting a platform:

• Does it integrate with your actual cloud provider (AWS, GCP, Azure) and cover the specific services you use?
• Does it cover your identity provider (Okta, Azure AD, Google Workspace) for automated access review evidence?
• Does it support your endpoint management tool (Jamf, Microsoft Intune) for device compliance evidence?
• Does it have a built-in auditor portal to avoid emailing evidence packages?
• Can it cross-map to ISO 27001, HIPAA, or PCI-DSS if you anticipate needing those frameworks within two years?

The 2026 market also includes platforms like Strac Comply that bundle evidence collection with active security controls — useful for teams that want to close control gaps and collect evidence in a single tool rather than two separate products.

// 07 SOC 2 Type II Audit Timeline and Cost Benchmarks

| Phase | Duration | Notes | |—|—|—| | Gap assessment | 2–4 weeks | Identify control gaps; prioritise remediation before observation start | | Control implementation | 6–10 weeks | Policies, tooling deployment, access review setup, training rollout | | Observation period | 3–12 months | Evidence accumulates; 6 months is the typical first-audit window | | Auditor fieldwork | 4–8 weeks | Auditor reviews sampled evidence, issues RFI (Request for Information) queries | | Report issuance | 1–2 weeks | Draft report, management response opportunity, final signed report |

Typical first-year costs for a SaaS company with 50–200 employees (sourced from Secureframe's 2026 cost analysis):

| Cost Category | Typical Range | |—|—| | Gap assessment and remediation | $20,000–$60,000 | | Compliance automation platform (annual) | $10,000–$30,000 | | Auditor fees | $20,000–$50,000 | | Total first-year | $60,000–$135,000 |

Renewal audits from year two onward are substantially less expensive: controls are already implemented, evidence accumulates automatically through your GRC platform, and auditor fees drop when the auditor already understands your environment.

// 08 Conclusion

SOC 2 Type II is not a documentation exercise — it is an operational commitment to running controls consistently across an entire audit period and proving it with evidence. The most common failures are not technically complex: access reviews done once and never repeated, shared admin accounts surviving from pre-compliance infrastructure, and vendor risk managed informally with no records. Teams that implement controls before the observation period begins, assign a named owner to every control, and automate evidence collection with Vanta, Drata, or Secureframe avoid the bulk of findings. A 12-month observation period means a decision made today yields a report by mid-2027 — start your gap assessment this quarter.

See our guide on zero-trust architecture and data movement controls for implementing the access segmentation your SOC 2 Type II access control section will require →

Related: understanding downstream vendor breach risk — directly relevant to the vendor risk management and third-party assessment controls in your SOC 2 programme →

Also see: vishing and SSO attacks targeting SaaS companies for the threat context behind the access control and MFA requirements in CC6 →