TL;DR

I originally wrote the 5-part SOC 2 for ISVs series in early 2025. In 2026 I refreshed all five posts: regenerated the imagery for a more modern, consistent look, and revisited the content based on what I actually saw across customer engagements between 2020 and 2025. Up front: I’m an engineer, not a CPA. I just want to ship code. I ended up doing this work because the companies I consulted with needed to sell B2B and couldn’t without it. This refresh adds the honesty that the original series didn’t quite have, plus a per-post update reflecting what’s changed in the field — including the rise of compliance automation vendors, the impact of AI on the workflow, and how identity standards have absorbed a huge chunk of what used to be manual security work.

A note on who’s actually writing this

Let me be honest about my position. I’m not a CPA. I’m an engineer who would rather be writing code than reading the AICPA Trust Services Criteria. I don’t enjoy bureaucracy or paperwork.

I ended up deep in SOC 2 — and SOC 1, SOC 2 Type I, SOC 2 Type II, and even the less-common SOC 3 — because the companies I consulted with needed those reports to sell B2B. PII safety, control evidence, audit trails: these were table stakes for the deals their sales teams wanted to close. So somebody had to make sure the technical side held up. That somebody, often, was me.

What I want to be clear about is that the audit work was never one person’s job. On the engagements I was part of:

  • The CISO owned the security program, risk register, and most policy documents
  • The CPA firm issued the actual SOC report — they’re the only ones legally allowed to
  • A third-party pen-test firm ran the independent penetration test (you can’t pen-test yourself, as I covered in Part 1)
  • The office manager / operations lead often handled surprising amounts of the people-side evidence — onboarding records, training completion, vendor agreements, signed acknowledgments
  • The engineering and platform teams handled the technical controls — IAM, logging, encryption, change management, vulnerability remediation
  • And in 2025 I finally adopted a GRC automation platform (Scytale, in my case) that pulled all of this together

That last point matters more than I gave it credit for in the original series.

The vendor landscape changed everything

When I started doing this work years ago, SOC 2 readiness was a Word-document-and-spreadsheet exercise. Policies in Word, evidence in Google Drive folders, control matrices in Excel, and a lot of human chasing. By 2025 the landscape had completely shifted. Modern compliance automation platforms now connect to AWS, Azure, GCP, GitHub, Okta, Jira, and dozens of other systems to pull evidence automatically.

The major vendors I’d put on any ISV’s evaluation shortlist today:

  • Vanta, Drata, Secureframe, and Sprinto — the four most commonly compared platforms, with Vanta favored for fast onboarding and Drata for deeper automation
  • Scytale — an Israeli compliance automation company with a hands-on customer support model, offering dedicated compliance specialists alongside the platform — this is the one I started using in 2025 and the one that finally pulled the workflow together for me
  • Thoropass — bundles platform plus audit services in a single contract
  • Delve — a newer AI-native compliance platform founded in 2023, gaining rapid traction with a “compliance in days, not months” pitch

These platforms don’t replace the auditor and they don’t replace the CISO. The final SOC 2 audit report still has to come from an independent CPA firm. What they do is replace the spreadsheet. They give you the rails — the questionnaires, the control mappings, the integration plumbing — so the human conversations across the organization (engineering, security, ops, finance, HR) become coordinated instead of chaotic.

Five years ago, getting a small ISV to SOC 2 Type II was a 9-12 month effort. With one of these platforms, an experienced team, and clean infrastructure, 6 months is realistic and 3-4 months is achievable for the readiness phase. That’s a real shift.

And then AI showed up

The other big change since I first wrote this series is AI sitting next to me while I work on compliance. In 2026, I can ask an LLM to map a specific AWS configuration to the relevant Trust Service Criteria, draft a management response to an exception, summarize what an auditor will likely ask in a walkthrough, or check whether my evidence quality looks consistent. None of this replaces the auditor’s judgment or the CISO’s ownership — but it dramatically reduces the “where do I even start?” friction that used to slow first-time engagements.

The compliance automation platforms have noticed. Several of them now ship AI features that pre-review evidence, flag anomalies, draft policy text, and answer auditor questions. Used carefully, this is genuinely time-saving. Used carelessly, it produces hallucinated controls and confident-sounding nonsense. The principle I keep coming back to: let AI accelerate the boring parts, keep humans on the judgment parts.

SOC 2 vs ISO 27001/2 — the philosophical difference

