Already ISO 27001 Certified? How to Get SOC 2 Without Starting From Scratch

The certificate is framed in the lobby, the surveillance audit went fine, and then a US prospect's security team replies: "Great, but we need a SOC 2 report." Many ISO 27001 certified companies hear this and assume a second full program is coming. It usually isn't.

A well-run ISMS already contains most of what a SOC 2 auditor will ask about. What it lacks is a handful of specific pieces, plus evidence collected in a different way. This guide shows how ISO 27001 to SOC 2 mapping works in practice and sorts your existing work into three buckets: reuse, adapt and add.

H2: SOC 2 vs ISO 27001: Two Different Kinds of Proof

Before mapping anything, it helps to see why the two exist. (For a wider comparison, see SOC 2 vs ISO 27001 vs HIPAA.)

H3: ISO 27001 certifies a management system

An accredited certification body checks that you assess risk, select controls, document them in a Statement of Applicability, audit yourself and review the results with management. The certificate covers your ISMS scope and is renewed on a three-year cycle with annual surveillance audits. The ISO 27001 certification process walks through each stage.

H3: SOC 2 is a CPA firm's attestation

A licensed CPA firm tests your controls against the AICPA Trust Services Criteria and issues a report with an opinion. The report describes your system, lists the controls tested and states what the auditor found. A Type 2 report covers a defined observation period, so it tests whether controls worked repeatedly, not only that they exist.

ISO tells a buyer you have a disciplined process. SOC 2 tells a buyer what an independent CPA saw when they tested your controls. US enterprise buyers tend to ask for the second because it is a document their reviewers can read and file.

Bucket One: What You Can Reuse Almost As It Is

Most of the Security criterion (the Common Criteria) lines up with work you already did for Annex A. The mapping below is approximate, so confirm the exact crosswalk with your auditor.

Access control is where reused controls most often trip up in testing, so review the access control mistakes auditors flag before you carry them over. Supplier management also needs a closer look, because subprocessor management is where many SOC 2 programs fall short.

The documents are reusable too: policies, asset inventory, risk register, training records, internal audit reports and management review minutes.

Bucket Two: What You Have but Must Adapt

Some ISO material needs reshaping before an auditor will accept it for SOC 2.

Your scope statement

An ISO scope names sites, processes and assets. SOC 2 asks for a fuller system description covering services, infrastructure, software, people, procedures and data, plus your commitments to customers. If the two scopes differ, decide which one the SOC 2 report should cover. Why your SOC 2 scope decision matters covers the trade-offs.

Control wording

An auditor tests the controls as you wrote them. A vague ISO-style statement ("access is reviewed periodically") becomes a test problem. Rewrite it with a frequency, an owner and an evidence source ("quarterly, by the engineering manager, recorded in the ticketing system").

Exclusions

The Statement of Applicability lets you exclude Annex A controls with a justification. SOC 2 does not work that way inside the categories you choose. If Availability is in scope, the Availability criteria apply.

H2: Bucket Three: What Is Usually Missing

These are the SOC 2 controls and documents ISO-certified teams most often haven't built.

• The system description and management assertion. A new narrative document, plus a signed statement from management that it is accurate. See how these sit inside the SOC 2 report structure.

• Governance evidence. SOC 2 draws on the COSO framework, which asks about board or leadership oversight, organisational structure, accountability and competence. ISO leadership clauses cover some of this, but expect more questions about who oversees the program and how.

• Fraud and change-related risk. The risk criteria expect you to consider these explicitly.

• Subservice organisations and user entity controls. You must say how cloud and other vendors are treated (included or carved out) and list what your customers are expected to do on their side. If you run on a hyperscaler, read what SOC 2 requires from you on AWS, Azure or GCP.

• Operating evidence over a period. The auditor samples across the whole window: new joiners, leavers, changes and incidents. A gap in any month shows up. This is what SOC 2 auditors look for when reviewing evidence.

Exceptions stay in the report

In ISO, a minor nonconformity can be corrected before the certificate decision. In a Type 2 report, an exception stays in the report for that period. Fix weak spots before the window opens.

