ISO 27001 vs SOC 2: which one does your buyer actually want?

A prospect sends a security questionnaire. Somewhere in it is a line asking for "your ISO 27001 certificate or SOC 2 report." Both are named, no guidance on which, and the deal is waiting.

The two are not interchangeable, and starting with the one your buyer will not accept means the deal waits anyway. But they are not rivals either: they overlap enough that most of the work counts twice. Here is what each one actually proves, who accepts which, and how to sequence them.

The difference in one line

ISO 27001 certifies a management system. SOC 2 attests to your controls.

ISO 27001 is an international standard you get certified against. An accredited certification body audits your information security management system (ISMS) and, if it holds up, issues a certificate: a short document with a scope statement and an expiry date.

SOC 2 is not a certification and there is no such thing as being "SOC 2 certified." An independent CPA firm examines your controls against the AICPA's Trust Services Criteria and issues a report containing their opinion, your description of your system, and, in a Type II, the tests they ran and what they found. A Type II commonly runs 60 to 100 pages and often more, and your customer's security team is expected to read it.

That distinction drives almost every other difference.

Side by side

What ISO 27001 actually proves

ISO 27001 is a management-system standard. The certifiable requirements sit in clauses 4 to 10: understand your context, get leadership commitment, assess and treat risk, provide resources, run the thing, audit it internally, review it at management level, and improve it.

Annex A's 93 controls are the menu you draw from, not a checklist you complete. You assess your risks, decide which controls are relevant, and record the decision, including exclusions and why, in a Statement of Applicability. That document is the spine of the audit. An auditor who finds controls in your SoA with no evidence behind them, or risks in your register with no treatment, will raise a nonconformity regardless of how good your security tooling is.

Certification runs in two stages. Stage 1 is a documentation review: does the ISMS exist, is it scoped sensibly, is the SoA coherent. Stage 2 is the real audit: does it run in practice. Pass both and the certificate is valid for three years, with a surveillance audit each of the first two years and a full recertification in year three.

One recent change catches people out. ISO 27001:2022/Amd 1:2024 added a line to clause 4.1, that the organisation shall determine whether climate change is a relevant issue, and a note to clause 4.2 that interested parties may have climate-related requirements. It applies now, with no transition window. You are allowed to conclude that climate change is not relevant to your ISMS; you are not allowed to have never asked. Auditors are checking that the determination exists and is reasoned. Full guide: A.5.1.

The other date worth knowing: ISO 27001:2013 certificates expired on 31 October 2025. There is no late-transition route. If yours lapsed, the way back is a full initial certification against the 2022 standard. Our ISO 27002:2022 guide covers what changed and the road back.

What SOC 2 actually proves

SOC 2 measures you against the AICPA's Trust Services Criteria. Security is mandatory and consists entirely of the 33 common criteria across nine series (CC1 to CC9), covering control environment, communication, risk assessment, monitoring, control activities, access, operations, change management and risk mitigation.

Four more categories are optional and you add them based on what you have promised customers:

• Availability, if you sell an uptime commitment
• Confidentiality, if you have contractual confidentiality obligations beyond privacy
• Processing Integrity, if you process transactions where completeness and accuracy are the product
• Privacy, if you handle personal information under a stated privacy notice

Adding categories you do not need is one of the most common ways to make a SOC 2 harder than it has to be. Ask your buyer what they want before you scope.

The criteria themselves have been stable since 2017. The AICPA refreshed the points of focus in 2022 to reflect current technology and threats; the criteria did not change, the implementation guidance did.

Then there is Type I versus Type II. Type I says the controls were designed appropriately on a given date. Type II says they operated effectively across a period, with the auditor sampling evidence throughout, so you cannot stand controls up the week before. We have a fuller breakdown in SOC 2 Type I vs Type II.

Who is asking, and what they will accept

This is usually the deciding factor, and it is worth asking the buyer directly rather than guessing.

Lean ISO 27001 if: your buyers are in Europe, the UK, India, Asia-Pacific or the Middle East; you are selling into government, banking or healthcare procurement; you need one credential that travels across many countries; or a tender explicitly names it. ISO 27001 is also the more natural base if you expect to add ISO 22301, ISO 27701 or similar later, because they share the same management-system skeleton.

Lean SOC 2 if: your buyers are US or Canadian, particularly US-headquartered SaaS companies; their vendor-risk team wants to see what the auditor tested and found, not just that you passed; or you need something in front of a procurement gate quickly, in which case a Type I gives you a document while the Type II period runs.