Worth saying out loud, because I see it confused a lot. Both frameworks aim at the same outcome (defensible, well-managed security), but they get there differently.

ISO 27001 / 27002 is prescriptive. The standard tells you what controls you need to have, organized into a structured Annex A. You either have them or you don’t. The certification process is rigorous and the controls are non-negotiable.

SOC 2 is principles-based. The Trust Service Criteria define what “good” looks like, but you describe the controls you implement to meet those criteria, in your own words, in your own system description. As long as you can defend them and the auditor can sample evidence of them operating, the report stands. This gives you flexibility — you can explain why a particular control fits your context, or why a different mechanism achieves the same outcome.

For ISVs, this matters: SOC 2 lets you describe a cloud-native, GitOps-driven, fully-automated control program in language that fits how you actually operate. ISO 27001 forces you into a more traditional control structure that doesn’t always map cleanly to modern infrastructure. Most ISVs do SOC 2 first for exactly this reason — it bends to fit your reality. ISO 27001 comes later, when European expansion or larger enterprise contracts demand it.

Identity standards have absorbed half the work

One more thing I want to call out, because it’s quietly the biggest shift in the SOC 2 control surface over the last five years.

Authentication, authorization, and identity used to be a sprawling mess of homegrown auth, password policies, manual access reviews, and ad-hoc role definitions. In 2026, for any ISV worth its salt, identity is solved by standards and managed services:

  • Okta, Auth0, AWS Cognito, Google Identity — externalized identity providers
  • OIDC, SAML, SCIM — open standards for federation, SSO, and provisioning
  • OAuth 2.0 with proper scopes — externalized authorization
  • Workload identity federation (IRSA, GCP Workload Identity, OIDC from CI) — no more long-lived machine credentials

When SOC 2 asks “how do you authenticate users? how do you enforce MFA? how do you provision and deprovision access? how do machine identities work?” — the answers in 2026 are mostly “we use Okta + OIDC + SCIM + workload identity federation”, with the identity provider itself carrying its own SOC 2 report that you inherit responsibility for.

This isn’t a free pass. You still have to configure these systems correctly — and the Snowflake breaches of 2024, the Okta incidents of 2022 and 2023, and the MGM/Caesars attacks via Okta AD Sync all showed what happens when the configuration is sloppy or ghost logins go un-reviewed. But the control surface has shrunk dramatically. The work is configuration and governance, not implementation.

If you want to go deeper on the identity side, I’ve written about this extensively in my Zero Trust series — particularly Identity is the New Perimeter and SSH and the Cryptographic Turn which map directly to the SOC 2 access-control and authentication criteria.

What’s in the rest of this post

Below, for each of the five posts in the series, you’ll find a short addition paragraph capturing what I’d add or sharpen with 2026 hindsight. The original posts are linked at the top of each section; the addition is the new material. Each addition also references at least one real-world incident from 2020-2025 that I would have used as an anchor if I’d written the series today.

Part 1 — The Price of Admission

Original: SOC 2 for ISVs: The Price of Admission to the Enterprise

Originally developed in-house as part of a customer engagement where I led the SOC 2 audit preparation across AWS and GCP — the medical-domain ISV anchor case I reference throughout the series.

2026 addition

The single thing I’d sharpen in this post with 2026 hindsight is the timeline framing. In 2025 I described SOC 2 as “the price of admission” — true then, even truer now. Across the engagements I’ve seen since, the expected compliance posture for an enterprise-selling ISV has drifted earlier in the company lifecycle. What used to be a Series-B problem is now often a late-seed or Series-A problem. Buyers are no longer satisfied with “we’re working on it” the way they sometimes were three years ago. If you’re building an ISV with enterprise ambitions in 2026, treat SOC 2 readiness as a Series-A milestone, not a post-PMF nice-to-have.

I’d also anchor the cost-of-not-doing-it argument in something more concrete than the original post did. The Okta breaches of 2022 and 2023 are the cleanest case study: Okta is a security company with a SOC 2 report and every certification you can name, and it still suffered two major incidents — the LAPSUS$ breach via the Sitel contractor in January 2022 and the HAR-file/session-token theft from the support system in October 2023. The 2022 disclosure triggered an 11% stock drop and roughly $6B in market-cap erasure; the 2023 disclosure triggered another 11.5% drop. Okta later settled a related securities class action for $60M. That’s the cost of a security incident with compliance posture — imagine the conversation if they’d been operating without it. Compliance doesn’t prevent every breach, but the absence of compliance amplifies every breach’s downstream cost.

