ISO 27001 vs SOC 2: How to Choose (or Combine) Both Frameworks

If you're weighing ISO 27001 vs SOC 2, the short answer is this: choose SOC 2 if most of your customers are in North America and want an independent auditor's report on how your controls operate. Choose ISO 27001 if you sell internationally or need a certificate that procurement teams recognize globally. If you sell into both markets, build one control set and get audited against both. The frameworks overlap heavily, so the second audit is mostly incremental work rather than a second program.

The rest of this post explains how the two differ, where they overlap, and how we would structure a combined program so you don't maintain two sets of evidence.

The Problem: Two Questionnaires, One Security Team

The situation usually looks like this. A sales team is blocked on an enterprise deal because the prospect's security review asks for a SOC 2 Type II report. A month later, a European prospect asks for an ISO 27001 certificate. A small security or platform team, already busy, now has to work out whether these are two separate projects.

They are not, but the frameworks are built differently enough that teams often treat them as separate. That leads to duplicate policies, duplicate evidence collection, and two audits that each feel like starting over.

ISO 27001 vs SOC 2: The Structural Differences

Both frameworks assess information security, but they answer different questions.

What ISO 27001 actually is

ISO/IEC 27001 is an international standard for an Information Security Management System (ISMS). The current version is ISO/IEC 27001:2022. Its core requirements are management-system clauses 4 through 10, which cover:

• Context of the organization and ISMS scope
• Leadership commitment and roles
• Risk assessment and risk treatment
• Support, operation, and performance evaluation
• Continual improvement, including internal audit and management review

Annex A lists 93 reference controls in four themes: organizational, people, physical, and technological. You select the controls that apply based on your risk assessment and record your choices in a Statement of Applicability (SoA).

The result is a certificate issued by an accredited certification body. The cycle runs for three years: a two-stage initial audit, annual surveillance audits, and recertification in year three.

What SOC 2 actually is

SOC 2 is an attestation report governed by the American Institute of Certified Public Accountants (AICPA). It must be issued by a licensed CPA firm. The auditor evaluates your controls against the AICPA's Trust Services Criteria (TSC), which cover five categories:

1. Security (the Common Criteria, required in every SOC 2)
2. Availability
3. Processing Integrity
4. Confidentiality
5. Privacy

There are two report types:

• Type I: Are the controls designed appropriately at a single point in time?
• Type II: Did the controls operate effectively over an observation period? Periods of 3 to 12 months are common.

You don't "pass" a SOC 2. You receive a report containing the auditor's opinion, your system description, the controls tested, and any exceptions. Customers read it and decide for themselves.

Side-by-side summary

The most important practical difference is the level of detail. An ISO 27001 certificate tells a buyer that your management system meets the standard for a defined scope. A SOC 2 Type II report shows the buyer which controls were tested, how they were tested, and whether any exceptions occurred. Some buyers want the certificate's simplicity. Others want the report's detail.

How to Choose

These questions settle most decisions:

• Where are your customers? Ask your sales team which artifact appears most often in security questionnaires and contract clauses. This is usually the deciding factor.
• Do you need a governance framework, or proof of controls? If you have no formal risk management process yet, ISO 27001's ISMS requirements give you that structure. SOC 2 assumes you can describe your system and controls, but it prescribes less about how you manage them.
• How mature is your evidence? A SOC 2 Type II requires evidence that controls operated across the whole observation period. If your logging, access reviews, and change records are inconsistent, start with a Type I or with ISO 27001 readiness work while you build that history.
• Which sector are you in? Regulated sectors often carry extra expectations on top of either framework. Our industry-specific work usually begins by identifying those overlays before any control mapping starts.

If the answer to the first question is "both," don't pick one. Plan for both from the start.

ISO 27001 SOC 2 Mapping: Building One Control Set

The AICPA publishes a mapping between the Trust Services Criteria and ISO 27001 controls. It is a good starting point and worth downloading from the AICPA website. In practice, we recommend going a step further: keep one internal control register, where each control is written once, owned once, and evidenced once, then tagged to every framework it satisfies.

Here is a simplified example of what that register can look like:

# controls/access-management.yaml
- id: CTL-AC-01
  title: Role-based access provisioning
  owner: platform-team
  description: >
    Access to production systems is granted through SSO groups
    tied to job role, approved by the system owner via ticket.
  frequency: per-request
  evidence:
    - source: idp_audit_log
    - source: access_request_tickets
  mappings:
    iso27001_2022: [A.5.15, A.5.18]
    soc2_tsc: [CC6.1, CC6.2]

- id: CTL-AC-02
  title: Quarterly privileged access review
  owner: security-team
  frequency: quarterly
  evidence:
    - source: access_review_signoff
  mappings:
    iso27001_2022: [A.5.18, A.8.2]
    soc2_tsc: [CC6.2, CC6.3]

