ISO 27001 for Companies That Already Have SOC 2: The 30% Shortcut

Your biggest European prospect just replied to your SOC 2 report with one line: "Thanks, but we'll need ISO 27001 before we can sign."

You forward it to your CTO. The response is predictable. "Didn't we just spend six months on compliance?"

Yes. You did. And the good news your CTO doesn't know yet: you're already roughly 70% of the way to ISO 27001. You just can't see it, because nobody has mapped the two frameworks against each other in a way that's actually useful to a founder.

Most vendors will quote you an ISO 27001 project like it's a greenfield build: six months, $40–60k, a fresh Statement of Applicability, a new auditor, a new policy stack. That's the lazy version. It's also how compliance platforms make their money twice.

The real shape of the work is different. If you have a clean SOC 2 Type 2 in hand, ISO 27001 is a 30% shortcut, not a 100% restart. This article tells you exactly which 30% is net-new, which 70% is already done, and how to sequence the project so you don't pay for the same controls twice.

They're overlapping specs for the same underlying thing: "prove you're not reckless with information."

• • SOC 2 is an American attestation standard. Five Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy). An auditor reviews your controls and writes a report. The output is a PDF your sales team sends to buyers.
• • ISO 27001 is an international certification standard. One control set (Annex A, 93 controls in the 2022 revision) wrapped around a formal management system called an ISMS. An auditor assesses you and issues a certificate. The output is a one-page cert your sales team sends to buyers, usually European ones.

Different outputs. Different auditors. Different vocabulary. Deeply overlapping evidence.

The reason nobody frames it this way is that the two standards use different words for the same thing. SOC 2 talks about "control objectives." ISO talks about "Annex A controls." SOC 2 has a "System Description." ISO has a "Statement of Applicability." Underneath the jargon, you're proving the same things: you manage access, you encrypt data, you respond to incidents, you screen your vendors, you train your people.

If your SOC 2 is real (not a paper exercise), you have already built most of an ISMS without calling it that.

Here's where the "30% shortcut" number comes from. The 2022 version of ISO 27001 Annex A has 93 controls across four themes: Organizational (37), People (8), Physical (14), Technological (34).

Mapped against a well-run SOC 2 Type 2 scope:

• • ~65 controls (≈70%) are fully or substantially covered by SOC 2 evidence you already have. Access management, change management, cryptography, logging, vendor risk, incident response, acceptable use, background checks, and all of it is in your existing SOC 2 scope.
• • ~20 controls (≈22%) are partial overlaps. You have the control, but ISO wants it documented differently or applied to a broader scope. Example: SOC 2 wants a risk assessment; ISO wants a documented risk treatment plan with owners and review cycles.
• • ~8 controls (≈8%) are genuinely net-new. The ISMS itself, the Statement of Applicability, internal audits of the ISMS, the management review meeting, and a handful of Annex A items that SOC 2 doesn't map to at all (like threat intelligence and information security during disruption).

That's the shape of the work. ~70% reuse. ~22% reformat. ~8% build from scratch.

The 6-month, $40k ISO project most vendors quote is priced like all 93 controls are new. They're not. You've already paid for two-thirds of them.

If you have a SOC 2 Type 2 report covering the Security Trust Services Criterion, the following Annex A controls are essentially free:

• • Access controls (A.5.15–A.5.18, A.8.2–A.8.5). Your SOC 2 already tested user provisioning, deprovisioning, MFA, privileged access, and quarterly access reviews. Same evidence, new label.
• • Cryptography (A.8.24). You're already encrypting data at rest and in transit. Same KMS, same TLS config, same evidence screenshots.
• • Change management (A.8.32). Your SOC 2 tested your PR review and deployment process. ISO wants the same thing.
• • Logging and monitoring (A.8.15–A.8.17). Your SOC 2 auditor already reviewed your log retention, alerting, and clock sync. Hand them the same exports.
• • Vendor management (A.5.19–A.5.23). Your SOC 2 vendor inventory, risk ratings, and contract reviews map one-to-one.
• • Incident response (A.5.24–A.5.27). Same playbook, same tabletop exercise evidence, same post-mortems.
• • HR security (A.6.1–A.6.8). Background checks, onboarding, offboarding, security awareness training. All already in your SOC 2 scope.
• • Physical security (A.7.1–A.7.14). If you're cloud-native, you inherit most of these from your AWS/GCP/Azure SOC 2 / ISO 27001 reports. Same inheritance, same sub-service organization letter.
• • Backup, availability, capacity (A.8.13–A.8.14, A.8.6). If your SOC 2 scope included Availability, these are done. If not, you still have most of the evidence, but it was just out of scope.

That's roughly 65 of the 93 controls. Your SOC 2 auditor's workpapers are the ISO auditor's evidence. You just re-package them under the Annex A labels.

This is where ISO quietly adds scope. The control exists in your SOC 2 world; ISO wants it documented with more structure.