Part 2 — The Five Trust Service Criteria, Demystified

Original: SOC 2 for ISVs, Part 2: The Five Trust Service Criteria, Demystified

Originally developed in-house during the same medical-ISV engagement, where the scoping decisions across the five criteria were a real, contentious conversation — not a hypothetical exercise.

2026 addition

What I’d add now is a sharper take on Privacy creep and on the shared responsibility model that scoping forces you to confront. In 2025 I said it was reasonable to exclude Privacy from a first audit if personal data wasn’t core to your product. That’s still technically true, but the enterprise buyer landscape has shifted. With the maturation of state-level privacy laws in the US (CPRA expansions, multiple new state acts) and continued GDPR pressure on cross-border SaaS, more enterprise procurement teams are asking “why isn’t Privacy in scope?” even when the answer is defensible. If you’re scoping a fresh SOC 2 in 2026, my updated default is: Security + Availability + Confidentiality remains the right core, but be ready to articulate — in writing, in your trust portal — exactly why Privacy is excluded and where that data is governed instead.

The other thing the 2024 Snowflake customer breaches made viscerally clear is that scoping is also about what you commit to do vs. what’s on the customer. Snowflake’s platform was not breached. What happened was that ~165 customers — including AT&T, Ticketmaster, Santander, and LendingTree — had Snowflake accounts without MFA, and attackers used credentials from infostealer malware (some dating back to 2018) to log in directly. Snowflake had a clean SOC 2 report. The customers had configuration failures. Both things were true at once. When you scope your own SOC 2, every criterion you include carries an implicit promise about which side of the shared responsibility line you’re on. Be deliberate about that, and make sure your customer documentation makes the same line equally clear.

Part 3 — The Technical Foundation

Original: SOC 2 for ISVs, Part 3: From Zero to Audit-Ready — The Technical Foundation

Originally developed in-house during the dual-cloud (AWS + GCP) audit work where the IAM, logging, and change-management mappings in this post were built and battle-tested.

2026 addition

The control-family mappings to AWS, GCP, and Kubernetes are still accurate. Two things I’d add with 2026 hindsight: first, workload identity has fully won. In 2025 I framed eliminating long-lived IAM credentials as the single biggest unlock — that’s still true, but the tooling to do it (IRSA on AWS, Workload Identity Federation on GCP, OIDC federation from CI) is now mature enough that there’s genuinely no excuse left. The 2022 GitHub OAuth token incident is the cautionary tale I’d cite now: attackers stole OAuth tokens from third-party CI integrators (Heroku and Travis CI) and used them to download dozens of organizations’ private repos, including npm’s source code, then mined the code for an embedded AWS API key to pivot further. Long-lived credentials, third-party trust, and secrets-in-code all in one incident. The 2023 Okta service-account incident — where an employee saved Okta service-account credentials in a personal Google account on a work laptop — is another one I’d cite. If you still have static cloud credentials in your CI in 2026, or service-account keys floating in personal accounts, that’s not a finding-waiting-to-happen, it’s already happened to someone you’ve heard of.

For the networking-side of workload identity, my post on WireGuard: Why Simpler Won covers how mesh VPN patterns reduce the attack surface that SOC 2 auditors often flag in traditional VPN setups.

Second, agentic / LLM-driven tooling in the development workflow is now in audit scope in ways it wasn’t when I first wrote this post. Auditors are starting to ask how AI-generated code is reviewed, how prompts and outputs are logged, and how access to internal data through AI tooling is governed. None of this changes the SOC 2 control families, but it adds new evidence surfaces that didn’t exist in the 2025 version of this post.

Part 4 — Continuous Compliance

Original: SOC 2 for ISVs, Part 4: Continuous Compliance — Making SOC 2 a Byproduct, Not a Project

Originally developed in-house from patterns built across multiple platform engagements — drift detection cadence, evidence automation, and the OPA/Rego enforcement points were all production-tested before they made it into the post.

2026 addition