- id: CTL-CM-01
  title: Peer-reviewed, pipeline-enforced change management
  owner: engineering
  frequency: continuous
  evidence:
    - source: vcs_merge_records
    - source: ci_deploy_logs
  mappings:
    iso27001_2022: [A.8.32]
    soc2_tsc: [CC8.1]

With the register in version control, you can check coverage automatically. A short script can show which criteria in each framework have no mapped control:

import yaml, glob

REQUIRED = {
    "iso27001_2022": set(open("scope/iso_soa_applicable.txt").read().split()),
    "soc2_tsc": set(open("scope/soc2_in_scope_criteria.txt").read().split()),
}

covered = {fw: set() for fw in REQUIRED}
for path in glob.glob("controls/*.yaml"):
    for ctl in yaml.safe_load(open(path)):
        for fw, refs in ctl.get("mappings", {}).items():
            covered.setdefault(fw, set()).update(refs)

for fw, required in REQUIRED.items():
    gaps = sorted(required - covered[fw])
    print(f"{fw}: {len(gaps)} unmapped -> {gaps}")

This doesn't replace auditor judgment, but it catches drift early. For example, it will flag a control that was deleted from one file while still being listed in the SoA.

Where the frameworks genuinely diverge

The overlap is large but not complete. Plan specific work for these areas:

• ISMS management clauses. ISO 27001 requires management review, internal audit of the ISMS, documented objectives, and continual improvement. SOC 2 has no direct equivalent to this full management-system cycle.
• Statement of Applicability. This is an ISO-only artifact. You must justify both the controls you include and the ones you exclude.
• System description. SOC 2 requires a detailed description of your system boundaries, components, and commitments, prepared according to AICPA description criteria.
• Operating-period evidence. A SOC 2 Type II tests samples across the observation window. ISO surveillance audits also sample evidence, but the testing approach differs.
• Optional TSC categories. If you include Privacy or Processing Integrity in SOC 2, expect criteria that go beyond what a typical ISO 27001 scope covers.

A Practical Sequencing Plan

When both are needed, this order generally works well:

1. Define a single scope. Use the same systems, locations, and teams for both audits wherever possible. Mismatched scopes are the most common source of duplicate work.
2. Run one risk assessment that meets ISO 27001 clause 6 requirements. SOC 2's risk assessment criteria (CC3.x) will be satisfied by the same process.
3. Build the unified control register and map each control to Annex A and the TSC.
4. Automate evidence collection from your identity provider, cloud platform, CI/CD pipeline, and ticketing system. Pull the evidence, don't screenshot it.
5. Start the SOC 2 observation period once the controls are live, and run ISO 27001 internal audit and management review in parallel.
6. Align the audit calendars so surveillance audits and SOC 2 fieldwork can reuse the same evidence pulls.

Much of this work is engineering, not paperwork: identity architecture, logging pipelines, and deployment controls. We cover that implementation side in our cloud and security engineering capabilities.

Sources

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection: Information security management systems: Requirements (iso.org)
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022) (aicpa-cima.com)
• AICPA, Mapping of the Trust Services Criteria to ISO/IEC 27001 (aicpa-cima.com)

FAQ

Is ISO 27001 or SOC 2 harder to achieve?

Neither is objectively harder. They are demanding in different ways. ISO 27001 requires a functioning management system with risk treatment, internal audit, and management review. A SOC 2 Type II requires consistent evidence that controls operated throughout the observation period. Teams with weak process governance tend to find ISO harder. Teams with inconsistent operational evidence tend to find SOC 2 Type II harder.

Can one auditor perform both ISO 27001 and SOC 2?

SOC 2 must be issued by a licensed CPA firm, and ISO 27001 certification must come from an accredited certification body. Some firms hold both qualifications, or work with an affiliated entity that does, which can make it easier to coordinate fieldwork. Confirm each auditor's accreditation directly.

Does an ISO 27001 certificate replace a SOC 2 report?

Not automatically. Some customers accept either one. Others specifically require a SOC 2 report because they want detailed control testing results. Check contractual requirements and security questionnaires before assuming one will substitute for the other.

How much of ISO 27001 and SOC 2 overlaps?

The technical and operational controls overlap substantially, particularly in access control, change management, incident response, logging, and vendor management. The AICPA mapping document shows this at the criterion level. The main differences are ISO's management-system requirements and SoA, and SOC 2's system description and operating-period testing.

Should we start with SOC 2 Type I or go straight to Type II?

A Type I is useful when you need an artifact quickly or want to validate control design before committing to an observation period. If your controls and evidence collection are already mature, going straight to Type II avoids paying for an extra report. Many buyers ultimately expect Type II.