SOC 2 vs ISO 27001: Same Policy, Different Citations
Published July 22, 2026 · 7 min read
TL;DR
SOC 2 and ISO 27001 share most of their control requirements at the policy level. The difference is not what you write — it is how you cite it. SOC 2 references the AICPA Trust Services Criteria (CC6.1, CC7.2). ISO 27001 references Annex A controls (A.5.15, A.8.5). If you write framework-agnostic policies from the start, adding a second framework means mapping citations — not rewriting documentation. If you don’t, you fall into the rewrite trap.
The Shared Controls Most Teams Never Map
When a startup finishes SOC 2 and a prospect asks about ISO 27001, the first question is always: “How much of this do we have to do again?”
The answer, if you did SOC 2 right: not as much as you think. SOC 2 and ISO 27001 both require controls for access management, encryption, incident response, vendor risk, change management, and business continuity. The core security work — MFA enforcement, access reviews, vulnerability scanning, backup verification — is identical regardless of which framework you are pursuing.
The AICPA Trust Services Criteria and ISO 27001:2022 Annex A address the same risk domains. What differs is the structural lens:
- SOC 2 organizes controls under five Trust Services Categories (Security, Availability, Processing Integrity, Confidentiality, Privacy). The criteria are principles-based: your controls must satisfy the stated criteria, but the standard does not prescribe specific controls.
- ISO 27001 organizes controls under four Annex A categories (Organizational, People, Physical, Technological) with 93 named controls. The standard prescribes a risk-driven control selection process documented in a Statement of Applicability (SoA).
In practice, most of the control effort overlaps. An access control policy, a vulnerability management procedure, an incident response plan — these serve both frameworks. The work is identical. The label changes.
What Actually Differs: Citations, Not Policy Body
Here is a concrete example. Take access control — one of the most scrutinized domains in both frameworks.
This criterion requires that the entity restricts logical and physical access to information assets using access control software, policies, and architecture. Auditors look for: documented access provisioning workflows, least-privilege enforcement, periodic access reviews, and MFA.
Rules to control physical and logical access to information shall be established and implemented based on business and information security requirements. Access to information and associated assets shall be restricted in accordance with the established access control policy. Secure authentication technologies and procedures shall be implemented based on information access restrictions.
The underlying policy content is identical: define who gets access, enforce least privilege, require MFA, review access quarterly. What changes is the citation. Your SOC 2 evidence package references CC6.1. Your ISO 27001 SoA maps the same policy to A.5.15, A.8.3, and A.8.5.
If your access control policy says “This policy satisfies SOC 2 CC6.1” in its header, you have a problem when ISO 27001 comes around — not because the policy is wrong, but because the citation is framework-bound.
Beyond Access Control: Five Overlapping Domains
Access control is not the only area where the security work is identical. Here are five domains where your policies serve both frameworks with different citation wrappers:
| Domain | SOC 2 Criteria | ISO 27001:2022 Controls | What You Actually Write |
|---|---|---|---|
| Access control | CC6.1, CC6.2, CC6.3 | A.5.15, A.8.2, A.8.3, A.8.5 | Least-privilege policy, access review procedure, MFA requirements |
| Incident response | CC7.3, CC7.4, CC7.5 | A.5.24, A.5.25, A.5.26, A.5.27 | IR plan, escalation matrix, post-incident review process |
| Change management | CC8.1 | A.8.9, A.8.25, A.8.32, A.8.33 | SDLC policy, code review requirements, deployment procedures |
| Encryption | CC6.1 (sub-criteria) | A.8.24 | TLS 1.2+ in transit, AES-256 at rest, key management |
| Vendor management | CC9.2 | A.5.19, A.5.20, A.5.21, A.5.22 | Vendor risk assessment questionnaire, annual review cadence |
The pattern repeats across every domain: the security work is the same. The citation wrapper is different. Teams that build framework-agnostic documentation from day one can add a second framework in weeks, not months.
The Rewrite Trap
The rewrite trap catches teams that bind their policies to a single framework.
It works like this: your startup completes SOC 2. Your policies, procedures, and evidence packages all reference SOC 2 criteria by number — CC6.1 in policy headers, CC7.2 in monitoring procedures, CC8.1 in change management documentation. Everything works perfectly for your SOC 2 Type II audit.
Then a European prospect asks for ISO 27001 certification. You pull out the SOC 2 policy suite and discover every document is framework-specific. Headers reference CC criteria. Evidence mappings are SOC 2-only. Your auditor cannot use this documentation for an ISO 27001 audit because the citation structure does not match Annex A.
The fix is not a small change. You are now rewriting 15–25 policy documents — not because the security content is wrong, but because the framework references are hard-coded throughout. This rewrite typically takes 6–12 weeks and is entirely avoidable.
How VylintShield Eliminates the Rewrite Problem
VylintShield was built for this exact problem. Write one policy, map it to every framework your customers require — SOC 2, ISO 27001, HIPAA, PCI-DSS — from a single document.
Here is what that looks like in practice:
- You write an access control policy once. VylintShield maps it to SOC 2 CC6.1, ISO 27001 A.5.15/A.8.3/A.8.5, and HIPAA §164.312(d) simultaneously.
- When a SOC 2 auditor asks for evidence, the citations are there. When a different auditor asks for your ISO 27001 SoA, the same policy maps cleanly.
- No rewriting. No framework-specific document sprawl. One assessment workflow produces audit-ready documentation for multiple frameworks without duplicating work.
This is the approach shown in the demo above — a single assessment that handles SOC 2, ISO 27001, and HIPAA from one workflow.
Ready to build multi-framework compliance from day one?
Stop writing single-framework policies that lock you into rewrites. VylintShield maps your security controls to SOC 2, ISO 27001, HIPAA, and more — from one workflow.
Start a free assessment →In 15 minutes, you’ll know exactly where you stand across every framework your customers require.