SOC 2 and ISO 27001: which one your buyers actually require

The request usually arrives from an enterprise procurement team or a European buyer, and it is short: do you have ISO 27001? If you already hold a SOC 2 report, the instinct is to send that instead and hope it lands. Sometimes it does. Often it does not, and the reason is worth understanding before you decide whether to run both.

They are different kinds of thing

SOC 2 is a report. A licensed CPA firm examines your controls and issues an opinion. What you hand a buyer is a document, typically thirty to eighty pages, containing the auditor’s opinion, management’s description of the system, and in a Type II the tests performed and their results. The buyer reads it. It is North American in origin and dominant in United States software procurement.

ISO 27001 is a certification. An accredited certification body audits your information security management system and, if it passes, issues a certificate. What you hand a buyer is the certificate plus your Statement of Applicability. The buyer usually does not read anything else. It is the international standard and it is what European, Middle Eastern and Asian enterprise buyers ask for by name.

That difference matters more than the control overlap. A SOC 2 report invites the buyer to form their own view of your controls. A certificate asserts that somebody accredited already did. Some procurement processes are built to consume one and not the other, and no amount of explaining will convert them.

What the overlap actually is

The 2022 revision restructured Annex A into 93 controls across four themes: 37 organizational, 8 people, 14 physical and 34 technological. A large share maps cleanly onto the Trust Services Criteria. Access control, cryptography, logging and monitoring, supplier relationships, incident management, business continuity and secure development all appear on both sides in recognizable form.

What does not map is the management system itself. ISO 27001 requires a scoped information security management system with defined boundaries, a documented risk assessment and treatment methodology, a Statement of Applicability justifying every included and excluded control, measurable objectives, internal audits, and a management review with leadership participation on record. SOC 2 cares that controls operate. ISO cares that a system exists which decides which controls should operate, checks that they do, and improves them on a cycle.

That management system is the real work, and it is the part a company with a good SOC 2 report is usually missing.

Two dates worth knowing

The transition from the 2013 version closed on 31 October 2025. Certificates against the old version have expired, so any certificate a vendor shows you today should be against ISO/IEC 27001:2022. It is a fair question to ask a supplier, and a fair one to expect from a buyer.

The certification cycle also runs differently from a SOC 2 report. Certification is a three year cycle: a Stage 1 documentation review, a Stage 2 audit of implementation, then surveillance audits in years two and three and a full recertification in year three. A SOC 2 Type II covers a defined observation window and is repeated annually. Budget and calendar planning are not the same shape.

Should you run both?

It depends entirely on who is asking, and the honest answer is often no.

Run SOC 2 alone if your buyers are United States software companies, and nobody has asked for ISO by name. This is most early stage companies, and adding a second framework before a buyer requires it is a cost with no revenue attached.

Add ISO 27001 when a specific deal or market requires it: European or international enterprise buyers, a procurement process that only accepts certification, or a customer contract that names it. The trigger should be a named deal, not a general sense that more compliance is better.

If you are running both, run them off one control set and one evidence pipeline. Doing them as separate projects with separate owners is how organizations end up with two sets of policies that contradict each other, and an auditor from either side will find the contradiction faster than you will.

The order that works

1. Establish the scope boundary once and use it for both. Systems, locations, people, and the services in scope. A mismatched boundary between the two is a finding waiting to happen.
2. Build the risk assessment to ISO’s expectations even if you only need SOC 2 today. It is more prescriptive, it satisfies both, and retrofitting it later is more work than doing it once.
3. Map the criteria and the Annex A controls to shared controls, so one access review and one training record serve both programs.
4. Sequence by whichever deal is real. Whichever buyer is waiting sets the order; the second framework follows on the shared foundation.

One honest limit

Control and Function is not a certification body and does not issue ISO 27001 certificates, in the same way we are not a CPA firm and do not issue SOC 2 reports. Certification comes from an accredited body you engage directly. What we do is build the control set, the risk methodology and the evidence so that one program answers both, and manage the process through to the audit.

Where we fit

Control and Function runs SOC 2 readiness as a fixed-fee engagement. We are not an audit firm and we do not issue SOC 2 reports: we build the program, prepare the evidence, refer you to a licensed CPA firm, and manage the audit through report issuance. We never assess our own preparation work, and we take nothing from any firm we introduce.

If you are somewhere between “a buyer just sent us a security review” and “we need a report by a deadline,” a 30-minute call will tell you where you actually stand. Book a readiness call or email hello@controlandfunction.com.