SOC 2 Playbook

Policies

Your platform generates ~21 policies from enterprise templates. They assume a security team, a change advisory board and an HR function you don't have. Replace them. Don't fill them in.

One real swap: 21 generated policies (~107 pages, ~26,600 words) → 17 lean ones (~40 pages, ~8,000 words). Same TSC coverage. Base was Tailscale's open set plus the three it lacks: Physical Security, Encryption, Acceptable Use.

One exception: name your source control. PRs are the change records, so naming GitHub makes the evidence path explicit. Keep incident tracking and log storage generic — "an issue tracker, document, or spreadsheet." Don't hand the auditor a hostage.

Fold in, don't write standalone

A standalone logging policy over-commits on retention, alert thresholds and SIEM tooling you can't evidence. A data-center Physical Security policy at a company with no data center becomes one paragraph: remote work, device security, cloud provider's responsibility.

The numbers to commit to

Skip the day-one acknowledgment theater. Behavioral policies (acceptable use, code of conduct, data classification, infosec) go to everyone at onboarding. Operational policies go to the roles that operate them, annually. Auditors accept the split when you state it.

Single reviewer? Don't write a rule you'll break weekly. Replace pre-deployment peer review with a self-review checklist in the change template (scope, blast radius, rollback, credential exposure, staging validation) plus a monthly batch review by another leader with sign-off recorded. Note that it applies until a second reviewer exists.

Evidence

Folders barely matter. The auditor consumes an index: one row per control — criterion, artifact, date, status. Build it as you go.

The whole artifact set

One 8-person company's entire operational layer: 12 documents (~5,300 words) and 7 spreadsheets.

• An index of every artifact and where it lives — itself an audit artifact
• Onboarding checklist — role drives access; MFA before anything else is granted
• Offboarding checklist — the longest one. Named-vendor walk, per-auth-method actions, API keys, device erasure, sign-off
• Incident response procedure, post-mortem template, tabletop template
• Backup recovery runbook with real commands
• Secure development practices — the absorbed SDLC content, labelled "not a policy"
• Vendor review questions — six at onboarding, four annually. That's the whole vendor program.
• Board roster and meeting cadence; a public security page

Register schemas

Map obligations to a calendar once

Split every policy obligation into recurring, event-triggered (~18 triggers: hiring, departure, lost device, KEV hit, emergency change, subprocessor change) and continuous. Setup is under an hour. Three calendar events cover an annual cadence: monthly security ops review, quarterly device patch check, annual review week.

Prefer controls that document themselves. A runbook can state "evidence lives in the systems themselves — no hand-kept log," then map each claim to its system of record: restore tests to CI history, secret changes to version history, who can restore to the IAM policy.

Vendors, Subservice Orgs & CUECs

CUECs run both ways

• Reading a vendor's report: the CUEC list is the vendor telling you which controls they did not implement for you. Their clean opinion is only valid if you do your half. Nobody reminds you.
• Writing yours: you publish a list telling customers what they own — their users, their API keys, their SSO config.

One flat sheet handles it: vendor, period, TSC, the CUEC text, your covering policy, status. One engagement logged 170 rows across nine vendors — 42 from the cloud provider, 4 from a single-purpose API vendor. Those 170 collapsed into 24 actions, and four cross-cutting ones covered most of the set. "Enforce MFA on every tenant" satisfies all nine by itself.

The obligations are the same everywhere

1. Enforce tenant MFA.
2. Provision, review and remove your own users, including admins. Federation is not deprovisioning.
3. Inventory and rotate non-human identities. Database users are a separate population from console users and have no MFA — that's the one nobody catches.
4. Turn on the logs. Cloud data-access logging is often off by default.
5. Alert on them yourself. The vendor records the event; detecting it is yours.
6. Set network posture per vendor: allowlist, private endpoint, or exposed.
7. Test your own restores. Managed backup is theirs; proving restore works is yours.
8. Keep an exit path: export, deletion, current contacts, their security escalation channel in your IR runbook.

Tier the depth. Full mapping for critical vendors; a couple of lines in the register for everyone else. Annual review reduces to "any new CUECs?"

Reading a vendor SOC 2

Collecting reports isn't the control. Reading them is. From nine of them:

• Periods often aren't 12 months. One covered Jan–Jun, another Apr–Sep. Get a bridge letter or the follow-on.
• You may be handed a SOC 3. The Type II is usually behind an NDA in the trust portal. Ask.
• "Emphasis of Matter" is normal — usually a control untested because no qualifying event occurred. Note that you read it.
• Assess exceptions against the service you consume. One report carried nine, none touching the identity service in use. That's a documented no-action, not a risk.
• You inherit their carve-out chain. Your model provider carves out its cloud host, warehouse and IdP. Decide how far down you follow and write down where you stopped.
• Check what the opinion covers. One major cloud provider's report excluded the performance and integrity of its AI services entirely, covering only underlying infrastructure.

Tier with two questions: if breached, would customer data be exposed? If down, would your product stop? Yes to either → critical (SOC 2 + CUEC mapping). Source code or internal data only → standard (report or questionnaire). Neither → light (confirm what it does, move on).

The Auditor Q&A Loop

Same three beats for every control. Most guides describe two.

1. "Provide one example of [control] operating on or before the audit date."
2. You: "No such event occurred; the control is designed and implemented."
3. "Provide documentation confirming that no [disposals / access changes / incidents] occurred as of [date]."

Beat three is the one nobody writes down. A null answer still needs an artifact. Every control needs a record showing it ran, or proof of the negative.

"Not yet due" vs "no instances"