• • Risk assessment and treatment (A.5.1–A.5.3, Clause 6). SOC 2 asks you to do a risk assessment. ISO asks you to do a risk assessment plus a formal risk treatment plan, with named owners, residual risk ratings, and annual review. Your SOC 2 risk register probably needs three new columns and a sign-off cycle.
• • Asset inventory (A.5.9–A.5.14). SOC 2 wants a list of systems. ISO wants a classified inventory, with owners, data classification, and acceptable use tied to each asset. Usually a spreadsheet upgrade, not a new control.
• • Supplier security (A.5.19–A.5.23). SOC 2 covers vendor reviews. ISO adds explicit requirements around supplier agreements, monitoring, and information security in ICT supply chains. Most founders need to upgrade their DPA/MSA templates once.
• • Information classification (A.5.12). SOC 2 tends to leave this implicit. ISO wants a classification scheme (Public / Internal / Confidential / Restricted) and evidence that people apply it. Light lift: a policy plus a labeling convention.
• • Secure development (A.8.25–A.8.31). SOC 2 covers SDLC. ISO adds explicit requirements around threat modeling, secure coding guidelines, and separation of dev/test/prod. Most engineering-led startups already do this; they've just never written it down.

None of this is hard. It's documentation polish on controls you already operate. Budget 40–60 hours of policy-and-evidence rework, not a quarter-long project.

This is the real work. None of it is hard on its own. All of it is invisible to a SOC 2 auditor, so none of it exists in your current setup.

• • The ISMS itself (Clauses 4–10). ISO is not just a control list; it's a management system. You need a documented scope, an information security policy, objectives with measurable targets, and a governance rhythm that actually happens. This is the single biggest conceptual leap from SOC 2.
• • Statement of Applicability (Clause 6.1.3 / A). A document that lists all 93 Annex A controls, says which apply to you, which don't, and why. It's the spine of the audit. Budget half a day to draft, then iterate.
• • Internal audit program (Clause 9.2). ISO requires you to audit your own ISMS at least annually, using someone independent of the function being audited. For a 20-person startup, this usually means a fractional resource or your compliance partner. SOC 2 has no equivalent requirement.
• • Management review (Clause 9.3). A formal, documented meeting where leadership reviews ISMS performance: incidents, audit findings, risk posture, objective tracking. Quarterly works. No meeting, no certificate.
• • Continual improvement (Clause 10). Documented corrective actions with root cause analysis for every nonconformity. More structured than a SOC 2 finding log.
• • Threat intelligence (A.5.7, new in 2022). You need a documented process for collecting and acting on threat intel. For most SaaS startups, this is a lightweight feed (CISA alerts, vendor advisories, your cloud provider's security bulletins) with a review cadence.
• • Information security for use of cloud services (A.5.23, new in 2022). Most of this inherits from your existing vendor reviews, but ISO wants explicit cloud-service selection and exit criteria documented.
• • ICT readiness for business continuity (A.5.30, new in 2022). Adjacent to your SOC 2 BCP, but ISO is more explicit. You need documented RTOs/RPOs tied to business impact.

This is the 8% that actually changes your operating model. Everything else is re-labeling.

Most founders treat ISO 27001 as a separate project from their next SOC 2 cycle. That's the expensive way. The cheap way:

1. 1. Align your SOC 2 renewal and your ISO 27001 stage 1 so they share controls, evidence, and policy reviews. One evidence-collection sprint, two certificates.
2. 2. Pick an auditor who does both. Many SOC 2 firms also issue ISO certs via an accredited partner (UKAS, ANAB, etc.). One kickoff, one stakeholder burden, lower combined fee. A standalone ISO auditor who's never seen your SOC 2 will ask for the same evidence three different ways.
3. 3. Reuse the policy stack, don't duplicate it. One information security policy that satisfies both frameworks is allowed and encouraged. Two parallel policy libraries is how compliance becomes a full-time job for someone on your team.
4. 4. Build the ISMS before the audit gap. The 8% of net-new controls need to run for at least 3 months before your ISO stage 2 audit. Management review minutes from last week won't fly. Start the ISMS rhythm the day you decide to pursue ISO, not the month before the audit.
5. 5. Scope tightly the first time. Your ISO scope doesn't have to be your whole company. Most startups scope it to the product + production infrastructure + the teams that touch them. Corporate IT, marketing systems, and sales tooling are optional. Narrow scope = cheaper audit, faster cert, easier to expand later.

Done right, the marginal cost of adding ISO 27001 on top of a SOC 2 is $12–20k and 6–10 weeks of part-time effort , not $40k and a quarter.

Three predictable ways the SOC-to-ISO path goes wrong:

• • Hiring a pure ISO consultant who ignores your SOC 2. They'll rebuild policies from templates they own, rewrite risk registers in their format, and quote you for a "full ISMS implementation" as if you've never done compliance. You'll pay for work you already did.
• • Letting the compliance platform drive the scope. Automated platforms default to "all 93 Annex A controls, all your systems, all your teams." That's a marketing-safe default, not a scoping decision. It inflates audit cost and policy count. A human should be making scope calls, not a checkbox UI.
• • Treating the ISMS as paperwork. Management review meetings that never happen. Internal audits scheduled the week before stage 2. Risk treatment plans with no owners. Auditors notice immediately. This is the fastest way to fail a stage 2 audit and pay for a remediation cycle.

The common thread: paying twice for controls you already operate, because nobody on the project knew what your SOC 2 already proved.