So you have to get SOC 2 — here's where to start

Someone in revenue just said the words: we need SOC 2. Maybe a big prospect blocked the deal. Maybe a partner portal won't turn on without a report. Either way, it's on your plate now — and the internet is full of vendors who will sell you panic.

This is the calm version: what that mandate usually means, what to clarify before you spend, and how to start the next 30 days without pretending to be an auditor.

Important: BreachBits is not a CPA firm and does not issue SOC 2 reports. An independent auditor does. Treat everything below as orientation for a CIO/CISO — not as audit procedure.

Core concepts (read this first)

SOC 2 is a report, not a wall certificate. A licensed CPA firm (your "service auditor") examines controls related to your service and issues a SOC 2 report you share with customers under NDA. There isn't a public "SOC 2 certified" badge that works like a three-year ISO certificate.

Type I vs Type II — the question everyone skips:

	Type I	Type II
What it answers	Are controls suitably designed as of a point in time?	Are controls designed and operating effectively over a period of time?
Evidence vibe	Policies, configs, and design proof "as of" a date	Design proof plus samples over the review window (tickets, logs, reviews that actually happened)
Typical use	Faster first milestone; bridge while you collect operating history	What most enterprise buyers eventually want

Review windows for Type II commonly run on the order of several months up to about a year (your auditor helps pick a period that produces enough evidence). Exact timing is a conversation with them — not a blog stopwatch.

How long does it "last"? A SOC 2 report doesn't expire like a driver's license. In practice, customers treat a report as current for roughly a year after the period/end date and expect you to keep producing fresh Type II reports on an annual rhythm. A stale report is why deals stall even though nothing "expired" on paper.

Trust Services Criteria (what can be in scope): Security is the usual baseline. Availability, Confidentiality, Processing Integrity, and Privacy are optional add-ons depending on what you sell and what buyers ask for. Confirm which criteria your customers care about before you scope the audit.

Who does the work: Your team runs the controls and gathers evidence. The CPA issues the opinion. Tooling and consultants can help readiness; they don't replace the auditor.

What people usually mean when they say "get SOC 2"

In practice, buyers want that SOC 2 report — usually Type II covering Security (and sometimes other criteria) — for the systems behind the product they buy.

Clarify these before you hire or buy anything

1. Is this a customer requirement or an internal goal? Deadline and willingness to accept alternatives (ISO letter, pen-test summary, questionnaire) change the plan.
2. Type I or Type II — did they specify? If they didn't, ask. Enterprise deals often expect Type II; Type I can be a stepping stone — confirm with the buyer and your auditor.
3. What's in scope? The product customers buy, the cloud account that runs it, corporate IT, a subsidiary — scope fights are where timelines explode.
4. Who owns this internally? Security, IT, Eng, Legal, People — SOC 2 is cross-functional. Pick an executive sponsor and a day-to-day owner.
5. Do we already have related work? Prior audits, ISO work, pen tests, inventory — bring it to the first auditor conversation so you don't restart from zero.

Who you'll need in the room

• Executive sponsor — clears priorities when Eng and Sales collide
• Day-to-day program owner — usually security or IT leadership
• Control owners — the people who actually run access reviews, change management, backups, etc.
• Independent CPA / SOC auditor — issues the report (select with procurement + references from peers)
• Optional: vCISO or compliance consultant to project-manage readiness — helpful, not mandatory

You do not need a tool for every checkbox on day one. You need scope, owners, and an auditor conversation.

What the journey usually feels like (phases, not a fake calendar)

Exact timelines depend on readiness, scope, and auditor availability — ask your auditor for a plan; don't trust a blog's stopwatch. The shape is usually:

1. Scope & criteria — what's in, what's out, which Trust Services Criteria
2. Gap look — where evidence or process is thin
3. Remediate & operate — fix gaps; run the controls long enough that evidence exists
4. Audit fieldwork — auditor examines evidence / operation for the period
5. Report — the artifact Sales can share under NDA

Your job as CIO/CISO is to keep scope honest and evidence real — not to "pass" by theater.

Evidence categories you'll be asked for (not a control list)

Expect requests that fall into buckets like:

• Policies and standards that match how you actually work
• System descriptions — what the service is, where it runs, what you promise
• Operational records — access reviews, change tickets, incident records, vendor reviews, training logs
• Technical evidence — configs, screenshots, exports, test results that back the story

If a control only exists in a slide deck, it isn't ready.

Common surprises

• Sales promised a date no auditor can hit with your current maturity — reset expectations early
• Scope creep — "just add HR systems" midstream
• Cloud shared-responsibility confusion — knowing what you own vs what AWS/Azure/GCP own
• Evidence that starts the day someone remembers the audit — Type II especially cares that controls ran, not that you wrote a policy last Tuesday

First 30 days — a starter checklist

• Capture the customer ask in writing (report type, deadline, systems)
• Name sponsor + program owner; book a weekly 30-minute steerco
• Draft a one-page scope hypothesis (in/out) for auditor feedback
• Inventory what you already have (policies, tickets, prior tests, diagrams)
• Shortlist 2–3 SOC auditors; schedule intro calls — ask about timeline for your scope
• List control-owner names even if the matrix isn't done
• Tell Sales what you can honestly commit to this quarter

Where continuous testing helps (without replacing the auditor)

Auditors care about controls and about whether your environment matches the story. Continuous outside-in assessment — discovering what's actually exposed, verifying real issues, and producing reports mapped to SOC 2-aligned control language — helps fill the technical-evidence gap and keeps surprises off the audit critical path.

That's a supporting input. The SOC 2 opinion still comes from your CPA firm.

If you want that kind of ongoing proof beside your readiness work, see Compliance or book a demo — after you've locked scope and an auditor path.

Authoritative sources

Start here when you want primary material (not vendor blogs):

• AICPA — SOC 2 overview (Trust Services Criteria) — what a SOC 2 examination is for
• AICPA — System and Organization Controls (SOC) suite — how SOC 1 / 2 / 3 relate
• 2017 Trust Services Criteria (with revised points of focus — 2022) — the criteria Security / Availability / Confidentiality / Processing Integrity / Privacy are drawn from
• Your chosen CPA firm's engagement letter and walkthrough of Type I vs Type II for your scope — still the authority on timeline and evidence sampling