SOC 2 vs ISO 27001: What's Actually Different

In the SOC 2 as Code post I built a small pipeline that collects evidence and checks it against the SOC 2 Common Criteria. The question I kept getting asked while working on it: why SOC 2 and not ISO 27001? They get mentioned in the same breath so often that it’s easy to assume they’re the same thing wearing a different label. The more I read into it, the less true that turned out to be. They’re both trying to answer the same question for a customer: should I trust this company with my data? But the mechanism, the audit itself, and even what gets tested are different.

What is SOC 2, again?

SOC 2 is a report, not a certificate. A licensed CPA firm audits your controls against the AICPA’s Trust Services Criteria and writes an opinion. There are five criteria total — Security (mandatory), Availability, Confidentiality, Processing Integrity, and Privacy — and a company scopes in whichever ones are relevant. Almost everyone starts with Security alone; it’s the only mandatory one and it covers most of what a customer actually cares about.

There are two types of report. Type I checks whether your controls are designed correctly, as of a single point in time, basically a snapshot. Type II checks whether those controls actually operated correctly over a period, usually 3 to 12 months, which is what customers actually want to see, since a control that’s designed well but never gets followed is worthless.

The audit itself runs roughly like this: a readiness assessment first (either self-run or with a consultant, to find gaps before the real audit does), then the observation period where the auditor is essentially watching your controls run in the background, then fieldwork, where the auditor requests evidence, samples a subset of it (they don’t check every single login event; they pull samples and extrapolate), interviews people, and writes an opinion. The opinion can be unqualified (clean), qualified (mostly fine, with named exceptions), or adverse (no). Most companies that fail don’t publish the report; a bad SOC 2 report is worse than no report at all, so failing audits tend to get quietly reworked rather than released.

What is ISO 27001?

ISO/IEC 27001 is an international standard for an Information Security Management System (ISMS). The actual subject of the audit is whether you have a functioning process for identifying risks and deciding what to do about them; having MFA turned on is just one downstream artifact of that process working.

Structurally, ISO 27001 has two halves:

• Clauses 4 through 10 — the mandatory ISMS requirements themselves: context of the organization, leadership commitment, planning, support, operation, performance evaluation, and improvement. This is the Plan-Do-Check-Act loop formalized. You can’t skip these; they’re what makes it a system instead of a checklist.
• Annex A — a reference set of controls you draw from based on your own risk assessment. The current version, ISO/IEC 27001:2022, has 93 controls across 4 themes — Organizational, People, Physical, and Technological. Anyone still certified under the old 2013 version (14 clauses instead of 4 themes) had to transition by October 2025, so 2022 is the only version that matters now.

An accredited certification body audits you against it, and if you pass you get an actual certificate, valid for three years. The first year is a full initial audit (Stage 1 checks your documentation and readiness, Stage 2 checks whether it’s actually implemented), then years two and three are lighter surveillance audits that spot-check a subset of controls, then year four is a full recertification audit and the cycle restarts.

The part that actually matters: fixed checklist vs. risk-based system

People usually summarize these frameworks as “American” versus “international” and leave it there. SOC 2’s Trust Services Criteria are effectively fixed: once you pick Security (and maybe Availability, Confidentiality, whatever else applies), the criteria you’re tested against don’t change based on your risk profile. Everyone doing a Security-only SOC 2 is tested against roughly the same shape of control set.

ISO 27001 works backwards from that. You’re required to run your own risk assessment first: identify your actual threats and vulnerabilities, decide which of the 93 Annex A controls are relevant to your business, and formally document the ones you’re excluding and why, in a Statement of Applicability (SoA). A physical-security control about server room access badges might be legitimately not applicable to a fully cloud-native startup with no office server room, and ISO 27001 expects you to say so, on the record, with reasoning. SOC 2 doesn’t really have an equivalent “we’re excluding this control because” mechanism in the same formal sense. The Trust Services Criteria you scope in are simply what you’re tested against.

Practically, this means ISO 27001 asks a startup to build a small risk-management muscle it might not otherwise build for years, and SOC 2 hands you a more prescriptive list. Neither is strictly harder. They’re testing different things: SOC 2 tests whether specific controls worked, ISO 27001 tests whether you have a system capable of noticing when a control needs to exist in the first place.

What it actually costs and how long it takes

I’m hedging the numbers here on purpose, because pricing varies wildly by company size, auditor, and how much of the evidence collection you’ve automated versus how much a consultant has to chase down by hand, but the rough shape that gets cited consistently across the industry:

	SOC 2 Type II	ISO 27001
