Sooner or later a B2B company's first large prospect sends a security questionnaire, and somewhere near the top it asks for a SOC 2 report or an ISO 27001 certificate. Both are serious undertakings, both are described as "security compliance", and from the outside they look interchangeable. They aren't. They come from different bodies, produce different artefacts, get audited by different kinds of firm, and are expected in different markets. Knowing what each one actually is makes the "which first" question much easier to answer.
The short version: most teams start with whichever one their customers keep asking for. SOC 2 is the default in North American procurement; ISO 27001 is the international default, especially in Europe and the public sector. The two overlap heavily, so whichever you do second is far less work than the first.
This post describes the two frameworks. It isn't legal or audit advice: scoping decisions belong with your auditor or certification body.
What each one actually is
| SOC 2 | ISO/IEC 27001 | |
|---|---|---|
| What it is | An attestation: an independent auditor's opinion on your controls | A certification of your information security management system (ISMS) |
| Defined by | The AICPA, using its Trust Services Criteria | ISO and IEC, as an international standard (current edition: 2022) |
| Who audits | A licensed CPA firm | A certification body, ideally one accredited by a national accreditation body |
| What you get | A report: the auditor's opinion, a description of your system, and (Type II) the tests performed and their results | A certificate, backed by your Statement of Applicability |
| What's in scope | The system you define, against the criteria you choose: Security is always included; Availability, Processing Integrity, Confidentiality and Privacy are optional | The ISMS scope you define; the 93 Annex A controls, each included or excluded with a justification |
| How long it lasts | No formal expiry, but a report covers a past period and customers typically expect a new one every year | Three years, with surveillance audits in years two and three, then recertification |
| Who can see it | Restricted: usually shared with customers under NDA (a SOC 3 is the public summary) | The certificate is public and verifiable; the Statement of Applicability is shared on request |
| Where it's most expected | US and Canadian customers, especially SaaS procurement | Europe, the UK, Asia-Pacific, and public-sector tenders |
Type I, Type II, Stage 1, Stage 2
Both have a two-step shape, which is where much of the confusion comes from. A SOC 2 Type I report assesses whether your controls are suitably designed at a single point in time. A Type II report tests whether they actually operated effectively over a period, commonly six to twelve months, which is why a Type II can't be rushed: the evidence has to accumulate. Customers ultimately want Type II, and a Type I is often what a company shows while the first observation period is running.
ISO 27001 certification also comes in two steps, but both are part of one certification audit. Stage 1 reviews your documentation and readiness: scope, risk assessment, Statement of Applicability, policies. Stage 2 checks that the ISMS is actually operating as documented. Before Stage 2, certification bodies generally expect the system to have run long enough to produce its own outputs, including at least one internal audit and management review.
The real difference is philosophy
ISO 27001 is a management system standard. Its core clauses ask whether you have a working process for managing information security risk: that you understand your context, that leadership owns it, that you assess and treat risks, decide which controls apply and why, measure how it's going, audit yourself, and improve. The Annex A controls are the catalogue you choose from, but the certificate is really about the machine that does the choosing.
SOC 2 is controls-first. The Trust Services Criteria describe outcomes, you describe the controls that achieve them, and the auditor tests whether those controls were in place and, for Type II, whether they worked throughout the period. It asks a narrower but very concrete question: over these months, did the things you said you do actually happen?
In practice that means ISO 27001 pushes you to build a durable risk process, while SOC 2 pushes you to produce a steady trail of evidence. Mature programmes need both, which is part of why companies selling internationally so often end up holding both.
Where they overlap
Heavily. Both expect a documented risk assessment, access control and regular access reviews, change management, logging and monitoring, incident response, vendor and supplier management, security awareness, and business continuity. The AICPA publishes a mapping between the Trust Services Criteria and ISO 27001, and many audit firms offer to run the two together. The practical upshot: the evidence you build for one is largely reusable for the other, and the second is mostly a matter of filling gaps and re-presenting the same work in the other framework's terms.
How teams usually decide
None of these is a rule, but these are the signals that tend to settle it:
- What the questionnaires literally ask for. If deals keep stalling on "please provide your SOC 2 Type II report", that's the answer. The same goes for tenders that list ISO 27001 as a requirement.
- Where your customers are. North American enterprise buyers tend to ask for SOC 2; European, UK and public-sector buyers tend to ask for ISO 27001. A company selling into both markets usually ends up with both.
- What you need to show, and by when. A SOC 2 Type I can be an early answer while the Type II period runs. ISO 27001 generally needs the ISMS operating, with an internal audit and management review done, before the Stage 2 audit.
- Whether a public credential matters. An ISO certificate can be named and verified publicly; a SOC 2 report is typically shared under NDA, one customer at a time.
- What you'll build next. Teams planning to add other ISO-family standards (such as ISO 27701 for privacy) often start with 27001 because the management system carries over.
Where threat modeling fits in both
Both frameworks start from risk, and both are easier to satisfy when risks are identified from how the system actually works rather than from a generic list. In ISO 27001, the risk assessment in clause 6.1.2, run on schedule under clause 8.2, is exactly where a threat model feeds the risk register, and Annex A controls such as 8.25 (secure development life cycle) and 8.27 (secure system architecture and engineering principles) expect security to be designed in. The deep dive is how threat modeling speaks ISO 27001.
In SOC 2, the risk-assessment criteria (CC3.2 on identifying and analysing risk, among others) and change management (CC8.1) are where a living threat model becomes evidence, especially for a Type II, where the auditor wants to see security analysis keeping pace with changes across the whole period. That's covered in closing the SOC 2 evidence gap. Either way, a risk register generated from real threat models is one artefact that serves both audits.
Common misconceptions
- "We're SOC 2 certified." There's no such thing: SOC 2 is an attestation report, not a certification. Buyers who know the difference notice.
- "Any ISO certificate will do." Certificates from certification bodies that aren't accredited carry much less weight with informed buyers. Check the accreditation mark.
- "The report or certificate covers the whole company." Both cover a scope you define. Read the system description or the ISMS scope and Statement of Applicability before assuming the product you're buying is included.
- "Compliant means secure." Both show that a defined set of controls exists and is operated. Neither says the controls are the right ones for every threat, which is why the risk assessment underneath them matters more than the badge.
The best predictor of which one to do first is usually already in your inbox, in the questionnaires your prospects send. Whichever it is, building the risk process properly the first time is what makes the second one cheap.
For how these frameworks show up across regulated industries, see threat modeling for SaaS and threat modeling for fintech, or start from the free risk register template.