60–90% Control Overlap: ISO 27001 vs SOC 2 for Security Leaders

ISO 27001 and SOC 2 title card

SOC 2 is a US attestation report built for buyer scrutiny, delivered as a CPA opinion. ISO 27001 is an international ISMS certification, delivered as an accredited certificate. The choice usually isn’t technical: it’s whichever deliverable your buyers demand, and organisations selling into both American and international markets typically end up running both, on a shared set of controls.

TL;DR:

  • Most organizations see 70 to 80% control overlap between ISO 27001 and SOC 2, easing the process of preparing for both frameworks simultaneously.
  • ISO 27001 emphasizes maintaining a management system with ongoing governance requirements, while SOC 2 focuses on demonstrating controls’ effective operation over time.
  • US buyers usually prefer SOC 2 reports for enterprise SaaS procurement, whereas ISO 27001 is more valued in Europe, the UK, and regulated sectors.
  • Building a joint control catalog and coordinating audits can reduce first-year compliance costs by approximately 30 to 40 percent.
  • Effective preparation relies on early scoping, continuous evidence collection, role-based training, and selecting auditors familiar with both standards.
Oxfordcentre
Build Security Skills Across Your Team
Oxfordcentre delivers expert-led, globally accredited training in flexible formats for organisations developing workforce capability.

Table of Contents

ISO 27001 compliance: what it certifies and what it demands

ISO 27001 certifies that an organisation runs a functioning Information Security Management System, or ISMS, not just a list of technical controls. The current edition, ISO/IEC 27001:2022, sets out mandatory management requirements in clauses 4 to 10, covering leadership commitment, risk assessment, resourcing, and continual improvement. Annex A then supplies a catalogue of security controls, organised into four themes: organisational, people, physical, and technological.

Three artefacts trip up more first-time applicants than any technical gap:

  • Statement of Applicability (SoA): a documented justification for every Annex A control you include or exclude, tied back to your risk assessment.
  • Internal audit programme: evidence that someone inside the organisation checked the ISMS is actually working, before the external auditor ever shows up.
  • Management review: minuted, top-level review of ISMS performance, typically at least annually.

Certification itself runs in two stages. Stage 1 is a documentation review, where the certification body checks your SoA, policies, and risk treatment plan exist and hang together. Stage 2 tests whether those controls operate in practice, through interviews, sampling, and evidence walkthroughs. Pass both, and you get a certificate valid for three years, subject to annual surveillance audits that check the ISMS hasn’t quietly decayed. Most mid-sized organisations need four to nine months of internal preparation to reach Stage 2 readiness, depending on how mature their existing security programme already is.

SOC 2 requirements: Trust Services Criteria and report types

SOC 2 is an AICPA attestation built around the Trust Services Criteria (TSC). Security is mandatory; Availability, Processing Integrity, Confidentiality, and Privacy are optional categories you add depending on what your service actually does. A payments processor will usually add Processing Integrity; a health tech vendor often adds Privacy.

The report comes in two flavours, and mixing them up in a sales conversation is an easy way to lose a buyer’s trust:

  • Type I examines whether your controls are suitably designed at a single point in time, essentially a snapshot.
  • Type II tests whether those controls actually operated effectively over a review period, usually three to twelve months.

Type II carries far more weight with sophisticated buyers because it demonstrates sustained operation rather than a well-written policy binder. The finished report itself is dense: a system description, the auditor’s testing procedures for each control, and any exceptions found along the way. That level of detail is exactly why it circulates under NDA rather than as a public badge. For SaaS and cloud companies, the most common scoping decision is starting with Security plus Availability, then adding Confidentiality or Privacy once enterprise or healthcare prospects start asking for it.

Where the frameworks overlap: controls you can reuse

Here’s the number that changes the whole conversation: practitioner mapping studies consistently find 60 to 90% control overlap between ISO 27001’s Annex A and the SOC 2 Trust Services Criteria, with 70 to 80% reusability being the figure most organisations actually experience once they map their own environment.

