SOC 2 SOP Requirements: Documentation for a Type 2 Audit

If you're a SaaS team that has started fielding "Do you have a SOC 2 report?" from prospects, you already know the scramble. The question isn't really about one report — it's about whether your controls are designed, documented, and demonstrably operating over time. That documentation is what this guide maps, because the difference between a report that passes and a report that hurts is almost always in the operating procedures and evidence behind each control.

Unlike a prescriptive framework like ISO 27001, SOC 2 is built around five Trust Service Criteria (TSC) — Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most companies pursue only Security (plus a bit of Availability), which is the cheapest path. But no matter which criteria you include, the mechanics are the same: you design controls, write them down, and then prove, over a period of time, that they actually ran.

Type 1 vs Type 2: What the Auditor Actually Looks For

Understanding the two report types tells you how much documentation you need and when you need evidence:

• Type 1 — designs and suitability of controls as of a point in time. You document that a control exists (e.g., access reviews happen), but you don't yet have to prove months of consistent operation.
• Type 2 — operating effectiveness over a period (typically 3–12 months). The auditor samples evidence across the full window: completed reviews, logs, approvals, training records.

A common, smart route is to build the control and write the SOP for the regulated-industry controls first, get a Type 1 to close the sales-loophole moment, then run for the Type 2 period collecting evidence. The documentation itself is the same in both cases — what changes is the evidence standard.

The Policies and Procedures SOC 2 Expects

There is no fixed "SOC 2 must-have document list," because the scope depends on your systems and the TSC you select. But in practice, virtually every Security-and-Availability SOC 2 program lands on a core set of policies (the "what") and operating procedures (the "how"), which in effect are your standard operating procedures:

• Information security policy — the top-level statement of intent and management commitment.
• Access control policy and procedure — how access is requested, granted, reviewed, and revoked. This is one of the most heavily sampled controls.
• Change management procedure — how code, config, and infrastructure changes are approved, tested, and deployed.
• Incident management procedure — how security incidents are detected, escalated, contained, and reviewed.
• Risk assessment procedure — how you identify, evaluate, and treat risks.
• Backup and availability procedure — how data is backed up, restoration is tested, and uptime is maintained.
• Vendor/third-party management — how subprocessors are evaluated and monitored.
• Employee on/off-boarding — how accounts are created and disabled, tied to access control.
• Security awareness training — the training program and its records.

Notice the pattern: SOC 2 is less interested in the policy page and far more interested in the operating procedure that a human (or an automated agent) actually follows. That step-level detail is precisely what the hidden cost of manual SOPs exposes — teams can describe an idealized process but struggle to capture the real clicks, real approvals, and real hand-offs.

Where the Evidence Comes From

For a Type 2, the auditor doesn't re-test your controls from scratch. They sample the evidence you retained across the audit period. The evidence categories you'll need to reproduce on demand include:

• Access review records — completed quarterly reviews of who has access to what.
• Change tickets — records of approvals, peer reviews, and post-deploy testing.
• Incident and vulnerability logs — whether you closed things within your stated SLAs.
• Training completion records — who completed security training and when.
• Backup and restore logs — backups ran on schedule and at least one restore test succeeded.
• On/off-boarding records — accounts requested, approved, and disabled in time.

This is where your compliance log retention matters. If you keep the evidence but can't find it, or you define retention that deletes the proof before the audit window closes, the control may as well not exist in the auditor's eyes. Retention and review cycles are the difference between "we do this" and "we can show you we did this." Tie those cycles to real SOP version control so every procedure has a current version, an owner, and a review date.

Privacy-First Recording for Sensitive Controls

There's a subtle tension in SOC 2 documentation: the most important controls to document (access reviews, incident response, change approval) are also the most sensitive to describe. If you write the procedure in a cloud tool, you're now storing a precise description of your critical security controls on a third-party server — often a third party that hasn't passed your own SOC 2 review. The confidentiality criterion makes you think hard about this.

A local-first recorder sidesteps the exposure entirely. The recording and the exported procedure stay on your device, encrypted, until you decide otherwise — which keeps the sensitive part of your SOC 2 evidence inside your own perimeter while still producing step-accurate documentation. It also makes the documentation dramatically faster to produce and keep current, which is the difference between a report that reflects your systems and one that reflects an outdated description.

A Practical Build Sequence for a Security TSC

1. Define scope — systems, people, and process in scope for the Security criterion (add Availability if cheap).
2. Map controls to the TSC — list each Common Criteria control area and the control that addresses it.
3. Write the policy and the operating procedure for each, capturing the real steps rather than an idealized flow.
4. Define retention and review cadence so every control has evidence you can reproduce on demand.
5. Run the control, collect evidence — access reviews, change tickets, training logs, backups.
6. Do a gap mock-audit before engaging the CPA firm, so the paid audit finds nothing embarrassing.

Many teams use automated workflow capture to close the gap between the documented procedure and the real one — if the recorded steps don't match what people actually do, that's the signal your build sequence needs to fix.

FAQ