SOC 2 vs ISO 27001: attestation report or certification?

The structural difference: attestation vs certification

SOC 2 is not a certification, however often the phrase "SOC 2 certified" appears in marketing copy. It is an attestation engagement: a licensed CPA firm, working under AICPA attestation standards, examines your controls against the Trust Services Criteria and issues a report containing the auditor's opinion, management's assertion, a system description, and — in a Type II — the tests performed and their results. There is no certificate and no pass/fail stamp; the deliverable is the report itself, typically shared with customers under NDA.

ISO/IEC 27001 works the other way. It is an international standard for an information security management system (ISMS), and conformity is certified by an accredited certification body — not an accounting firm. The audit covers the management-system requirements in clauses 4 through 10 (context, leadership, planning, support, operation, performance evaluation, improvement) plus the Annex A controls you declare applicable in your Statement of Applicability. The deliverable is a certificate you can show anyone, with the detail of the audit staying between you and the certification body.

That structural difference drives most of the practical ones: who performs the audit, what you hand a prospect, how the cycle runs, and where the effort concentrates.

What each one actually covers

SOC 2 is organized around the Trust Services Criteria. Security (the common criteria) is included in every report; availability, processing integrity, confidentiality, and privacy are added only if you choose them. The framework does not prescribe specific controls — you assert the controls you operate, and the auditor tests whether they meet the criteria. That flexibility is why two companies' SOC 2 reports can look quite different.

ISO 27001:2022 prescribes more structure. The mandatory clauses require a functioning management system — risk assessment and treatment, documented objectives, internal audit, management review, corrective action — and Annex A supplies a reference set of 93 controls across four themes (organizational, people, physical, technological), each of which you either implement or justify excluding in the Statement of Applicability. The certification tests the system that manages security, not just the controls themselves.

In practice the underlying control work converges: both expect access control with joiner-mover-leaver discipline, change management, encryption, logging and monitoring, incident response, business continuity, and vendor management. A company that has genuinely done one has done most of the technical work for the other; what remains is the wrapper — an ISMS with its documentation and internal-audit cycle for ISO, or an auditor-testable evidence trail over an observation period for SOC 2.

Audit cadence and lifecycle

A SOC 2 engagement comes in two types. Type I evaluates the design of controls at a point in time; Type II evaluates operating effectiveness over an observation window, conventionally somewhere between three and twelve months. Most buyers who ask for SOC 2 mean Type II, and because the report covers a fixed period, companies re-engage annually so there is never a long gap between covered periods. The recurring cost of SOC 2 is therefore evidence: every control has to be shown operating throughout each successive window.

ISO 27001 certification runs on a three-year cycle. The initial audit comes in two stages — a Stage 1 review of your ISMS documentation and readiness, then a Stage 2 audit of implementation and effectiveness. The certificate is then maintained through surveillance audits, typically annual, with a full recertification audit in year three. The recurring cost of ISO 27001 is the management system: the risk assessments, internal audits, management reviews, and corrective actions that surveillance auditors check are genuinely happening.

Which one your buyers expect

The honest decision driver is rarely the frameworks' content — it is who is asking. SOC 2 grew out of the US audit profession and is the default ask from US enterprise buyers, their procurement teams, and their vendor-risk questionnaires. ISO 27001 is the international standard, and it is what buyers in Europe, the UK, Asia-Pacific, and the Middle East most commonly recognize, along with government and regulated-industry procurement outside the US. Many mid-size and larger vendors end up holding both because their pipeline spans both worlds.

A decision framework:

Where the effort lands

The two frameworks cost differently in shape, not just size. SOC 2's effort is weighted toward evidence over time: once controls are designed, the ongoing work is keeping them demonstrably operating across every observation window — access reviews completed, changes approved, incidents documented — because Type II tests operating effectiveness, not intentions. Teams that treat evidence as a once-a-year collection scramble feel this the hardest.

ISO 27001's effort is front-loaded into building the management system: the risk methodology, the Statement of Applicability, the policy set, the internal-audit function, the management-review rhythm. Once the ISMS is genuinely running, surveillance audits are comparatively contained — but a paper ISMS that exists only in documents gets found out at Stage 2 or at the first surveillance visit.

Neither is meaningfully a shortcut to the other, but the overlap means the second framework is a fraction of the first: the controls, the evidence feeds, and most policies carry over, and what you add is the missing wrapper.

Running both without doubling the work

The expensive way to hold both is to run two parallel programs — two control lists, two evidence collections, two sets of owners drifting out of sync. The efficient way is one canonical control set with both frameworks mapped onto it: a control such as quarterly access review is defined once and mapped to the SOC 2 common criteria and to the relevant ISO 27001 clauses and Annex A controls simultaneously. Evidence gathered for that shared control — access-review records, change approvals, encryption settings, log samples — then supports the corresponding requirement in each framework instead of being collected twice.

The mechanism matters more than the tool. Whether you manage this in a spreadsheet-based control matrix, a GRC platform, or dedicated compliance-automation software, evaluate any approach against the same tests: does it maintain an explicit crosswalk between frameworks so you can see which control satisfies which requirement; does it pull evidence from the source systems with enough provenance and freshness that an auditor will accept it; and is it honest about coverage, marking what it cannot verify as unmeasured rather than presenting an estimate as fact. A dashboard that reports "compliant" without a testable evidence trail behind each control is the failure mode to avoid.

One boundary holds regardless of tooling: internal readiness systems prepare management's side of both programs — the controls, the evidence, the documentation, the testing records — but they do not issue SOC 2 reports or ISO 27001 certificates. What auditors actually test is independent of any tool: for SOC 2 Type II, that your asserted controls operated effectively across the observation period; for ISO 27001, that the management system is genuinely running when surveillance auditors look. Good tooling makes that examination faster to complete and cheaper to repeat; it does not replace the CPA firm or the certification body.

Frequently asked questions