That overlap shows up concretely in the controls that matter most to both auditors:

  • Access control and least-privilege enforcement
  • Change management and code deployment approval
  • Incident response planning and post-incident review
  • Vulnerability management and patch cadence
  • Vendor and third-party risk assessment

Mapping the two frameworks means building a single control catalogue and tagging each control against both Annex A and the relevant TSC criterion, then pulling evidence once and presenting it to both auditors. AICPA even publishes its own crosswalk mapping between the TSC and ISO 27001, which is worth reviewing before you build your own spreadsheet from scratch.

The practical payoff is straightforward: a firewall rule review, an access recertification, or a vendor questionnaire collected for one framework rarely needs collecting twice. Where the frameworks genuinely diverge isn’t in the technical controls at all. It’s in governance. ISO 27001 wants a management system wrapped around those controls, complete with the SoA and internal audit records; SOC 2 wants proof those same controls held up under sustained testing. That distinction sets up the next question almost every decision-maker gets wrong at first.

ISO 27001 and SOC 2 control overlap

Key differences between ISO 27001 and SOC 2 that shape procurement

The most consequential difference isn’t a control gap at all. It’s the deliverable. ISO 27001 produces a public, verifiable certificate that anyone can check against the certification body’s register. SOC 2 produces a long, detailed report that most organisations keep confidential and only share with prospects under NDA. A government tender in the EU will happily accept “we’re ISO 27001 certified” as a one-line claim. A US enterprise procurement team will usually ask to read the actual SOC 2 report, exceptions and all, before signing anything.

That difference cascades into everything else:

  • Governance load: ISO 27001 demands ongoing management-system obligations (SoA maintenance, scheduled internal audits, documented management review) that persist for the life of the certificate. SOC 2 has no equivalent standing governance requirement; it simply re-tests your controls each audit period.
  • What “adding scope” costs you: bolting Availability or Processing Integrity onto a SOC 2 audit adds a defined, bounded set of extra controls to test. Expanding ISO 27001’s scope means reworking your ISMS boundary and, often, your entire risk assessment.
  • Geographic pull: SOC 2 dominates US enterprise and SaaS procurement almost by default. ISO 27001 carries far more weight across the EU, UK, and APAC, particularly in government and regulated-sector tenders where an internationally recognised certificate is often a hard requirement rather than a nice-to-have.
  • Substitutability, or the lack of it: buyers who specifically ask for a SOC 2 report will often not accept an ISO 27001 certificate in its place, and vice versa. The frameworks are not interchangeable currency in a procurement conversation, even where the underlying controls are nearly identical.

Pro Tip: Before you commit budget to either framework, pull your last twelve months of security questionnaires and count how many explicitly named “SOC 2 report” versus “ISO 27001 certificate”. That count is a better guide to your first move than any framework comparison chart.

Which one should you choose? A practical decision guide

Procurement geography decides this more often than any technical merit argument. If most of your revenue comes from US enterprise or SaaS buyers, expect SOC 2 to appear on nearly every vendor security questionnaire you receive. If you’re selling into the EU, UK, Middle East, or APAC, especially into government, finance, or critical infrastructure, ISO 27001 tends to be the non-negotiable line item instead.

Organisational stage matters almost as much as geography:

  • Early-stage, pre-product-market-fit: hold off on formal certification. Build basic security hygiene, access controls, and an incident response plan first; certification without operational maturity behind it just produces a stressful, expensive audit.
  • US-only SaaS with enterprise prospects asking questions: start with SOC 2 Type I to get a report in hand quickly, then move to Type II once you have a track record worth testing.
  • Selling into EU or regulated buyers, or bidding on government contracts: start with ISO 27001, since the certificate itself is often a gating requirement before a tender is even opened.
  • Global pipeline with both American and international prospects in the deal flow: build one mapped control set from day one and pursue both, sequenced rather than run as separate projects.

Choosing the assurance your buyers actually ask for beats chasing whichever framework sounds more rigorous on paper. A technically excellent ISO 27001 programme does nothing for a deal stuck because procurement wants a SOC 2 report they can read line by line.