Do both if: you sell on both sides of the Atlantic, or you are moving upmarket into enterprise accounts that ask for whichever they are used to. This is common, and it is far less than twice the work.

A useful shortcut: ISO 27001 tends to satisfy procurement, SOC 2 tends to satisfy security teams. If the questionnaire came from a security engineer with follow-up questions, they probably want the report.

Not sure which applies? Our framework chooser takes about a minute, and the readiness check tells you how far along you already are.

Where the work overlaps

Substantially, which is the good news.

Access control, onboarding and offboarding, change management, vendor management, incident response, logging and monitoring, encryption, backup, secure development and risk assessment all appear in both. Build the control once and it produces evidence for both audits.

Here is roughly how the two line up. There is no official AICPA-to-ISO crosswalk, so treat this as a working map for planning rather than something to hand an auditor:

The practical read: the Security category maps almost entirely onto controls you would implement for ISO 27001 anyway. The optional categories map cleanly too. What does not appear on the right-hand side is the ISMS machinery, and what does not appear on the left is the system description.

What does not transfer:

• The ISMS machinery. Statement of Applicability, formal risk methodology, internal audit programme, management review. SOC 2 does not ask for these as artefacts. ISO will not certify without them.
• The system description. SOC 2 requires a written description of your system (infrastructure, software, people, procedures, data) that the auditor opines on. ISO has no equivalent.
• The evidence rhythm. SOC 2 Type II wants continuous evidence across the period, sampled. ISO wants the management system demonstrably operating, judged more holistically.
• Who signs. A certification body cannot issue a SOC 2 report; a CPA firm cannot issue an ISO certificate. They are different professions.

Your cloud provider, and who is responsible for what

This is where the two frameworks diverge in a way that catches teams out, and it is the part most comparison articles skip.

You run on AWS, Azure or GCP. Your SOC 2 has to say something about that. Under SOC 2 those are subservice organisations, and you pick one of two treatments:

• Carve-out, which is what almost everyone does. The provider sits outside your report's boundary. You disclose complementary subservice organisation controls (CSOCs): the controls you are relying on them to perform. Your auditor does not test those; you are asserting you have a reasonable basis to expect they exist, usually by reviewing the provider's own SOC report.
• Inclusive, where the provider is inside your scope and your auditor tests their controls too. It requires their cooperation, which hyperscalers do not give.

Related, and frequently missed: complementary user entity controls (CUECs). These are the controls your customers have to run for your criteria to hold, and you must list them. Configuring SSO, managing their own admin accounts, reviewing their access. If a customer's security team reads your report properly, CUECs are the section they will ask about, because it tells them what they are still on the hook for.

ISO 27001 handles the same reality differently. There is no carve-out mechanism. Instead you set an ISMS scope, state what is inside it, and manage the provider through the supplier controls: A.5.19 to A.5.22 on supplier relationships, agreements, ICT supply chain and service monitoring, plus A.5.23 for cloud services specifically. The obligation is ongoing management rather than a disclosure in a report.

The practical consequence: a SOC 2 report shows a reader exactly where your responsibility ends and theirs begins. An ISO certificate does not, which is part of why a security team that has read both often prefers the report.

The sequence that avoids duplicate work

If you know you need both, do not run them as two projects.

1. Ask the buyer which one unblocks the deal. That one goes first. Everything else follows from a real date.
2. Build a single control set, mapped to both Annex A and the Trust Services Criteria from day one. Retrofitting a mapping afterwards is where teams lose weeks.
3. Stand up evidence collection early, because SOC 2 Type II grades you on a period you cannot go back and re-run. Even if ISO is first, start collecting as though Type II were running.
4. Run the ISMS layer once. Risk assessment, internal audit and management review serve ISO directly and give SOC 2's CC3 and CC4 criteria strong evidence.
5. Sequence the audits, typically ISO Stage 1 and Stage 2, then the SOC 2 observation period, or a SOC 2 Type I first if a deal needs a document immediately.

The pattern that works: one control set, two audiences, two audit trails.

You already have one and the buyer wants the other

The most common situation we are called into, and the work is asymmetric in a way worth knowing before you plan.

You have ISO 27001, they want SOC 2. The lighter direction. Your controls, risk assessment and internal audit evidence largely carry over. What you have to build is the system description, the CUEC and CSOC disclosures, and evidence collection running continuously across the observation period. If a deal is waiting, a Type I gives you a document quickly, then the Type II period runs behind it.

