guide
ISO 27001 vs SOC 2: a practical mapping guide
If you've already done one, you're closer to the other than you think. This guide maps ISO 27001:2022 Annex A controls to SOC 2 Trust Services Criteria so you can reuse evidence, avoid duplicate work, and scope a combined audit.
TL;DR
- ISO 27001 is a certifiable management-system standard. You build an ISMS, pick controls from Annex A (93 controls in the 2022 revision), and an accredited body certifies it.
- SOC 2 is an AICPA attestation. An auditor reports on how your controls meet the five Trust Services Criteria (Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional).
- Roughly 80% of ISO 27001 Annex A controls overlap with SOC 2 Common Criteria. Plan one control set, two reports.
Scope and audience
ISO 27001 targets a global audience and is the de-facto requirement for selling into EU, APAC, and regulated industries. SOC 2 is the dominant trust signal for North American SaaS buyers. If your customers span both, doing the work once is meaningfully cheaper than running two independent programs.
Annex A → Trust Services Criteria crosswalk
High-overlap controls. Use this as a starting point — your auditor decides the final mapping based on your environment.
| ISO 27001 Annex A | SOC 2 TSC | Notes |
|---|---|---|
A.5.1 Policies for information security | CC1.1, CC5.3 Control Environment / Policies | Both require board-approved security policies reviewed at planned intervals. |
A.5.2 Information security roles and responsibilities | CC1.3 Org. Structure & Authority | Document a RACI and security org chart; ISO is more explicit about segregation. |
A.5.7 Threat intelligence | CC3.2, CC7.1 Risk Identification / Monitoring | SOC 2 covers this indirectly via risk assessment; ISO 2022 makes it explicit. |
A.5.9 Inventory of information and other associated assets | CC6.1 Logical Access — Asset Inventory | Maintain a single asset register that feeds access reviews. |
A.5.15 Access control | CC6.1, CC6.2, CC6.3 Logical & Physical Access | Direct overlap. One IAM policy can satisfy both. |
A.5.23 Information security for use of cloud services | CC9.2 Vendor Risk Management | Cloud-provider due diligence + shared responsibility documentation. |
A.5.30 ICT readiness for business continuity | A1.2, A1.3 Availability — BCP/DR | Only relevant to SOC 2 if Availability TSC is in scope. |
A.6.3 Information security awareness, education and training | CC1.4, CC2.2 Competence / Communication | Annual training + onboarding training satisfies both. |
A.6.6 Confidentiality or non-disclosure agreements | CC1.4, CC2.3 Internal/External Communication | NDA on hire and with vendors handling customer data. |
A.6.8 Information security event reporting | CC2.3, CC7.3 Incident Communication | Whistleblower / event-reporting channel to security team. |
A.7.4 Physical security monitoring | CC6.4 Physical Access | N/A for fully cloud-hosted SaaS — inherit from cloud provider. |
A.8.2 Privileged access rights | CC6.1, CC6.3 Privileged Access | Just-in-time access, quarterly privileged access reviews. |
A.8.5 Secure authentication | CC6.1 Authentication | MFA for all production access; SSO with strong password policy. |
A.8.7 Protection against malware | CC6.8 Malicious Software Prevention | EDR on endpoints + container image scanning. |
A.8.9 Configuration management | CC7.1, CC8.1 Change Management | IaC + drift detection covers both. |
A.8.12 Data leakage prevention | CC6.7 Data Transmission & Disposal | DLP rules on email + sanctioned data egress paths. |
A.8.13 Information backup | A1.2 Availability — Backups | Tested restores quarterly; only required for Availability TSC. |
A.8.15 Logging | CC7.2, CC7.3 Monitoring & Anomaly Detection | Centralized log aggregation with alerting. |
A.8.16 Monitoring activities | CC7.2 Monitoring | SIEM or equivalent with documented runbooks. |
A.8.24 Use of cryptography | CC6.1, CC6.7 Encryption | TLS 1.2+ in transit, AES-256 at rest, documented key management. |
A.8.25 Secure development life cycle | CC8.1 Change Management — SDLC | Peer review, automated tests, security review for sensitive changes. |
A.8.28 Secure coding | CC8.1 SDLC — Secure Coding | SAST + dependency scanning in CI. |
A.8.32 Change management | CC8.1 Change Management | One change-management process documents both. |
Where they differ
ISO-only emphasis
- Formal ISMS, Statement of Applicability, and risk treatment plan
- Management review meetings and internal audit program
- Continual improvement clauses (4–10)
SOC 2-only emphasis
- Operating effectiveness over an audit window (Type II)
- Detailed evidence sampling per control
- Customer-facing report distributed under NDA
Sequence and timeline
- Pick the broader framework first. Most teams start with SOC 2 Type I (4–8 weeks), then layer ISO 27001 (4–6 months) using the same controls.
- Define one control library with mappings to both frameworks. Tag each piece of evidence with the controls it satisfies.
- Run a combined readiness assessment. Auditors familiar with both will surface gaps in either direction.
- Schedule the SOC 2 Type II window to overlap with the ISO Stage 2 audit so evidence collection is concurrent.
Skip the spreadsheet
SecFrame Explorer has every ISO 27001 and SOC 2 control with plain-English AI explanations and implementation guidance for AWS, Azure, GCP, and Kubernetes.