ISO 27001 and SOC 2: How They Work Together (and Where They Don't)

Reviewed by Ali Aleali, CISSP, CCSP · Last reviewed March 18, 2026

A company finishes its first SOC 2 Type 2 audit, feels good about the result, and then gets a request from an international prospect asking for ISO 27001 certification. Or the reverse, a company with ISO 27001 certification expands into North America and discovers that enterprise buyers expect a SOC 2 report, not a certificate.

In both cases, the question is the same. How much of what we already built carries over, and how much is new work?

The answer is encouraging, but the details matter. The two frameworks share a significant foundation in risk management, access control, incident response, and change management. But they differ in structure, certification mechanics, and what auditors actually examine. Understanding these differences before starting the second framework is the difference between a 3-month project and a 9-month one.

What ISO 27001 Actually Requires

ISO 27001:2022 is an international standard for information security management systems (ISMS). Unlike SOC 2, which evaluates specific service controls against Trust Services Criteria, ISO 27001 requires a complete management system: a documented, risk-based approach to information security that covers the entire organization.

The standard has two layers. The main body (Clauses 4-10) defines the management system requirements: context, leadership, planning, support, operations, performance evaluation, and improvement. Annex A provides 93 controls organized into four categories: organizational, people, physical, and technological.

Certification requires demonstrating compliance with both layers through a two-stage audit conducted by an accredited certification body.

Key distinction

SOC 2 evaluates whether controls are operating effectively. ISO 27001 evaluates whether a management system exists, is maintained, and drives continuous improvement. The first asks are your controls working? The second asks do you have a system for making sure they keep working?

What SOC 2 Actually Requires

SOC 2 is an attestation framework governed by the AICPA. A licensed CPA firm evaluates an organization's controls against Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) and issues a report, not a certificate.

The scope is narrower than ISO 27001. SOC 2 focuses on the specific services an organization provides to its customers, not the entire organization. The criteria are outcome-based: CC6.1 requires logical and physical access controls, CC7.1 requires vulnerability identification, CC8.1 requires change management. How those outcomes are achieved is up to the organization.

For a deeper breakdown, we wrote a detailed comparison of the two frameworks and a companion FAQ addressing the most common questions.

Where the Overlap Is Real

Organizations that have completed one framework will find that 60 to 80 percent of the work applies to the other. The overlap is strongest in areas where both frameworks demand evidence of the same operational practices.

Access control is the clearest example. ISO 27001 Annex A 5.15-5.18 covers access control policies, user access provisioning, privileged access, and authentication. SOC 2 CC6.1-CC6.3 covers the same ground. If an organization already has documented access provisioning workflows, periodic access reviews, and MFA enforcement, that evidence satisfies both frameworks with minimal adaptation.

The same holds for:

SHARED CONTROL DOMAINS

Risk Management

ISO 27001 Clause 6.1 requires formal risk assessment and treatment. SOC 2 CC3.1-CC3.4 requires risk identification and mitigation. The methodology and outputs are reusable.

Incident Response

ISO 27001 Annex A 5.24-5.28 and SOC 2 CC7.3-CC7.5 both require documented incident response plans, defined roles, and evidence of execution.

Change Management

ISO 27001 Annex A 8.32 and SOC 2 CC8.1 both require controlled change processes with approval, testing, and rollback procedures.

Vendor Management

ISO 27001 Annex A 5.19-5.22 and SOC 2 CC9.2 both require oversight of third-party service providers.

When the evidence architecture is designed well from the start, the same logs, screenshots, and review records serve both auditors.

Where They Diverge

The differences are not cosmetic. They affect planning, staffing, and timeline.

Dimension ISO 27001 SOC 2
Scope Entire organization (or defined subset) Specific services provided to customers
Output Certification (pass/fail) from accredited body Attestation report from CPA firm (can include exceptions)
Geography Global recognition, especially Europe and APAC Primarily North American enterprise buyers
Renewal 3-year cert with annual surveillance audits Annual report (12-month observation period for Type 2)
Management System Required (risk treatment, management review, internal audit, continual improvement) Not explicitly required

Scope is where teams get caught off guard. A company with ISO 27001 can't simply hand the certificate to a SOC 2 auditor and expect credit for everything. The SOC 2 auditor will want controls specifically mapped to the in-scope services and systems, regardless of what the ISO certificate covers.

The management system wrapper is the other surprise. Organizations coming from SOC 2 often find they have the security controls but lack the management system: documented risk treatment plans, formal management review meetings, and internal audit programs. ISO 27001 Clauses 9.2 (internal audit) and 9.3 (management review) are a different kind of work than implementing controls.

How to Sequence Them

The sequencing decision depends on where the revenue pressure is coming from.

Start with SOC 2 if most of your customers are North American enterprises requesting SOC 2 reports. SOC 2 has a faster time to value: a Type 1 audit can be completed in 8-12 weeks, and it gives you a report to share with prospects while you build toward Type 2.

Start with ISO 27001 if you sell internationally or your customers require a recognized certification (not just an attestation report). ISO 27001 builds a broader management system foundation that makes SOC 2 faster afterward.

Either way, the key is building an effective security program from the start, not a framework-specific compliance project. When the program is designed around real operational practices, policies that match how the team actually works, and evidence that flows naturally from day-to-day operations, the second framework becomes a mapping exercise rather than a rebuild.

What we've observed

Companies that treat each framework as a separate project spend roughly the same effort twice. Companies that build a unified security program and map it to both frameworks spend about 30-40% less on the second one.

The Certification Process

For teams evaluating ISO 27001, here is what the certification process looks like:

ISO 27001 CERTIFICATION STAGES

Stage 1: Documentation Review

The auditor reviews ISMS documentation, the Statement of Applicability, risk assessment methodology, and policies. This is a readiness check, not the full audit. Gaps identified here become corrective actions that must be resolved before Stage 2.

Stage 2: Evidence-Based Assessment

The auditor examines how the ISMS operates in practice. They review logs, interview staff, verify that controls are implemented as documented, and assess whether the management system is actively maintained. This is where the work either holds up or doesn't.

Surveillance Audits (Years 2 and 3)

Annual audits that verify continued compliance. Lighter than the initial certification but still require evidence of ongoing operations, management reviews, and continual improvement.

Re-certification (Year 4)

A full audit cycle repeats. The timeline from project kickoff to initial certification is typically 6 to 12 months. Companies with an existing SOC 2 program can often compress this to 4 to 6 months.

Common Mistakes in Dual-Framework Programs

A few patterns show up repeatedly when organizations pursue both frameworks:

Using generic policy templates. Policies written for a generic SaaS company and applied to an organization with a different architecture, industry, or operating model create the most common source of audit friction: a gap between what the policy says and what the team actually does. Both ISO 27001 and SOC 2 auditors are trained to find exactly that gap.

Treating frameworks as separate projects. Running ISO 27001 and SOC 2 as independent workstreams with separate teams, separate evidence repositories, and separate policy sets doubles the effort. A unified security program with a single set of policies, controls, and evidence sources, mapped to both frameworks, is the more efficient model.

Underestimating the ISMS wrapper. Teams coming from SOC 2 tend to assume ISO 27001 is just more controls. The management system requirements, formal risk treatment, management review, internal audit, continual improvement, are a different kind of work. They require executive engagement, documented decision-making, and a cadence of review that many SOC 2-compliant organizations don't yet have.

Skipping the evidence architecture. Both frameworks require evidence, but the types and retention requirements differ. Designing the evidence architecture once, with both frameworks in mind, prevents the scramble of retroactively collecting evidence for the second audit.

Pursuing ISO 27001, SOC 2, or Both?

We'll review your current security posture, identify what carries over between frameworks, and scope a roadmap to certification. The goal is an effective security program where compliance is a byproduct, not a separate project for each framework.

Frequently Asked Questions

Should I pursue ISO 27001 or SOC 2 first?

It depends on where the demand is coming from. If most of your customers are North American enterprises specifically requesting SOC 2 reports, start there. SOC 2 Type 1 can be completed in 8-12 weeks, giving you a report to share with prospects quickly. If you sell internationally or need a certification recognized globally, ISO 27001 is the stronger starting point. Either way, building a unified security program from the start makes the second framework significantly faster.

How much overlap exists between ISO 27001 and SOC 2?

Significant overlap, particularly around access control, risk management, incident response, change management, and vendor oversight. Organizations that have implemented ISO 27001's Annex A controls typically find that 60 to 80 percent of SOC 2's Trust Services Criteria are already addressed. The remaining gaps tend to be in areas where the frameworks have different structural requirements, such as ISO 27001's management system wrapper or SOC 2's service-specific scoping.

How long does ISO 27001 certification take?

For most mid-sized organizations, 6 to 12 months from project kickoff to certification. This includes scoping, risk assessment, control implementation, internal audit, and the two-stage external audit. Organizations with an existing SOC 2 program or mature security practices can often compress this to 4 to 6 months, since the control implementation and evidence collection infrastructure is already in place.

What is the difference between ISO 27001 certification and SOC 2 attestation?

ISO 27001 certification is a pass/fail outcome issued by an accredited certification body, confirming that an organization's ISMS meets the standard's requirements. SOC 2 is an attestation report issued by a licensed CPA firm that evaluates controls against Trust Services Criteria. A SOC 2 report can include qualified opinions or noted exceptions and still be valid. An ISO 27001 audit with unresolved major nonconformities blocks certification entirely.

Do ISO 27001 and SOC 2 require annual renewals?

ISO 27001 certification is valid for three years, with mandatory surveillance audits in years two and three and a full re-certification in year four. SOC 2 Type 2 reports cover a defined period (typically 12 months), and most customers expect a new report annually. Both frameworks require continuous maintenance of controls between assessment cycles, not just preparation before audits.

Share this article:

About the Author
Ali Aleali
Ali Aleali, CISSP, CCSP

Co-Founder & Principal Consultant, Truvo Cyber

Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.