SOC 2 vs. ISO 27001: what’s the difference?

Ask around and you’ll hear that SOC 2 and ISO 27001 are basically the same thing. There’s some truth in that, but it’s only half the story.

“If there’s a Venn diagram, you overlap them, and there’s quite a large chunk in the middle,” says Charlie Naughton-Rumbo, CEO of LeftBrain. “So that is both true and both not true at the same time. The reason why it’s not true is because the fundamental purpose of SOC 2 is very different to the purpose of ISO 27001.”

Here’s what that difference looks like in practice, and how to think about which one you need.

The short version

• ISO 27001 gives you a one-page certificate that you can share freely with clients.
• SOC 2 gives you a 20 to 40 page report, shared under NDA, with an auditor’s opinion rather than a simple pass or fail.

ISO gives you a certificate

ISO 27001 confirms that your organisation is compliant with the management system the standard defines. The result is a single page you can give to clients, or as Charlie puts it, “hang on your office wall should you want to.”

In procurement, that tends to keep things simple. “Typically they will say, ‘Do you have ISO? Great. Can you show us your certificate? Great, that’s done.'”

SOC 2 gives you a report

SOC 2 is a different kind of document altogether. It’s a 20 to 40 page report that goes into detail on what your organisation does, what it delivers, and what it promises in its contracts. It then shows how you’ve used controls to back those promises up, and whether those controls have been operating effectively over a period of time, typically six or twelve months.

It goes further still. An annex covers every single control, how the auditors tested it, and any exceptions or deviations they found where something wasn’t working quite as described.

Because of that level of detail, you don’t hand it out freely. It’s shared under NDA, as part of a customer’s procurement process. What a buyer wants from it isn’t a tick.

It isn’t pass or fail either. An auditor gives an attestation as part of the report, so there is an opinion in it. But the real value is in the detail

Why the difference matters

This matters most if you build your own technical product. A customer whose confidential data is going into your system will read your SOC 2 report closely, because they want to know it’s safe.

That changes how you should approach the work. With SOC 2, the onus is on your organisation to attest to how you operate, not just to hold a single page with a tick on it.

“It’s not a case of what can I do to pass. It’s a case of what do I need to do to have in a report the information needed to give my prospective customers the warm, fuzzy feelings that when they onboard me, they’re going to be safe.”

Where they overlap

The frameworks aren’t rivals. The requirements SOC 2 is built on, known as the Trust Services Criteria, map easily onto ISO 27001. A lot of the artefacts you produce are similar too: a risk register, an information security policy, a board charter.

So if you’ve started the journey with one, that work carries over. As Charlie says, “we can easily transition to mapping evidence across the different frameworks.”

So which one do you need?

Start with your customers. During implementation, clients often ask whether they should include a particular control or detail. Charlie’s answer is always a question back: “What do your clients want? Do your customers want to know this, or is this not relevant and material to the service you’re delivering, based on the contracts you sign and send to your customers?”

That’s the real test. The question isn’t which framework is easier to get, but what you need to show the people you want to win as customers.