What is the difference between SOC 2 and ISO 27001, and what does an auditor accept as evidence?

They are not two versions of the same thing

Start by getting the category right, because the single most common error in this answer is calling SOC 2 a certification. It is not one, and the distinction has practical consequences.

SOC 2 is an attestation engagement performed by a licensed CPA firm under standards set by the AICPA. You describe your own system and its boundary, select which of the Trust Services Criteria apply — security always, with availability, confidentiality, processing integrity and privacy chosen — and state the controls you implemented to meet them. The auditor tests those controls and issues a report containing an opinion. Nobody hands you a certificate and there is no registry to look you up in; what you have is a document, usually shared under a non-disclosure agreement, that a reader is expected to read. A Type 1 report opines on whether the controls were suitably designed at a point in time. A Type 2 opines on whether they operated effectively throughout a stated period, and includes the auditor's tests and their results. Type 2 is the one buyers mean.

ISO 27001 is a certifiable international standard, and what gets certified is an information security management system rather than a set of technical measures. Certification comes from an independent certification body, and credible ones are themselves accredited by a national accreditation authority — worth checking, since unaccredited certificates exist and are worth very little. The standard requires you to define the ISMS scope, run risk assessment and treatment, justify inclusion or exclusion of the Annex A controls in a Statement of Applicability, and operate the management machinery: objectives, internal audit, management review, corrective action, continual improvement. ISO/IEC 27001:2022 restructured Annex A into 93 controls across four themes — organisational, people, physical and technological — with ISO/IEC 27002 giving implementation guidance. Assessment runs in two stages, documentation then implementation, on a three-year certificate cycle with surveillance audits in between.

So the real differences are these. ISO prescribes the management system and lets you justify which controls apply; SOC 2 prescribes the criteria and lets you define the system and the controls. ISO gives you a short certificate plus a scope statement; SOC 2 gives you a long report a reader can interrogate, including the failures. ISO's cycle is continuous by construction, while SOC 2's continuity comes from commissioning consecutive periods with no gap between them. Buyers in North America tend to ask for SOC 2; buyers elsewhere and in the public sector tend to ask for ISO. The underlying control work overlaps heavily, which is why organisations needing both run one control set mapped to two frameworks rather than two programmes.

Because you write the scope, someone must read it

The self-defined scope is not a loophole to exploit, but it is the reason "we are SOC 2 compliant" carries almost no information on its own. When a vendor's report lands on your desk, the questions that determine what it is worth are: which system was in scope, and does it include the product you are buying; which criteria were selected, because a security-only report says nothing about availability; what period does it cover, and does that period end before or after the incident you are worried about; whether subservice organisations were carved out, meaning their controls were excluded and you need their reports too; what exceptions the auditor noted and how management responded; and what complementary user entity controls the report lists, since those are the things the vendor is explicitly telling you are your job and not theirs. A candidate who goes straight to the exceptions section and the scope statement is signalling they have used one of these reports for its intended purpose rather than filing it.

The same logic applies to an ISO certificate. A certificate whose scope statement covers "the corporate IT function at the London office" tells you nothing about the SaaS platform you are about to depend on.

Control, implementation, evidence

These three words get used interchangeably and they are three different objects. Separating them is the most transferable thing in this whole topic.

A control is a statement of what must be true, written at the level of intent and independent of technology. "Access to production systems is authorised, and authorisation is reviewed at least quarterly." It says nothing about how, which is what allows it to survive a platform migration.

An implementation is the specific mechanism by which that becomes true in your estate. Production access is granted only through groups in the identity provider; group membership is requested in a workflow that requires the resource owner's approval; a scheduled job exports effective membership each quarter and opens a review task per group; the network path allows no route that bypasses single sign-on. Implementations change often, and each change is a change to how you will evidence the control.

Evidence is the artefact that demonstrates the implementation operated as described, throughout the period, for the whole population. This is where teams underestimate the work. Evidence has properties: it is preferably system-generated rather than asserted by a human, because a screenshot of a settings page proves the setting today and nothing about March; it is dated inside the audit window; it covers the complete population from which the auditor draws a sample, so you need the list of all access changes in the period before anyone picks five to inspect; and it is reproducible, meaning you can produce it again next year without a heroic effort.

In practice the good news is that engineering work already emits most of it. A pull request with a recorded approval evidences change management. A pipeline log evidences that tests and security scans ran before deployment. A ticket with timestamps and an approver evidences access authorisation. An automated export of group membership with a reviewer's decision evidences the quarterly review. What breaks the chain is the manual exception: the emergency deploy from a laptop, the access granted directly in the console during an incident, the review someone did in a meeting and did not write down. Those are not audit problems, they are gaps in the control, and the audit merely finds them.

Operating effectiveness is a claim about a period

Here is where a Type 2 engagement catches people out, and it is worth understanding before you commit to a date. The opinion is about whether the control operated throughout the period, so evidence must exist across the whole window, generated as the work happened. If the control was designed in January, implemented in September and the period runs from January to December, no amount of effort in December produces the missing nine months. You cannot backfill operating effectiveness, and attempting to reconstruct it is where an honest programme turns into a dishonest one.

So the readiness work happens before the observation period starts rather than during it; a quarterly control needs four occurrences inside the period, meaning one that fires quarterly on paper and twice in reality is an exception; a shorter first period is a legitimate way to get a report out early; and gaps between consecutive periods are visible to readers and awkward to explain. A noted exception, meanwhile, is not a catastrophe — a report with a few exceptions each carrying a credible management response generally reads as more trustworthy than a spotless one, because readers know what real operations look like.

All of which points at the control that exists to be audited. It is entirely possible to build a quarterly access review nobody uses to remove access, a risk register nobody consults and a policy set that describes no observed behaviour, and to pass. That gets you the report and leaves the risk where it was. The test for your own programme is whether removing the audit requirement would make you stop doing the thing. Where the answer is yes you have built theatre, and the auditor is not the party you deceived.