.svg)
A question that comes up in nearly every initial engagement: Should we do SOC 2 or ISO 27001? Sometimes followed by Can we do both without doubling the work?
The short answer is that roughly 70% of the controls overlap. The longer answer is that the overlap is at the control level, not at the structural level, and understanding that distinction is what separates companies that stack frameworks efficiently from companies that end up maintaining two parallel compliance programs. Companies that get this right start by building an effective security program as the foundation, then map each framework onto it. The program is the source of truth; SOC 2 and ISO 27001 are different lenses applied to the same underlying controls.
This article breaks down the comparison at the control level, using real SOC 2 control sets mapped against ISO 27001:2022 Annex A, so you can see exactly where the work overlaps and where each framework demands something the other doesn't.
The Fundamental Structural Difference
Before comparing controls, it helps to understand what each framework actually produces, because this is where the buyer experience diverges completely.
40-60 pages
Attestation Report
SOC 2 was specifically designed to be shared with third parties. The entire framework exists to produce a document a buyer can read and evaluate. Written by an independent CPA firm, it describes the control environment in detail: what systems are in scope, what controls exist, how the auditor tested them, and what the results were. The report is the product.
1-2 pages
Certificate
ISO 27001 was designed to help organizations build and operate a systematic approach to managing information security. The output is a certificate issued by an accredited certification body. It confirms the company operates an ISMS that meets the standard's requirements, but does not describe individual controls or how they were tested. The system is the product, not the document.
Why this matters for your market
A company serving North American enterprise buyers will almost certainly need SOC 2 because those buyers want to read the report. A company serving European or multinational buyers may need ISO 27001 because the certificate is the accepted proof in those markets. The decision is driven by who you sell to, not by which framework is better.
Where the Controls Actually Overlap
The 70% overlap figure holds up when you map SOC 2 Trust Services Criteria against ISO 27001:2022 Annex A at the control level. Here is how the major security domains align, drawn from real SOC 2 control implementations.
Access Control
SOC 2 (CC6.1-CC6.3)
- Unique user IDs for all sensitive systems
- MFA and strong password enforcement
- Least-privilege provisioning
- Periodic access reviews
- Timely termination of access
- SSH key and access key restrictions
- Production infrastructure access via bastion host
ISO 27001 (Annex A)
- A.5.15 Access control policy
- A.5.18 Access rights management
- A.8.2 Privileged access rights
- A.8.3 Information access restriction
- A.8.5 Secure authentication
Bottom line: If SOC 2 access controls are implemented properly, ISO 27001's access control requirements are already satisfied. The one addition is a formal access control policy that explicitly references the ISMS, which most SOC 2 implementations already produce.
Change Management
SOC 2 (CC6.8, CC8.1)
- Baseline configurations managed securely
- Code tested before production deployment
- Independent approval for changes
- Dev/staging/production segregation
- No production data in test environments
- Secret detection in CI pipeline
ISO 27001 (Annex A)
- A.8.25 Secure development lifecycle
- A.8.26 Application security requirements
- A.8.31 Separation of environments
- A.8.32 Change management
- A.8.9 Configuration management
Bottom line: Nearly identical controls. ISO 27001 places slightly more emphasis on documenting the secure development lifecycle as a formal process, but any SOC 2 program with a Secure Development Policy and CI/CD controls already covers this.
Incident Response
SOC 2 (CC7.3-CC7.5)
- Documented Incident Response Plan
- Incident tracking and analysis
- Lessons learned documentation
- Periodic tabletop exercises
ISO 27001 (Annex A)
- A.5.24 Incident management planning
- A.5.25 Assessment and decision on events
- A.5.26 Response to incidents
- A.5.27 Learning from incidents
- A.6.8 Information security event reporting
Bottom line: Both expect the same lifecycle: plan, detect, respond, document, learn. ISO 27001 adds explicit requirements for event reporting channels (A.6.8), which SOC 2 handles less formally through communication controls.
Network Security and Monitoring
SOC 2 (CC6.6, CC7.1-CC7.2)
- Endpoint management and configuration
- Network traffic monitoring (SIEM, IDS/IPS)
- Firewall port/protocol restrictions
- Logging and alerting software
- DNS filtering and malicious domain blocking
- Network architecture diagrams
ISO 27001 (Annex A)
- A.8.20 Network security
- A.8.21 Security of network services
- A.8.22 Network segregation
- A.8.15 Logging
- A.8.16 Monitoring activities
Bottom line: Controls align closely. ISO 27001's network segregation requirement (A.8.22) is sometimes more explicit, but any SOC 2 program with environment segregation and network zoning already meets it.
Risk Management
This is where the frameworks diverge most significantly.
The gap
SOC 2 expects risk assessments, a risk register, and risk mitigation strategies. ISO 27001 requires all of that plus a structured risk treatment process that maps directly to the Statement of Applicability (SoA). Every Annex A control must be explicitly included or excluded with justification. Companies adding ISO 27001 to an existing SOC 2 program typically need to build the SoA and formalize the risk treatment methodology, even though the risk register and assessments already exist.
The Full Control Mapping
| Security Domain | SOC 2 Criteria | ISO 27001 Annex A | Overlap |
| Access control | CC6.1-CC6.3 | A.5.15, A.5.18, A.8.2, A.8.3, A.8.5 | ~95% |
| Change management | CC6.8, CC8.1 | A.8.9, A.8.25, A.8.31, A.8.32 | ~90% |
| Incident response | CC7.3-CC7.5 | A.5.24-A.5.27, A.6.8 | ~90% |
| Network security | CC6.6, CC7.1-CC7.2 | A.8.15, A.8.16, A.8.20-A.8.22 | ~85% |
| Vulnerability mgmt | CC7.1 | A.8.7, A.8.8, A.8.28 | ~85% |
| Encryption & data | CC6.1, CC6.6-CC6.7 | A.8.10-A.8.12, A.8.24 | ~80% |
| Vendor management | CC9.2 | A.5.19-A.5.22 | ~80% |
| Risk management | CC3.1-CC3.4, CC9.1 | Clause 6.1, A.5.1 | ~60% |
| Governance & org | CC1.1-CC1.5 | Clauses 4-10 | ~50% |
| Physical security | CC6.4-CC6.5 | A.7.1-A.7.14 | ~40% |
Where They Don't Overlap
The 30% that doesn't overlap falls into two categories: things ISO 27001 requires that SOC 2 doesn't, and things SOC 2 covers that ISO 27001 treats differently.
ISO 27001 Requires, SOC 2 Doesn't
ISMS Governance Structure
A formal Information Security Management System with defined scope, context of the organization (Clause 4), leadership commitment (Clause 5), and management review (Clause 9.3). SOC 2 expects governance but does not prescribe this formal structure.
Statement of Applicability (SoA)
Every Annex A control must be explicitly included or excluded with justification. SOC 2 has no equivalent requirement. This is typically the single largest piece of net-new work when adding ISO 27001.
Internal Audit Program (Clause 9.2)
The organization must conduct internal audits of the ISMS itself. SOC 2's audit is external by definition; it does not require the organization to audit its own program.
Continual Improvement (Clause 10.1)
A formal process for continual improvement of the ISMS. SOC 2 encourages improvement through monitoring (CC4.1, CC4.2) but does not require a formal improvement process.
Threat Intelligence (A.5.7)
ISO 27001:2022 added a specific control for threat intelligence collection and analysis. SOC 2 has no direct equivalent.
Physical Security (A.7.1-A.7.14)
14 controls covering physical security in detail: secure areas, clear desk, equipment siting, cabling security. SOC 2 addresses physical security under CC6.4 and CC6.5 but with far less granularity.
SOC 2 Addresses, ISO 27001 Treats Differently
Trust Services Categories Beyond Security
SOC 2 offers five categories: Security (required), Availability, Processing Integrity, Confidentiality, and Privacy. ISO 27001 touches on availability and confidentiality within Annex A, but does not provide the same structured, auditable criteria for these domains.
Detailed Audit Report
The SOC 2 report itself is a buyer-facing document. The depth of scrutiny it receives from procurement teams is materially different from how an ISO certificate is evaluated.
System Description
SOC 2 requires a formal system description documenting the service, infrastructure, people, processes, and controls. ISO 27001 requires ISMS scope documentation, but not a buyer-facing system description.
How to Decide
The decision is almost always driven by who you sell to, not by which framework is better.
SOC 2 first
Your buyers are in North America and ask for a SOC 2 report during procurement. Default for B2B SaaS, cloud providers, and IT service providers selling into US and Canadian enterprises.
ISO 27001 first
Your buyers are in Europe, the Middle East, Asia, or operating under regulations that reference ISO standards. Government procurement outside North America often requires it.
Both
You operate across markets or large enterprise customers require both. The 70% overlap means adding the second framework is 8-12 weeks of focused effort, not months.
The key insight: frameworks don't define your security program. They describe and test it. A company with a strong underlying security program can map it to SOC 2, ISO 27001, or both without redesigning anything. Build the program once. Map it many ways.
The Audit Experience
| Factor | SOC 2 | ISO 27001 |
| Auditor | Licensed CPA firm | Accredited certification body |
| Output | 40-60 page attestation report | 1-2 page certificate |
| Audit type | Type 1 (point-in-time) or Type 2 (observation period) | Stage 1 (documentation) + Stage 2 (implementation) |
| Cycle | Annual | 3-year cert with annual surveillance audits |
| Buyer use | Buyers read the report, evaluate controls | Buyers accept the certificate as proof |
| Scope | Systems processing customer data | Organization-wide ISMS |
| Cost range | $10,000-$50,000 CAD (varies by scope) | $10,000-$50,000 CAD (varies by scope) |
Build the Foundation Once
We help companies build effective security programs, then map them to SOC 2, ISO 27001, or both.
FAQ
How much of my SOC 2 work carries over to ISO 27001?
Roughly 70% of the controls transfer directly. Access controls, change management, incident response, encryption, vulnerability management, and vendor risk management are functionally identical in both frameworks. The remaining 30% is primarily ISO 27001's ISMS governance requirements (formal management review, internal audits, Statement of Applicability, continual improvement process) and more detailed physical security controls.
Can I run SOC 2 and ISO 27001 on the same GRC platform?
Yes. GRC platforms like Secureframe, Vanta, and Drata support multi-framework mapping. A single control implementation can satisfy both SOC 2 criteria and ISO 27001 Annex A requirements simultaneously. The platform handles the cross-referencing; you maintain one set of controls.
Which one do Canadian companies need?
It depends on who your customers are, not where you are incorporated. Canadian companies selling to US enterprises almost always need SOC 2. Canadian companies selling into European or global markets may need ISO 27001. Companies selling into both markets often pursue both, starting with whichever their largest revenue opportunity requires first.
Is ISO 27001 cheaper because the full audit only happens every three years?
Not significantly. ISO 27001 has annual surveillance audits between full certification cycles, and these carry their own costs. When you factor in surveillance audit fees, the ISMS maintenance overhead, and the internal audit requirement, the annual cost difference between the two frameworks is smaller than expected. Choose based on market requirements, not perceived cost savings.
Do I need to build two separate security programs?
No. This is the most common misconception. Build one effective security program as the foundation, then map it to each framework. The underlying controls remain the same. Each framework is a different lens applied to the same program. Companies that build framework-specific programs end up maintaining duplicate policies, duplicate evidence, and duplicate audit preparation processes.
How long does it take to add ISO 27001 if I already have SOC 2?
Typically 8 to 12 weeks of focused work to build the ISMS documentation, prepare the Statement of Applicability, close any gap controls (primarily physical security and ISMS governance), and prepare for the Stage 1 and Stage 2 audits. The timeline assumes the existing SOC 2 program is mature and well-documented.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
About the Author
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.