SOC 2, ISO 27001 and GDPR Overlap: What Carries Across

Many teams in this position also have European customers, so the SOC 2 ISO 27001 GDPR overlap question comes up. Security work overlaps. Privacy work only partly does.

Neither ISO 27001 nor SOC 2 certifies GDPR compliance. If personal data is central to your service, ISO 27701 extends an ISMS toward privacy management, and the SOC 2 Privacy criteria cover personal information handling on the US side. Treat them as supporting evidence, not proof of compliance. The core GDPR principles show what still needs separate work, and running SOC 2 Type 2 and GDPR as one program explains how to combine them.

A Practical Sequence for an ISO-Certified Team

1. Confirm what buyers want. Check recent questionnaires. Security alone is a common starting scope.

2. Align the scope. Decide the system boundary for the SOC 2 report and compare it with your ISMS scope.

3. Run a gap assessment against the criteria. Use your Annex A evidence as the baseline and mark each criterion reuse, adapt or add.

4. Close the gaps. Write the system description, tighten control wording, document vendor treatment and fill the governance evidence. How to fix compliance gaps before your audit goes step by step.

5. Open the observation window. Many teams choose a shorter window for a first report and extend it in later years. See why the observation period matters.

6. Plan the combined cycle. Ask whether your ISO surveillance audit and the SOC 2 fieldwork can share evidence and scheduling.

Mistakes to Avoid

• Assuming the certificate satisfies the buyer. Some reviewers will not accept ISO in place of a SOC 2 report.

• Copying ISO control statements unchanged. They tend to fail testing because they lack specifics.

• Starting the window before the gaps are fixed. Early exceptions are hard to explain.

• Mixing up auditors. The ISO certification body and the SOC 2 CPA firm are different kinds of organisations, and the CPA firm must be independent of your consulting support. SOC 2 auditor or consultant explains where the line sits.

The Takeaway

Your ISMS is the head start. Reuse the risk work, the policies and the evidence you already collect. Adapt the scope and control wording. Add the system description, the governance proof and the period evidence. Done in that order, ISO 27001 to SOC 2 mapping turns a second certification project into an extension of the first.

If you hold ISO 27001 and a buyer is asking for SOC 2, talk to our risk assurance team about a gap assessment built on your existing ISMS.

Frequently Asked Questions

1. Does ISO 27001 replace SOC 2?

No. ISO 27001 certifies your security management system, while SOC 2 is a CPA firm's report on your controls. Some buyers accept ISO, but many US enterprise buyers ask for SOC 2 specifically, so check the wording in their questionnaire.

2. How much of SOC 2 does ISO 27001 already cover?

A large share of the Security criterion, including risk assessment, access control, logging, incident response and supplier management. It usually doesn't cover the system description, governance evidence or operating evidence across the audit period.

3. Which should we do first, ISO 27001 or SOC 2?

Whichever your largest buyers ask for. US customers usually point to SOC 2, and European or Asian customers often point to ISO. If you already hold ISO, SOC 2 is a lighter lift.

4. Can we reuse our ISO evidence for SOC 2?

Often, yes. Policies, the risk register, training records and internal audit reports are a good starting point. Rewrite vague control statements with a frequency, an owner and an evidence source, because the auditor tests them as written.

5. Is the SOC 2 scope the same as our ISO scope?

Not always. SOC 2 needs a fuller system description covering services, infrastructure, software, people and data. Decide early which system the report covers and compare it with your ISMS scope.

6. Do ISO 27001 and SOC 2 make us GDPR compliant?

No. Both support GDPR's security requirements, but neither covers lawful basis, data subject requests, DPIAs or international transfers. Those need separate work. ISO 27701 and the SOC 2 Privacy criteria can help, as supporting evidence.

7. Should we start with a Type 1 or a Type 2 report?

If a customer needs something soon, a Type 1 report shows your controls are designed properly at a point in time. Most enterprise buyers eventually ask for Type 2, which tests whether those controls operated across a period.