TL;DR

The audit itself is anticlimactic — if you’ve done the work, it’s mostly walkthroughs and evidence sampling. The interesting parts are before (auditor selection, readiness assessment) and after (the observation window, the report, what compliance framework comes next). This final post in the series covers all of that, plus the most common findings I see ISVs hit on their first Type II.

Introduction

Over four posts we’ve covered why SOC 2 matters, how to scope it, the technical foundation, and how to make compliance continuous. Now we close the loop: what does the actual audit feel like, and what should you do with the report once you have it?

Most first-time ISVs treat the audit as the finish line. It isn’t. It’s a checkpoint in a multi-year compliance journey, and how you handle it shapes everything that comes after — including which framework you tackle next.

Choosing an auditor

You’re going to spend a lot of time talking to this firm. Pick well.

What actually matters:

  • Industry experience. An auditor who has worked with cloud-native ISVs in your domain understands your stack and your risks. One who mostly audits financial services will ask questions that don’t apply and miss ones that do.
  • CPA license and AICPA peer review. SOC 2 reports must be issued by a licensed CPA firm. Verify their peer review status — it’s public.
  • Tooling fit. Modern auditors integrate with the major compliance platforms via API. If your platform pulls evidence into a structured store, you want an auditor who can consume it that way, not one who emails you a spreadsheet of evidence requests.
  • Pragmatism. Some auditors are box-checkers; some genuinely engage with how your controls operate. Talk to references and ask the latter group’s clients about how exceptions and judgment calls were handled.

What doesn’t matter as much as you think: brand. The Big Four will issue a fine SOC 2 report, but for a small-to-midsize ISV, mid-tier audit firms specializing in tech are usually faster, cheaper, and more in tune with your reality. Enterprise buyers care about the report content and the auditor’s CPA status — not the firm’s logo.

The readiness assessment

Before you commit to a Type I or Type II audit, most teams run a readiness assessment — sometimes called a gap assessment — with either their compliance platform’s advisory team or a separate consultant. This is essentially a mock audit that produces a list of gaps to remediate before the real one starts.

What it’s good for:

  • Catching missing controls before the audit clock starts
  • Sanity-checking your scoping decisions
  • Calibrating evidence quality (is your access review really sufficient, or just sufficient-looking?)
  • Building muscle memory for walkthroughs

The medical ISV I’ve referenced throughout this series ran a readiness assessment before committing to the Type II observation window. The gap list it produced — encryption verification on a few legacy GCP buckets, missing documentation for one change-management exception path, an access-review template that didn’t capture the right metadata — was small but meaningful. Fixing them up front prevented exceptions in the actual report.

Skip the readiness assessment only if: you’re an experienced compliance team doing your second or third report. First-timers should always do one.

Type I or Type II — and when

  • Type I = “your controls are designed correctly as of [date].” Useful as an early signal to enterprise buyers — “we’re working toward Type II and here’s our Type I as a placeholder.” Some ISVs skip Type I entirely and go straight to Type II.
  • Type II = “your controls operated effectively over [period].” This is what enterprise procurement actually wants. Observation windows are typically 3, 6, or 12 months.

Pragmatic sequencing for most ISVs:

  1. Readiness assessment (4-8 weeks)
  2. Remediate gaps (varies wildly)
  3. Type I report (point-in-time, can be issued quickly)
  4. Begin Type II observation window (3-6 months for first report)
  5. Type II audit fieldwork (4-6 weeks)
  6. Type II report issued

After the first Type II, subsequent Type II reports typically cover a 12-month observation window with annual renewal. The cadence becomes predictable.

The observation window — what to actually do

Once your Type II observation window starts, your job is simple: operate your controls consistently, every day, and let your evidence-collection pipeline (from Part 4) do its job.

