ISO 27001 or SOC 2: How to Choose When a Customer Asks

A customer has asked for one of them and you are not sure which one to pursue, or whether the one they named is the one they actually need. This comes up constantly, and the usual advice, that SOC 2 is American and ISO 27001 is European, is true enough to be useless when a real decision is in front of you.

The two are not competing versions of the same thing. They answer different questions, are produced by different kinds of organization, and prove different things about you.

The structural difference

ISO/IEC 27001 certifies an information security management system. The subject of the certificate is your governing process: how you identify security risk, decide what to do about it, assign ownership, and review whether it worked. The controls in Annex A matter, but the standard is fundamentally about whether you run a functioning system for managing security, not about whether you have a particular technical control.

A SOC 2 report is an attestation. A licensed CPA firm examines your controls against the AICPA Trust Services Criteria and issues an opinion, along with a detailed description of what it tested and what it found. There is no certificate. There is a report, and the report has an audience.

That difference cascades into everything else. ISO 27001 is granted by an accredited certification body and results in a certificate you can put on a website. SOC 2 produces a document you send under NDA to a buyer who asked for it, and which their security team reads.

A related consequence: a SOC 2 report is far more informative to a reader who does the work. It contains the auditor’s tests, the exceptions found, and management’s responses. An ISO 27001 certificate tells you that a certification body was satisfied, and little else without asking for the statement of applicability.

Who is asking, and from where

Geography is the crude version of a better question: who is your buyer, and what does their security review actually run on?

North American enterprise procurement and security teams are largely built around SOC 2. Their questionnaires reference it, their vendor risk tooling ingests it, and their reviewers know how to read it. If your revenue is concentrated in the United States and you sell business software, SOC 2 is usually the direct answer.

European, UK, Middle Eastern, and Asian buyers, along with most public sector procurement outside the United States, tend to be organized around ISO 27001. It is an international standard with an established accreditation chain, and it travels in a way a report from a US accounting firm does not.

There are strong exceptions in both directions, which is why asking is better than assuming. Large multinationals frequently accept either. Some regulated buyers want both. And a growing number of security teams ask for ISO 27001 as a baseline and then send a bespoke questionnaire regardless of what you hold.

The overlap is real, and it is where the leverage is

The two frameworks ask for many of the same things in different vocabularies. Access control, change management, vendor risk, incident response, business continuity, and secure development appear in both. The evidence that proves an access review happened proves it for both.

What differs is the framing and what the assessor wants to see around that evidence. ISO 27001 wants to see the management system: the risk assessment that led to the control, the statement of applicability recording why it is in scope, the internal audit that checked it, and the management review that considered the result. SOC 2 wants to see the control operating and the evidence that it operated across the period.

For an organization that will eventually need both, this matters enormously. Building the underlying record once and presenting it two ways is substantially less work than running two programs. Building two programs, which is what happens when they are owned by different people in different tools, means paying for the same evidence twice and reconciling the two when they drift.

A practical note on ISO 27001 versions

ISO/IEC 27001:2022 is the current version of the standard. The transition period for organizations certified against the 2013 version closed on 31 October 2025, and certificates based on the 2013 version are no longer valid.

This has a specific consequence worth knowing if you are evaluating a vendor or inheriting a program: an organization that let its certification lapse cannot simply transition now. The transition audit route is gone, and recertification means a full initial audit against the 2022 version, which is a longer and more expensive path than the transition would have been.

If you are starting fresh today the question does not arise, because you will certify against the 2022 version. If you are picking up an existing program, confirm which version the certificate references and when it expires before you plan anything around it.

How to choose

Start by finding out what the customer will actually accept. Not what they asked for, what they will accept. Security questionnaires are often written once and reused for years, and the person sending yours may have no strong view. A direct question, asking whether an ISO 27001 certificate would satisfy the requirement or whether they specifically need a SOC 2 report, resolves a surprising number of these decisions in a single email.

If the answer is genuinely open, weigh these:

• ·Where your next two years of revenue comes from. Optimize for the buyers you are going to have, not the one in front of you.
• ·Whether you need something to show publicly. A certificate can go on a website. A report cannot.
• ·Whether your buyers’ security teams will read the detail. If they will, a SOC 2 report gives them more to work with and can shorten the review.
• ·What your existing evidence looks like. If you already run something resembling a risk-driven management system, ISO 27001 is closer than it appears.

And if the honest answer is that you will need both within two years, plan for both now. Not by pursuing both simultaneously, which spreads the work thin, but by building the underlying control record in a form that serves either. Sequencing one and then the other is normal. Rebuilding from scratch for the second is not necessary and is where most of the wasted cost in this area comes from.

The effort profiles are shaped differently

Comparing these on cost alone is misleading, because the work is distributed differently across time and the two have different failure modes.

ISO 27001 front-loads governance. Before an auditor is interested, you need a defined scope, a risk assessment methodology you actually applied, a statement of applicability justifying every Annex A control you included or excluded, and evidence that leadership reviewed the thing. Certification runs as a two-stage audit: a documentation review, then an implementation audit. After that, surveillance audits recur annually and the certificate is recertified on a three-year cycle.

SOC 2 front-loads operations. Governance artifacts matter less, but the control has to run and throw off evidence for every month of the observation period. There is no equivalent of a documentation-only stage that you can pass on the strength of good writing.

The failure modes follow from that. ISO 27001 programmes usually fail on the management system: a risk assessment done once and never revisited, an internal audit that never happened, a management review with no minutes. SOC 2 engagements usually fail on evidence: a control everyone agrees exists, with nothing to show it ran in March.

When you genuinely need both

Organizations selling across regions frequently end up holding both, and the sequencing question then becomes practical rather than philosophical.

The common order is SOC 2 first when US revenue dominates and a specific deal is waiting, because the observation period can start as soon as controls are running and there is no certification body to schedule around. ISO 27001 first tends to make sense when the buyer pressure is international, or when you want the management system discipline in place before you commit to a period of tested operating effectiveness.

What determines whether the second one is cheap or expensive is whether the evidence was built to be reused. A control implemented for SOC 2, with its evidence stored in a way that maps to an Annex A reference and a risk decision, carries most of the way. A control implemented for SOC 2 with evidence scattered across screenshots in a shared drive does not.

Our overviews of SOC 2 and ISO/IEC 27001 set out what each involves and what we maintain for clients pursuing them.