The three pillars — policy-as-code, drift detection, evidence automation — have aged well. The one place I sharpened the original post itself was inside the policy-as-code pillar: I added a dedicated treatment of AWS Service Control Policies and GCP Organization Policies as the unbeatable top layer of preventive control. OPA and Gatekeeper catch violations at the IaC and Kubernetes layers, but a console user with enough permissions can still go around them. SCPs and Org Policies sit at the cloud account boundary and deny the API call regardless of who’s logged in — the CloudTrail “AccessDenied” entry is the evidence, with no ambiguity. If I were writing Part 4 fresh today rather than in 2025, that would have been in there from day one. Public-S3 prevention, CloudTrail-disable prevention, IAM-user creation lockdown, region restriction, root lockdown — these are the day-one SCPs every ISV should ship before their first audit window opens.

What I’d add as genuinely new for 2026 is a fourth pillar: AI-assisted compliance review. By 2026, the better compliance platforms have shipped agents that can pre-review evidence quality, flag anomalies in access reviews, and draft management responses to exceptions. Used carefully, they meaningfully reduce the human-time cost of running a continuous compliance program. Used carelessly, they hallucinate controls you don’t have and produce evidence summaries that don’t survive auditor scrutiny. My current rule of thumb: let AI accelerate the boring parts (collection, formatting, gap-spotting), keep humans on the judgment parts (risk decisions, scope changes, exception handling).

I’d also use this post to drive home — with real incidents — why the continuous part of continuous compliance matters. Three I’d cite:

  • The 2021 Cash App incident, where a former employee accessed and downloaded data on 8.2 million customers after termination. A textbook offboarding failure — exactly the kind of joiner/mover/leaver control SOC 2 puts under the microscope.
  • The 2021 Verkada breach, where a hacker collective found “Super Admin” credentials on an unencrypted internal subdomain — but the underlying problem was that 100+ employees, including interns, had super-admin access in the first place. Least-privilege failure at a scale that’s almost satirical.
  • The 2024 Internet Archive incidents, including a Zendesk API token that had been valid and unrotated since 2018 — granting access to 800,000+ support tickets containing sensitive personal documents. A drift / token-rotation control that nobody touched for six years.

Every one of these would have been caught by the continuous-compliance pillars in the original post. None of them required exotic detection — just a control that actually operates on cadence, with evidence captured along the way.

The “where humans still belong” section in the original post was right; in 2026 it’s load-bearing.

Part 5 — Surviving the Audit and What Comes After

Original: SOC 2 for ISVs, Part 5: Surviving the Audit and What Comes After

Originally developed in-house drawing on a half-decade of customer engagements where I sat through readiness assessments, observation windows, and follow-on framework expansions (HIPAA, ISO 27001 mapping work).

2026 addition

The audit experience itself hasn’t changed much — auditors still do walkthroughs, still sample evidence, still write reports in the same five sections. What’s changed is what comes after. In 2025 I framed ISO 27001, HIPAA, and FedRAMP as the natural next-framework choices. That’s still right, but the order has shifted for many of the ISVs I’ve worked with recently. ISO 27001 has become the more frequent immediate next step — partly because European enterprise expansion is a more common growth motion than US federal sales for the kind of ISVs I see, and partly because the control overlap with SOC 2 has been formalized by the major compliance platforms in ways that make the delta meaningfully smaller. FedRAMP remains a 12-24 month commitment with its own gravitational pull; HIPAA remains domain-specific.

I’d also be more direct in this post about the “clean report doesn’t mean done” point. The September 2023 MGM and Caesars breaches — both reportedly abusing the Okta Active Directory Sync integration, with red-team write-ups showing how easy that utility was to exploit publicly available before the breaches occurred — made it brutally clear that a controls program can pass audit while quietly carrying known-weak integrations. The audit catches what’s in scope at a point in time. It doesn’t catch what your security team hasn’t gotten around to mitigating yet. SOC 2 renewal isn’t a deadline to chase; it’s a forcing function to ask what’s degraded since the last one. If I were advising an ISV on framework sequencing in 2026, the default path I’d suggest is SOC 2 Type II → ISO 27001 → domain-specific framework as needed — and I’d push the ISO 27001 conversation earlier in the planning cycle than I would have in 2025.

Closing note

Keeping a series like this fresh isn’t about chasing every trend. It’s about being honest when something I wrote a year ago doesn’t quite match what I’d say today — and updating the public record accordingly. The original 5-post series stands; these additions are the 2026 view, written from a current engagement that pulled me back into the material with fresh eyes.

If you’re starting a SOC 2 journey now, the original posts are still the right place to begin. If you’re mid-journey, the additions above are where the frontier has moved.