SOC 2 and ISO 27001, and which buyers ask for which
Neither is a privacy certification and neither substitutes for a data processing agreement, a lawful basis or a transfer mechanism. Both attest to an information security management approach, assessed differently, for different audiences. If a customer's legal team is asking about GDPR and your answer is a SOC 2 report, you have answered a different question, and experienced reviewers notice. Choose based on who asks and what they will accept, not on which sounds stronger.
What is the actual difference?
One is an attestation report, the other is a certificate. SOC 2 is an engagement performed under AICPA standards by a licensed CPA firm, producing a report containing the auditor's opinion, a description of your system, the criteria tested and any exceptions found. You send it to customers, usually under a non-disclosure agreement, and they read it. There is no pass mark, because the deliverable is an opinion rather than a certificate. There is a logo: the AICPA registers a SOC for Service Organizations mark that a service organisation holding an unqualified report may apply to use under its guidelines. It signals that a report exists rather than standing in for one, which is the real contrast with an ISO certificate.
ISO/IEC 27001 is certification against a management system standard by an accredited certification body. The output is a public certificate with a scope statement, backed by a Statement of Applicability that records which Annex A controls apply and why any are excluded. The standard requires the management system machinery: risk assessment, internal audit, management review and continual improvement. The current edition is the 2022 revision, and the transition period for the previous edition has closed, so a certificate against the older version is no longer current.
The practical difference for buyers is what they get to see. A SOC 2 Type 2 report shows them the exceptions the auditor found, which is genuinely informative. An ISO certificate shows them that a body assessed your system and the scope it covered, and the interesting detail is in the scope statement rather than the certificate.
Which one will your buyers ask for?
It divides largely by geography and by sector. US enterprise procurement asks for SOC 2 Type 2 as a default and often will not accept an alternative. European, Middle Eastern and Asian buyers, and most public sector procurement, ask for ISO 27001. Companies selling to both eventually hold both, which is less duplicative than it sounds because the underlying controls overlap heavily and only the evidence format differs.
Sector schemes sit on top rather than replacing these, and they arrive with the customer rather than by choice.
| Scheme | What it is | Typical asker | Notable requirement |
|---|---|---|---|
| SOC 2 Type 1 | Opinion on control design at a point in time | A buyer who needs something now | Design only, no evidence of operation |
| SOC 2 Type 2 | Opinion on operation over a period | US enterprise procurement | An observation window, commonly three to twelve months |
| ISO/IEC 27001 | Certification of a management system | European, APAC and public sector buyers | Internal audit and management review, plus surveillance audits |
| ISO/IEC 27701 | Standalone privacy management system since the 2025 revision | Buyers focused on processor obligations | Controller and processor roles distinguished, 2019 edition retires October 2028 |
| Cyber Essentials Plus | UK scheme with hands-on technical verification | UK public sector and some primes | Verified patching and configuration, not documentation |
| Sector schemes such as HITRUST or C5 | Industry or national frameworks | US healthcare, German cloud buyers | Prescriptive control sets with less scoping freedom |
What does scope really control?
Almost everything about the cost and the credibility. Both schemes let you define what is covered, and a narrow scope covering one product in one environment is faster, cheaper and perfectly legitimate, provided the scope statement says so. The failure is a narrow scope presented as though it covered the organisation, because a reviewer reads the scope statement first and a mismatch damages trust more than having no certificate at all.
For SOC 2, the equivalent lever is which trust services criteria you include. Security is always in scope. Availability, confidentiality, processing integrity and privacy are optional, and adding the privacy criteria is a considerably larger commitment than teams expect, because it pulls in notice, choice, retention and disposal practices.
Scope also decides how much of your estate has to behave consistently. A control that is in place for the flagship service and absent from three internal tools is an exception if those tools are in scope and irrelevant if they are not, so drawing the boundary is a decision to make with the auditor early rather than during fieldwork.
Which controls generate the most findings?
Access reviews, change management and vulnerability remediation, in roughly that order, because all three are recurring rather than one-off. Access reviews fail because the review happened and left no artefact, or because leavers retained access in a system outside the joiner-mover-leaver process. Change management fails on the exceptions: the emergency deploy that skipped review, with no record explaining why.
Vulnerability management fails in a way this cluster's sibling guide on container scanning describes in detail. Organisations write a control committing to remediate critical findings within a fixed period, then run a container scanner that produces hundreds of findings from base images, many with no available fix. The stated commitment and the actual backlog diverge immediately, and the auditor tests the commitment you wrote rather than the one you meant.
The fix is to write the control to match a policy that survives a real release: gate on findings with a fix available, treat base image currency as the measurable target, and record suppressions with a reason and an expiry. Auditors accept a risk-based policy that is consistently applied far more readily than an aspirational one that is routinely breached, and the second option guarantees a finding.
How much of this can the platform generate for you?
More than most teams use. Evidence that a control operated is a by-product of good engineering: pull request records show change approval, pipeline logs show that tests and scans ran, infrastructure as code shows configuration state over time, identity provider reports show access grants and removals, and ticket history shows incident handling. A control instrumented this way is cheap to evidence every year rather than expensive once.
The controls that stay manual are the management system ones. Risk assessment, internal audit, management review and competence and awareness records require someone to do a thing on a schedule and record it. Under ISO 27001 these four are mandatory clauses rather than Annex A options, and they are the most common reason a first certification attempt slips. Supplier assessment is the same kind of recurring manual work, but it sits in Annex A as controls A.5.19 to A.5.22, so it is selected or excluded through the Statement of Applicability like any other Annex A control.
The test worth running this week: pick three controls you believe are strong and try to produce twelve months of evidence for each without asking anyone to recall anything. Whatever you cannot produce is the work, and it is usually recording rather than control.
Does either one help with GDPR?
Partly, and only for one obligation. Article 32 requires security appropriate to the risk, and a certified or audited security programme is credible evidence towards that. Article 42 also contemplates approved certification mechanisms as a way of demonstrating compliance, but the schemes discussed here are not those, and neither SOC 2 nor ISO 27001 was designed to demonstrate GDPR compliance.
They do nothing for lawful basis, records of processing, subject rights, retention, transfers or breach notification. A company can hold both and be unable to answer an access request or produce a data map, which is a common combination because the two programmes are usually run by different people with different budgets.
So sequence them by who is asking. If deals are stalling on a security questionnaire, the certification work is the right investment. If a customer's legal team is asking about transfers and sub-processors, no amount of audit work answers them, and the guides on those subjects describe what does.
Common questions
- What is the difference between SOC 2 and ISO 27001?
- SOC 2 is an attestation engagement performed by a licensed CPA firm under AICPA standards, producing a private report with the auditor's opinion and any exceptions found, which you share with customers under NDA. ISO/IEC 27001 is certification of an information security management system by an accredited body, producing a public certificate with a scope statement and requiring risk assessment, internal audit and management review on an ongoing cycle.
- Does SOC 2 or ISO 27001 prove GDPR compliance?
- No. Both speak to Article 32, security appropriate to the risk, and are credible evidence for that one obligation. Neither addresses lawful basis, records of processing, subject rights, retention, international transfers or breach notification. Organisations frequently hold both certifications and still cannot answer an access request or produce an accurate data map, because the two programmes are usually owned by different teams.
- Which certification do enterprise buyers ask for?
- It splits by geography. US enterprise procurement asks for SOC 2 Type 2 by default and often will not accept a substitute. European, Middle Eastern, Asian and most public sector buyers ask for ISO 27001. Companies selling into both markets usually end up holding both, which duplicates less work than it appears to because the underlying controls overlap heavily and only the evidence format differs.
- What is the difference between SOC 2 Type 1 and Type 2?
- Type 1 is an opinion on whether controls were suitably designed at a single point in time. Type 2 adds an opinion on whether they operated effectively across an observation window, commonly between three and twelve months. Type 2 is what most enterprise buyers mean when they ask for SOC 2, and the length of the observation window is the main driver of how long a first report takes to obtain.
- Why does vulnerability management cause audit findings?
- Because organisations write a commitment to remediate critical findings within a fixed period, then deploy a container scanner that reports hundreds of base image findings, many with no upstream fix available. The written control and the real backlog diverge at once, and the auditor tests what you wrote. A risk-based policy that gates on findings with an available fix, tracks base image freshness and expires suppressions is easier to pass and easier to keep.