Typical first-time cost	Commonly cited in the low-to-mid five figures for a small company, scaling up with headcount and scope	Similar order of magnitude, often somewhat higher once you count the certification body’s audit days plus internal risk-assessment effort
Timeline to first report/certificate	Readiness work, then a 3–12 month observation period, then fieldwork	Stage 1 and Stage 2 audits, often several months of ISMS build-out beforehand
Ongoing cost	A new Type II report roughly every 12 months, effectively forever	3-year cycle: lighter surveillance audits in years 2 and 3, full recertification in year 4

The practical upshot is that SOC 2 is a recurring annual cost: there’s no multi-year certificate you can coast on, you need a fresh Type II period covered every year to keep the report current. ISO 27001 front-loads more effort into the ISMS build in year one, then eases off for two years before a heavier recert. Companies that end up holding both frameworks are usually paying for SOC 2’s yearly cadence and ISO’s three-year cadence running in parallel, on different clocks.

Where they overlap (and why one pipeline can serve both)

Under the hood, a lot of the raw evidence is identical: MFA enforcement, centralized logging, change management, encryption at rest. What differs is the mapping: the same security_groups_open_to_world check that satisfies SOC 2’s CC6.6 also satisfies an ISO 27001 Annex A control on network security, just filed under a different clause number.

A few controls straight out of controls.py, next to their rough ISO 27001 Annex A equivalent:

Evidence collected	SOC 2 control	ISO 27001 Annex A control
MFA required for IAM, Okta, GitHub org	CC6.1	A.5.17 Authentication information, A.8.5 Secure authentication
Access removed on offboarding, no long-lived root keys	CC6.3	A.5.18 Access rights, A.8.5 Secure authentication
No security group open to the internet on a sensitive port	CC6.6	A.8.20 Networks security
S3 buckets private and encrypted	CC6.7	A.8.24 Use of cryptography
GuardDuty threat detection enabled	CC7.1	A.8.16 Monitoring activities
Multi-region CloudTrail logging	CC7.2	A.8.15 Logging
PR review required, no force-push to default branch	CC8.1	A.8.32 Change management

Same fact, same API call, two different filing cabinets depending on which auditor is asking. Which is the practical case for building your own evidence pipeline instead of only buying a platform: the collection layer doesn’t care which framework you’re mapping to. The evidence.json my pipeline already collects wouldn’t need a single new API call to start feeding an ISO 27001 control set, just a second mapping table next to controls.py, and someone willing to run the actual risk assessment and write the SoA, which is the one part of this that genuinely can’t be automated. That part is a judgment call about your business, not a fact you can pull from an API.

One thing people get backwards

People say a company is “SOC 2 certified.” It isn’t. There’s no certification and no pass/fail badge, just a report with an auditor’s opinion attached, and that opinion can be qualified in ways that still get called a pass in a sales deck. ISO 27001, by contrast, really does produce a certificate you either hold or don’t, issued by a body that itself has to be accredited by a national accreditation body to be allowed to issue it. People get this backwards constantly, treating the report as a certification and the certification as just another report. It’s a small thing, but it’s a decent tell for whether someone’s actually read a SOC 2 report or just seen the logo on a trust page.

Which one should a startup actually get first?

For most early-stage SaaS startups selling to other US companies, SOC 2 comes first. It’s what’s actually being asked for in the sales cycle, it’s faster to get an initial report on, and the whole ecosystem (auditors, platforms like Vanta and Drata, even this kind of blog post) is built around it. ISO 27001 tends to show up later, once a company is selling into enterprise, government, or international customers who either don’t recognize a SOC 2 report or specifically require ISO certification as a vendor condition. Plenty of companies eventually end up holding both, because the customer bases end up overlapping, and at that point the ISMS clauses 4–10 give you a natural home to manage both efforts under one system instead of two disconnected compliance projects.

This isn’t really an engineering decision, it’s a sales and market question, and whoever’s closing the deals usually knows the answer before whoever’s building the evidence pipeline does. What the engineering side controls is how expensive that answer is to act on. That’s the part I actually have some influence over.

Wrap-up

The thing that actually surprised me putting this together: the hard part of either framework was never the technology. MFA, centralized logging, change review, none of that is exotic, and none of it is the reason one framework takes longer or costs more than the other. The hard part is the system built around the technology: for SOC 2 that means an annual cycle of proving the same controls worked again, for ISO 27001 it means a standing risk-assessment process that keeps noticing new things worth controlling. The evidence-collection pipeline I built for SOC 2 barely changes if I point it at ISO 27001 instead. The part that doesn’t come for free on either framework is the judgment underneath it: deciding what’s actually a risk to your business, and being honest about it in writing. A script can’t do that part.

References

• AICPA — SOC 2 / Trust Services Criteria
• ISO/IEC 27001 — Information security management
• SOC 2 as Code: Automating Evidence Collection for a SaaS Startup — the pipeline this post references