Not interchangeable, and using the wrong one is checkable. "Not yet due" is a periodic control whose cycle hasn't arrived. "No instances" is an event-driven control where the event hasn't happened. Never claim "none" where instances occurred — a company that hired people has onboarding approvals.

For a cycle not yet due, five parts get accepted and four get returned:

1. The policy and section establishing it
2. What triggers it
3. Where the evidence will live
4. A statement that no qualifying event occurred
5. Cadence and a specific date

In practice: "The annual access review had not yet come due as of June 8, 2026. It is scheduled for August 31, 2026." Attach the calendar screenshot — that screenshot is the evidence. Say "newly implemented," never "we're a young company" — a year of hires on the books contradicts you.

Four things that get evidence rejected

• Acknowledgments that don't name policies. A "policies accepted" screenshot was rejected — it "does not clearly demonstrate acknowledgment of the company's security policies." The fix named all four and the date.
• Relabelling one control as another. Dependabot is SCA, CodeQL is SAST. Both scan code, not your running attack surface. Use them for "vulnerabilities identified and tracked to remediation" and close external scanning with a documented compensating-control decision.
• Claiming a control you don't run. No criminal background checks? Say so, name what you do (identity and work-authorization verification, reference checks, before access), and check your system description doesn't claim otherwise.
• A config screenshot where an event exists. Asked for IDS with no corporate network, the answer was cloud alert policies on IAM, firewall and service-account key changes — and an alert that had actually fired.

Ask for their evidence spreadsheet at kickoff. Good auditors keep a per-control list with separate Type I and Type II columns. It turns the audit into a checklist.

Auditors vary a lot in how hard they push. Read yours early, calibrate to the bar you measure, don't assume the next one shares it.

Two scheduling notes. Confirm your real stack before writing anything — policies drafted against an assumed identity provider cost more to unpick than they did to write. And auditors need roughly ten days of lead time to get you into their queue, so if the as-of date is going to move, move it early.

Your GRC Dashboard Is Not the Audit

Auditors evaluate controls, not your platform's score. One engagement started triage at 110 controls with 86 "Unhealthy" — 78% red — and got a clean unqualified report. Sorting all 98 failing tests:

Eight of 98 were real security problems. Nine-tenths of a red dashboard is paperwork and scope.

Archive out-of-scope TSC controls first, before remediating anything. Security-only doesn't cleanly deselect the others. Archiving reclassified ~31% of one control set in twenty minutes.

• Override — control level. Flips to healthy with your justification in the audit record. Doesn't silence the tests beneath.
• Disable test — for evidence of an event that didn't occur or doesn't apply.
• Mark N/A — same effect; label varies by build.

Decision rule: if the config can change, fix it. If not, justify with compensating controls. Otherwise disable.

Good override text names the mechanism and cites the policy: "Production infrastructure managed as Terraform IaC in GitHub, reviewed through branch-protected PRs per Change Management Policy." Overrides also defend a lean policy set against a platform demanding one policy per topic.

Then stop optimizing the number.

Two gotchas: federated MFA often reads as failing because the platform can't see through federation. And the platform can't see systems it doesn't integrate with, so your access review population is assembled by hand.

Reviewing the Draft Report

You get a draft before signature. Read it twice.

Pass one — defects worth sending back

• Type II language in a Type I. The highest-value catch. A "Results of Service Auditor Test of Controls" column, testing "throughout the period [single date]," notes reading "no events to test during the review period." These contradict the opinion's own statement that no operating-effectiveness procedures were performed — and make a new program look like a year in which controls never fired.
• Subservice orgs missing where data lives. Carve-out names only the cloud host while your description puts credentials elsewhere. Real scoping defect, not optics.
• Controls the narrative promises that the matrix omits. MFA and encryption-at-rest go missing surprisingly often. A reviewer spots a missing MFA control in thirty seconds.
• Filler mappings. One "commitment to integrity" control reused across three criteria. For a founder-run company, say the founders perform board oversight and describe the real cadence.
• Your own overclaiming. The description is yours to fix. If compute is per-customer but the data layer is shared with tenant scoping, don't say "single-tenant" — that's the first thing a technical buyer probes.

Pass two — read it as your buyer will

They discount predictably: when is the Type II and for what period, why Security only, what governs the data stores you left out, what does "single-tenant" actually mean, where's the penetration test. Have answers before the report ships.

Two asks while the draft is open: get the Type II timeline in writing so you can quote it, and agree the bridge-letter plan.

The 60-90 Days Before Type II

Type II is where exceptions appear. The auditor defines populations — every termination, every production change, every hire — samples ~25 of each, and wants evidence the control fired every time.

You cannot retroactively fix an operating-effectiveness miss. You can backfill documentation for a control that ran. You cannot create a review that never happened.

Fix before the clock starts, in order:

1. Automate deprovisioning (HRIS/SCIM → IdP). Removes the single most common exception.
2. Access reviews scheduled and documented with dated, signed sign-offs.
3. MFA enforced, not advisory.
4. Change management locked to branch protection and reviewed PRs, plus a written emergency-change procedure.
5. Vendor inventory with current SOC 2s on file.
6. Annual risk assessment signed by leadership.
7. A tabletop with written notes.
8. Training and screening records complete.

Manual, memory-dependent controls fail. Controls that produce evidence as a side effect of normal work — a merged PR, a CI run, an alert that fired — don't.

Expect scope expansion. If your product sits in the runtime path of customer data, buyers will want Confidentiality and probably Availability — plus a scoped penetration test, formal secrets management, EDR beyond built-in AV, and a redaction policy for whatever reaches your analytics stores and model providers.

← Back to the guide

Need help?

We do readiness assessments, AI red teaming, app penetration testing, and general "am I doing this right" support for SaaS companies selling into enterprise markets.