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

Type I attests that controls are designed appropriately at a point in time. Type II attests that controls operated effectively over a defined period — typically six to twelve months. Enterprise buyers generally want Type II; Type I is sometimes accepted as an interim signal when a company is newly building its program. The evidence burden is substantially higher for Type II because auditors sample actual operational activity over the period, not just the control design.

How much evidence does a SOC 2 Type II audit actually require?

For a 12-month audit window across five Trust Services Criteria, expect the auditor to sample thirty to fifty distinct control operations, each requiring two to ten evidence items. The volume is manageable when your control operations produce evidence as a byproduct (access review exports, ticket closure logs, config snapshots) and unmanageable when evidence is reconstructed at audit time. Evidence-as-byproduct is the single biggest determinant of audit cost.

What are the Trust Services Criteria?

Five criteria defined by the AICPA: Security (required on every audit), Availability, Confidentiality, Processing Integrity, and Privacy. Most SaaS companies audit against Security + Availability + Confidentiality, which covers the majority of enterprise-buyer contract requirements. Adding Privacy is typical for companies handling personal data; Processing Integrity is specific to companies whose product output correctness matters legally (financial systems, healthcare, eDiscovery).

Can I use a SOC 2 compliance platform (Vanta, Drata, Secureframe) instead of hiring an advisory firm?

The platforms handle evidence collection and auditor coordination well. They do not handle control design, architecture decisions, gap remediation, or the judgment calls about what evidence is actually sufficient for a given auditor's sampling approach. For a simple SaaS with a clean architecture and a cooperative auditor, the platform is often enough. For anything more complex — multi-region deployments, regulated data, frequent architecture changes, or atypical control environments — the platform produces evidence that needs a human to interpret before submission.

SOC 2 Type II: Evidence Patterns That Pass

The difference between a clean SOC 2 Type II audit and a painful one is almost never about controls. By the time a company reaches the observation window, the controls are in place — multi-factor authentication is on, access reviews happen, change management exists, vendor assessments have been run. What separates the two is whether the evidence is produced operationally or reconstructed retrospectively.

Reconstructive evidence is expensive. Screenshots with timestamps that are two days old. Access review spreadsheets assembled from HR exports and ad-hoc tickets. Incident response narratives written four months after the event. Auditors can tell. The SOC 2 report quality suffers, the timeline stretches, and every future observation window begins with the same scramble.

This article is the evidence pattern we teach clients before they enter the observation window. It is the difference between a SOC 2 program that runs itself and one that becomes a second full-time job for your security team every twelve months.

The evidence-as-byproduct principle

An auditable control has three components: a documented policy, a technical enforcement that executes the policy, and a record of the enforcement operating. The third is where most programs fail. The technical enforcement runs; the record gets lost.

The fix is designing the operational step so that running it produces the record without additional effort. If you have to run a separate task to generate the evidence of a control, the evidence will eventually lag or vanish. If the control fires and the evidence is a side effect, you will not lose it.

The practical examples below illustrate the pattern for the controls auditors drill hardest: logical access, change management, incident response, and vendor oversight.

Logical access: the system of record owns the evidence

Auditors will ask for evidence of three things during the observation window: user provisioning (new employees got the right access), user de-provisioning (terminated employees lost access promptly), and periodic access review (someone checked whether current access was still appropriate).

The reconstructive approach: pull HR reports for new hires and terminations, pull a list of accounts from each system, compare, write a narrative. This produces a technically acceptable but fragile artifact that falls apart at scale.

The byproduct approach: use an identity provider that generates the records as a consequence of doing the work.

For provisioning, configure your IdP (Okta, Azure AD, JumpCloud, etc.) so that every access grant is tied to a workflow with an approver, a requester, and a timestamp. When a new hire joins, the workflow produces an audit log entry per access granted. The auditor request becomes “export all provisioning events in the observation window from the IdP” — one report, complete.

For de-provisioning, integrate your HR system with the IdP so that termination triggers automated offboarding. The IdP logs the deactivation events. Auditor request: “export all deactivation events within X hours of termination date.” Clean.

For access reviews, use the IdP’s native access-review feature or a tool like Veza, SailPoint, or ConductorOne. Run reviews quarterly on a scheduled cadence. The tool produces the review artifact automatically — reviewer, reviewee, decision, timestamp. Auditor asks for the Q2 access review; you export it.

The investment is a one-time tool selection and configuration. The ongoing effort per review is minimal. The evidence is comprehensive.

Change management: the code review is the evidence

For software companies, the change management control is almost always a source code control system plus a deployment pipeline. SOC 2 expects that production changes have been reviewed and approved by someone other than the author. GitHub, GitLab, and Bitbucket all natively support this through branch protection and required reviews on pull requests.

The evidence exists automatically. Every merged PR shows the author, the reviewer, the approval timestamp, the commit diff, and (if configured) the automated check results. Export the PR list from your version control system for the observation window and it is the evidence.