Running both: sequencing, joint audits and realistic savings

The pattern that works best for most dual-market organisations is SOC 2 Type I first, then ISO 27001 Stage 1 and Stage 2, then SOC 2 Type II. That order gets a report into sales conversations fast, builds the governance layer ISO 27001 demands, and lets the SOC 2 Type II observation window run over a period where the ISMS is already operating, so evidence serves both audits at once.

Joint programmes work because they’re engineered as one project rather than two:

  • One control catalogue, tagged against both Annex A and the Trust Services Criteria from the start
  • An auditor or audit firm that offers combined SOC 2 and ISO 27001 engagements, cutting duplicate scoping calls
  • A GRC platform configured to tag a single piece of evidence, an access review or a patch log, against both frameworks simultaneously

Done deliberately, coordinated programmes can cut first-year audit and programme spend by roughly 30 to 40% compared with running two fully separate tracks. That figure assumes genuine joint design from the outset, not two teams working in isolation and comparing notes afterwards. Bolt ISO 27001 onto an existing SOC 2 programme without restructuring the evidence pipeline first, and you’ll capture only a fraction of that saving.

How to prepare for ISO 27001 and SOC 2 audits

  1. Scope it first. Define your ISMS boundary (which business units, systems, and locations are in scope) and, separately, draft the SOC 2 system description covering the services, infrastructure, and people the report will cover.
  2. Build the mandatory artefacts. For ISO 27001, that’s the Statement of Applicability, internal audit records, and management review minutes. For SOC 2, it’s the finished system description and a signed management assertion.
  3. Collect evidence continuously, not at audit time. Access logs, change tickets, patch records, incident tickets, and signed vendor contracts all need to exist before an auditor asks for them, not scrambled together the week before fieldwork.
  4. Select your auditor or certification body early, and ask directly whether they run combined SOC 2 and ISO 27001 engagements before booking separate ones.
  5. Schedule your observation window deliberately. A SOC 2 Type II period and an ISO 27001 surveillance cycle can often overlap, so evidence collected once covers both.
  6. Close capability gaps with targeted training for the people who actually own these controls, rather than a generic security awareness module that nobody remembers by audit day.

Pro Tip: Assign one named owner per control category (access, change, vendor risk, incident response) before scoping starts. Audits that fail on evidence gaps almost always trace back to nobody being accountable for that specific control in the first place, not to the control being poorly designed.

Oxford Centre perspective: training closes the gap auditors actually flag

Oxford Centre perspective: training closes the gap auditors actually flag — overview diagram

Most ISO 27001 and SOC 2 findings aren’t missing controls. They’re controls that exist on paper but nobody executing them consistently, because the person responsible was never properly trained on what the ISMS or the TSC actually requires of their role. Role-based training for leadership, IT operations, and risk teams closes that gap directly: leaders learn what management review has to demonstrate, IT operations learns what “consistent” looks like to an auditor, and risk owners learn how to write a defensible Statement of Applicability rather than a generic one copied from a template.

Organisations that train people before the audit, not during it, consistently report shorter readiness windows and fewer internal audit nonconformities to remediate under pressure.

— Sam

Prepare your team for certification with Oxford Centre training

Oxfordcentre offers training aimed at helping the people who own your controls to understand what an ISO 27001 auditor or SOC 2 assessor will ask them. That’s the gap between a documented policy and a control someone can defend under questioning.

Oxfordcentre

Course themes include ISMS fundamentals for leadership and risk teams, hands-on risk assessment workshops for building a defensible Statement of Applicability, and internal auditor training. Programmes are offered in various formats and can be tailored to your organisation’s chosen framework(s). If you’re scoping a joint SOC 2 and ISO 27001 programme, understanding which operational metrics are safe to disclose to buyers during procurement is worth reviewing alongside your training plan. Contact Oxfordcentre to discuss a corporate training programme scoped to your certification timeline.

Authoritative primary sources to consult

Sources

Register Now