SOC 2 or ISO 27001 first? A commercial question wearing a technical costume

This is the whole method, and it costs nothing. Go through the deals that slowed down or died in security review over the last year and find what the questionnaire or the procurement team actually named. Not what you assume they want — what they wrote down.

As a rough market pattern: North American technology buyers usually ask for SOC 2, and increasingly for Type 2 specifically. European, British, Indian, Japanese and Australian buyers, and enterprise procurement in most of the rest of the world, usually ask for ISO/IEC 27001. Regulated buyers often ask for whichever their own regulator or auditor recognises.

But that is a pattern, not your data. Your pipeline is a better predictor than any general rule, because it reflects the segment you actually sell into rather than the global average. If your five stalled deals name SOC 2 four times, the argument is over.

The failure mode here is choosing the one you find more comfortable. Teams with strong engineering instincts often prefer SOC 2 because it feels like describing systems rather than building governance; teams with process instincts often prefer ISO. Both rationalisations produce a real, expensive artefact that your buyers did not ask for.

This is the difference that matters most in practice and gets the least attention.

An ISO 27001 certificate is a short public document. It names the standard, the scope and the dates, it can sit on your website, and a customer can verify it independently with the certification body or the accreditation body behind it. It answers "are they certified?" instantly and answers almost nothing else — which is why a careful buyer will also ask for your Statement of Applicability.

A SOC 2 report is a substantial confidential document. It contains your system description, the controls, the tests the auditor performed, the results including any exceptions, and an opinion. You cannot publish it; it goes out under NDA, usually one prospect at a time. It answers a great many questions in detail, and it requires the reader to actually read it.

So they do different jobs in a sales process. A certificate clears a checkbox at scale. A report satisfies a reviewer in depth, and creates ongoing work — every prospect needs an NDA and a copy, and you will be asked for a bridge letter whenever your report period and their year-end do not line up.

If both are eventually needed, sequencing is mostly a question of which clock you can start sooner.

ISO 27001 is front-loaded. You build the management system — scope, risk assessment, Statement of Applicability, internal audit, management review — and then the two-stage audit happens against something that already exists. The elapsed time is mostly yours to compress, and a lot of it is work you control.

A SOC 2 Type 2 has a waiting period that nobody can compress: the observation window over which the auditor samples your controls. You can have every control perfect on day one and still be months from a report, because the report is about elapsed operation. That asymmetry is the single strongest argument for starting the SOC 2 clock early if you know you will need one — and for reaching for a Type 1 only when a specific deal is blocked right now.

A practical consequence: if you need both and your pipeline is mixed, starting the Type 2 observation window while you build the ISO management system often costs less total time than doing either one cleanly first.

The controls overlap heavily. Access control, change management, logging and monitoring, supplier management, incident response, HR security and encryption appear in both, and one well-designed control with one evidence trail can serve both. This is the bulk of the work in either programme, which is why the second framework costs far less than the first.

What does not overlap is the assessment machinery around the controls. ISO wants a management system as an object in its own right: a defined scope, a repeatable risk method, an SoA justifying every inclusion and exclusion, internal audit and management review with records. SOC 2 wants a system description, a mapping to the criteria you selected, and continuous evidence across an observation window.

Neither of those substitutes for the other. Budget them separately, and design the controls once.

The first is thinking one is more rigorous. They are differently shaped, not ranked. ISO tests whether a management system exists and functions; SOC 2 tests whether specific controls operated across a period and reports the exceptions in detail. A sceptical reader learns more from a SOC 2 report than from a certificate — and a certificate evidences a governance discipline that a SOC 2 does not directly examine.

The second is the word "certified". There is no SOC 2 certificate and no SOC 2 certification body; a SOC 2 is an attestation report and saying you are "SOC 2 certified" is wrong in a way that informed buyers notice. Conversely, an ISO 27001 certificate from an unaccredited body is a document rather than an assurance — if you are choosing the ISO route, accreditation is the thing to check about your certification body.