The traps that catch first-timers during the observation window:

  • A control fails and nobody documents the remediation. Quarterly access reviews missed by 2 weeks because the reviewer was on vacation? That’s an exception unless you document the compensating control and the catch-up.
  • A new system gets added and isn’t brought into scope. A new EKS cluster, a new database, a new CI runner — if it’s in scope but not under the same controls, that’s a finding.
  • Evidence quality drifts. The first month’s evidence is pristine; by month 4, screenshots are missing context, log exports have gaps, approvals lack timestamps. Audit your own evidence quarterly.
  • People change roles and access doesn’t update. The single most common finding — promoted engineer keeps old admin access “just in case.” Tie this to your joiner/mover/leaver process and test the process, don’t just document it.

Common first-time findings

Across the ISV engagements I’ve been part of, the same handful of findings come up again and again:

  1. Long-lived IAM credentials still floating around. Service accounts, CI tokens, ancient access keys nobody owns.
  2. Incomplete log retention. Logs exist but the retention policy doesn’t match what the controls document say.
  3. Access review gaps. Reviews happen, but evidence is informal — Slack threads, undated spreadsheets — instead of structured artifacts.
  4. Missing or untested DR/backup procedures. Backups run; restores are theoretical.
  5. Vendor management debt. Subprocessors used by the product aren’t documented or risk-assessed.
  6. Change management exceptions without a paper trail. Production hotfixes that bypassed review with no documented exception.

If you can clear these six before your audit, you’re already ahead of most first-timers.

What the report actually contains

A SOC 2 Type II report is a formal document, typically 50-100 pages, structured as:

  • Section I — Independent Auditor’s Report: the auditor’s opinion (unqualified, qualified, or adverse)
  • Section II — Management’s Assertion: your formal statement about your system and controls
  • Section III — System Description: how your service works, infrastructure, processes, scope
  • Section IV — Trust Service Criteria and Controls: the actual control list, tests performed, and results
  • Section V — Other Information (optional): management response to any exceptions

You’ll share this report under NDA with prospects and customers. Most enterprises will accept it directly; some will run it through a third-party review (KY3P, OneTrust, etc.) before clearing your vendor file.

An “unqualified opinion with no exceptions” is the gold standard. Exceptions aren’t fatal — auditors expect them in early reports — but each one needs a management response explaining what happened, what the impact was, and what you’ve changed.

What comes after SOC 2

SOC 2 is rarely the end of the compliance story. Once you have it, the question becomes: which framework next?

ISO 27001 — international counterpart, broader management-system focus. About 60-70% control overlap with SOC 2, so it’s the most natural next step for ISVs expanding internationally (especially into Europe). The lift is real but smaller than the first SOC 2 was.

HIPAA — required if you handle Protected Health Information. Not an audit/certification per se, but a regulatory framework with technical and administrative safeguards. SOC 2 covers maybe 70% of the technical controls; the gap is mostly around BAAs, breach notification, and patient-rights handling.

FedRAMP — required to sell to US federal agencies. Significantly heavier than SOC 2. Different baselines (Low, Moderate, High) and a much more prescriptive control catalog (NIST 800-53). Plan for 12-24 months and a dedicated compliance team.

PCI DSS — required if you handle cardholder data. Different framework, different auditor type (QSA), but again significant control overlap with SOC 2.

The pattern: SOC 2 builds the muscle. The first framework is the hardest because you’re learning to operate continuously and collect evidence. Subsequent frameworks become control-mapping exercises on top of an existing program — meaningful work, but not foundational rebuilds.

Conclusion

If you’ve done the work described in Posts 1 through 4, the audit is the easy part. You’ve scoped intentionally, built the technical foundation, and made compliance a byproduct of how you operate. The auditor’s role is mostly to verify that what you say is true, sample your evidence, and write it up.

The bigger picture: SOC 2 isn’t a credential you earn once. It’s an operational discipline you build into your platform — and once it’s there, every subsequent compliance framework gets cheaper, faster, and less disruptive. That’s the long-term ROI most founders miss when they stare at the year-one cost.

For ISVs with enterprise ambitions, that compounding is the real reason to start now rather than later.

Further Reading