You have SOC 2, they want ISO 27001. The heavier direction, because SOC 2 never made you build the management system. You need a scope and boundary, a documented risk methodology with a risk register and treatment plan, a Statement of Applicability justifying all 93 Annex A controls including exclusions, an internal audit programme, and a management review with records. Your controls are mostly there. The governance around them is not, and that is exactly what Stage 1 examines.

Either direction, do the gap assessment against the target framework before committing to a date. The gap is rarely where teams expect.

Four mistakes worth avoiding

• Scoping to impress rather than to pass. A narrow, honest ISO scope that genuinely covers the product beats an ambitious one you cannot evidence. The same goes for SOC 2 categories.
• Treating Annex A as a to-do list. It is a control menu driven by your risk assessment. Applying all 93 without justification creates work an auditor never asked for.
• Assuming a certificate answers a security team. If a buyer wanted the detail in a Type II report, an ISO certificate will trigger a follow-up questionnaire rather than close one.
• Letting the evidence lapse between cycles. A SOC 2 report with a gap and no bridge letter, or a missed ISO surveillance audit, gets flagged in exactly the vendor review you bought it to clear.

Where Singahi fits

We run both, and we plan them together when you need both. That means one gap assessment against both frameworks, one control set mapped to Annex A and the Trust Services Criteria, one evidence programme, and support through the audits: Stage 1 and Stage 2 with your certification body, or the readiness and auditor coordination for a Type I or Type II.

We do not issue the certificate or the opinion; an accredited certification body and an independent CPA firm do that, and that independence is the point. We get you ready, keep you ready, and stay on the call when the auditor has questions.

See ISO 27001, SOC 2, or talk to a practitioner about which one your buyer actually needs.

FAQ

Is ISO 27001 or SOC 2 better?

Neither. They answer different questions for different audiences. ISO 27001 certifies that you run a working information security management system and is recognised globally, especially in Europe, the UK, India and Asia-Pacific. SOC 2 produces a detailed report for a US and Canadian audience whose security teams want to read what the auditor tested. The better question is which one your buyer will accept.

Can you be SOC 2 certified?

No. SOC 2 is an attestation, not a certification. An independent CPA firm issues a report containing their opinion on your controls. Any vendor claiming to be "SOC 2 certified" is using the term loosely, and a careful buyer will notice.

Does ISO 27001 cover SOC 2?

Not automatically, but the overlap is large. Access control, change management, incident response, vendor management, logging, encryption and risk assessment satisfy requirements in both. What ISO adds is the management system (Statement of Applicability, internal audit, management review), and what SOC 2 adds is the system description and continuous evidence across the observation period.

Which should we do first?

Whichever unblocks the deal in front of you. If a US buyer is waiting, a SOC 2 Type I gives you a document quickly while the Type II period runs. If you are selling into Europe, the UK or public-sector procurement, ISO 27001 is usually the credential named in the tender. If both are coming, build one control set mapped to both from the start.

How long is each one valid?

An ISO 27001 certificate runs on a three-year cycle, with a surveillance audit in each of the first two years and a recertification audit in year three. A SOC 2 report has no formal expiry, but buyers generally expect one covering the last 12 months. A management-signed bridge letter covers the gap between the report's period end and today, and auditors typically expect it to span no more than about 90 days.

Do we need both ISO 27001 and SOC 2?

Only if your buyers do. Companies selling across both North America and Europe frequently end up with both, because procurement asks for whichever their market recognises. Because the control sets overlap heavily, doing both is meaningfully less than twice the work, provided you map to both frameworks from the start rather than retrofitting the second one later.

What is the climate change amendment, and does it affect us?

ISO 27001:2022/Amd 1:2024, published in February 2024, added a requirement to clause 4.1 that you determine whether climate change is a relevant issue for your ISMS, and a note to clause 4.2 that interested parties may have climate-related requirements. It applies immediately with no transition period. You may conclude climate change is not relevant, provided the determination is documented and reasoned. Auditors are checking that you considered it.

Is an ISO 27001:2013 certificate still valid?

No. ISO 27001:2013 certificates expired on 31 October 2025 regardless of the expiry date printed on them, and there is no late-transition route. Recertification means a full Stage 1 and Stage 2 audit against ISO 27001:2022.