The failure modes are operational. A branch protection rule that allows “administrators bypass” is a finding — the auditor will ask whether any administrator merged a PR without review during the observation window. If yes, that is either a non-conformity or a compensating-control exception that needs a documented rationale.

The other failure mode is “emergency changes” that bypass the normal flow. These need their own documented process: a ticket is opened, post-hoc peer review happens, and the event is logged. Most companies use an incident runbook that includes the post-event review step. Auditors look for evidence that the post-event review actually happened — not just that it was supposed to happen.

Incident response: the ticketing system is the evidence

An auditor reviewing CC7 (System Operations) and CC9 (Risk Mitigation) will ask three things about your incident response: do you have an IR plan, have you tested it, and have you handled any actual incidents during the observation window according to the plan.

The IR plan document satisfies the first. An annual tabletop exercise — documented with a date, participants, scenario, findings, and remediation items — satisfies the second. The third is where reconstruction fails.

The byproduct approach: every incident, however small, gets a ticket in your incident management system (PagerDuty, Opsgenie, Jira Service Management). The ticket captures the detection event, the responders, the timeline, the root cause, and the remediation. The IR runbook references this exact ticket structure.

At audit time, you export the incident tickets from the observation window. Each one demonstrates the IR plan in action. The auditor spot-checks a handful; if each follows the plan, the control is operating.

The failure mode is informal incident handling — Slack threads, hallway conversations, “we got paged at 2am and fixed it.” These are real incidents that produce no audit trail. The fix is a cultural one: every page-worthy event becomes a ticket, even if the ticket is short. Team discipline is the evidence mechanism.

Vendor oversight: a vendor database with assigned reviewers

For CC9 (Risk Mitigation) and any Privacy/Confidentiality criteria, auditors expect documentation that critical vendors are assessed and monitored. The classic reconstructive failure is a vendor list pulled from expense reports, with security questionnaires assembled at the last minute by someone calling around to find the latest SOC 2 report.

The byproduct approach is a simple vendor database with an assigned reviewer per vendor, a documented review cadence, and an annual refresh trigger. Each vendor entry stores: vendor name, data categories shared, reviewer, last review date, next review date, and links to current SOC 2 or ISO 27001 reports.

The tool does not matter — Notion, Airtable, a dedicated GRC platform, or a spreadsheet all work. The discipline is the cadence. When a vendor is added, the reviewer is assigned and the first review date is set. When the review date arrives, the reviewer receives a notification, completes the review, and logs the outcome.

At audit time, export the vendor list filtered to critical vendors. Each entry has a review history. The auditor spot-checks — the entries show annual reviews happening on schedule. Done.

Evidence organization: the folder structure auditors prefer

For the observation window, create a single evidence repository organized by Trust Services Criterion. Inside each TSC, organize by control. Inside each control, store the artifacts.

soc2-evidence-2026/
├── CC1 Control Environment/
│   ├── CC1.1 Integrity/
│   ├── CC1.4 Competence/
│   └── ...
├── CC2 Communication/
├── CC3 Risk Assessment/
├── CC4 Monitoring/
├── CC5 Control Activities/
├── CC6 Logical & Physical Access/
│   ├── CC6.1 Logical Access/
│   │   ├── access-reviews-q1-q4.xlsx
│   │   ├── provisioning-events-export.csv
│   │   └── deprovisioning-events-export.csv
│   ├── CC6.2 User Registration/
│   └── ...
├── CC7 System Operations/
├── CC8 Change Management/
└── CC9 Risk Mitigation/

Auditors arriving to review the package can navigate by control without orientation. The narrative section of the SOC 2 report references the same structure. This single choice saves days of back-and-forth during fieldwork.

The ongoing operating rhythm

A SOC 2 program that produces clean Type II reports runs on a monthly cadence. Roughly:

First week of month: pull access-review deltas, run any scheduled reviews, log to evidence folder.
Second week: vulnerability scan review, POA&M update, any critical patches.
Third week: vendor review touch-points if scheduled; confirm vendor database up to date.
Fourth week: any monthly management review, incident retrospective, policy review items.

If this cadence is running, the Type II observation window is not a project — it is a continuation of normal operations. The audit becomes a packaging exercise.

What to tell engineering

The evidence-as-byproduct principle is an engineering principle more than a compliance principle. When engineering teams design systems with auditable operations built in, SOC 2 stops being a burden on engineering velocity. The signal to send: audit evidence is a first-class output of every operational system. If we cannot prove it happened, it effectively did not.

Teams that internalize this ship faster with better controls than teams that add compliance as an afterthought.

This evidence-pipeline approach is the heart of our SOC 2 practice. If you are comparing SOC 2 to ISO 27001 or running both, the ISO 27001 practice shares substantial control overlap — particularly in Annex A’s Technological theme.

SOC 2 Type II: evidence patterns that survive the observation window