ISO/IEC 27001 ↔ SOC 2

24 canonical controls in Keel's library satisfy clauses of both ISO/IEC 27001 and SOC 2. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don't repeat.

24 shared controls ISO/IEC 27001 · 2022: 25 in library SOC 2 · 2017 TSC (rev. 2022): 25 in library

Start free with ISO/IEC 27001 + SOC 2 See all pairs

Controls that satisfy both

Canonical control	ISO/IEC 27001 clauses	SOC 2 clauses
Information security policy A board-approved information security policy set, reviewed at least annually and communicated to the workforce.	A.5.1	CC5.3
Risk assessment & treatment A documented process to identify, analyze, evaluate, and treat information security risks on a defined cadence.	A.5.7	CC3.1, CC3.2
Access control policy Rules for granting, reviewing, and revoking access to systems and data based on business need and least privilege.	A.5.15	CC6.1, CC6.3
User provisioning & deprovisioning Joiner/mover/leaver process to grant, change, and promptly remove access across systems.	A.8.3	CC6.2, CC6.3
Multi-factor authentication MFA enforced for remote access, administrative access, and access to sensitive systems and data.	A.8.5	CC6.1
Encryption in transit & at rest Strong cryptography protects sensitive data in transit over public networks and at rest in storage.	A.8.24	CC6.7
Logging & monitoring Security-relevant events are logged, protected, retained, and reviewed for anomalies.	A.8.15, A.8.16	CC7.2
Vulnerability management Regular scanning, prioritization, and remediation of vulnerabilities across systems and applications.	A.8.8	CC7.1
Malware protection Anti-malware controls prevent, detect, and respond to malicious software on endpoints and servers.	A.8.7	CC6.8
Backups Regular, tested backups of critical data and systems with defined retention.	A.8.13	A1.2
Business continuity & disaster recovery BC/DR plans with defined RTO/RPO, tested periodically, to restore service after disruption.	A.5.30	A1.2, A1.3
Incident response A documented, tested plan to detect, triage, contain, remediate, and communicate security incidents.	A.5.24, A.5.26	CC7.3, CC7.4
Change management Changes to systems and software are requested, reviewed, tested, approved, and tracked.	A.8.32	CC8.1
Third-party / vendor risk management Due diligence, contractual safeguards, and ongoing monitoring of vendors that handle your data.	A.5.19	CC9.2
Security awareness training Ongoing security awareness training for all personnel, with completion tracking.	A.6.3	CC1.4
Asset inventory An inventory of hardware, software, and information assets with assigned owners.	A.5.9	CC6.1
Data classification & handling Information is classified and handled per its sensitivity, with rules for labeling and protection.	A.5.12	C1.1
Physical security Physical access to facilities and equipment holding sensitive data is restricted and monitored.	A.7.1, A.7.2	CC6.4
Secure software development Secure coding, review, and testing practices across the development lifecycle.	A.8.25	CC8.1
Network security controls Firewalls/segmentation and network controls restrict traffic to and from sensitive environments.	A.8.20, A.8.22	CC6.6
Data retention & secure disposal Data is retained per policy and securely destroyed when no longer needed.	A.8.10	C1.2
Personnel security (HR) Background screening, confidentiality agreements, and onboarding/offboarding security steps.	A.6.1, A.6.5	CC1.4
Document & records control Documented information is created, approved, versioned, and controlled; records are retained and protected.	A.5.37	CC5.3
Internal audit program A risk-based internal audit program evaluates conformity and effectiveness at planned intervals.	A.5.35	CC4.1

Clause identifiers (ISO/IEC 27001 and SOC 2) are referenced factually for mapping. Keel is not affiliated with or endorsed by the bodies that publish these standards. Control descriptions are Keel's own; a framework's full authored control count is on its framework page.

Why this is one project, not two

On a crosswalk-native model, SOC 2 mostly lights up controls you already built for ISO/IEC 27001. You're not re-uploading the same screenshot for a second audit. You apply the framework and see the genuine delta worth working. That's the whole idea behind collect once, comply everywhere.