NIST SP 800-53 ↔ SOC 2
23 canonical controls in Keel's library satisfy clauses of both NIST SP 800-53 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.
Controls that satisfy both
| Canonical control | NIST SP 800-53 clauses | SOC 2 clauses |
|---|---|---|
| Information security policy A board-approved information security policy set, reviewed at least annually and communicated to the workforce. | PL-1 | CC5.3 |
| Risk assessment & treatment A documented process to identify, analyze, evaluate, and treat information security risks on a defined cadence. | RA-3, RA-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. | AC-1, AC-2, AC-3, AC-6 | CC6.1, CC6.3 |
| User provisioning & deprovisioning Joiner/mover/leaver process to grant, change, and promptly remove access across systems. | AC-2, PS-4, PS-5 | CC6.2, CC6.3 |
| Multi-factor authentication MFA enforced for remote access, administrative access, and access to sensitive systems and data. | IA-2 | CC6.1 |
| Encryption in transit & at rest Strong cryptography protects sensitive data in transit over public networks and at rest in storage. | SC-13, SC-28, SC-8 | CC6.7 |
| Logging & monitoring Security-relevant events are logged, protected, retained, and reviewed for anomalies. | AU-2, AU-6, AU-12 | CC7.2 |
| Vulnerability management Regular scanning, prioritization, and remediation of vulnerabilities across systems and applications. | RA-5, SI-2 | CC7.1 |
| Malware protection Anti-malware controls prevent, detect, and respond to malicious software on endpoints and servers. | SI-3 | CC6.8 |
| Backups Regular, tested backups of critical data and systems with defined retention. | CP-9 | A1.2 |
| Business continuity & disaster recovery BC/DR plans with defined RTO/RPO, tested periodically, to restore service after disruption. | CP-2, CP-10 | A1.2, A1.3 |
| Incident response A documented, tested plan to detect, triage, contain, remediate, and communicate security incidents. | IR-4, IR-5, IR-6, IR-8 | CC7.3, CC7.4 |
| Change management Changes to systems and software are requested, reviewed, tested, approved, and tracked. | CM-3 | CC8.1 |
| Third-party / vendor risk management Due diligence, contractual safeguards, and ongoing monitoring of vendors that handle your data. | SA-9, SR-3, SR-6 | CC9.2 |
| Security awareness training Ongoing security awareness training for all personnel, with completion tracking. | AT-2, AT-3, AT-4 | CC1.4 |
| Asset inventory An inventory of hardware, software, and information assets with assigned owners. | CM-8 | CC6.1 |
| Data classification & handling Information is classified and handled per its sensitivity, with rules for labeling and protection. | RA-2 | C1.1 |
| Physical security Physical access to facilities and equipment holding sensitive data is restricted and monitored. | PE-2, PE-3, PE-6 | CC6.4 |
| Secure software development Secure coding, review, and testing practices across the development lifecycle. | SA-3, SA-8, SA-11 | CC8.1 |
| Network security controls Firewalls/segmentation and network controls restrict traffic to and from sensitive environments. | SC-7, AC-4 | CC6.6 |
| Data retention & secure disposal Data is retained per policy and securely destroyed when no longer needed. | MP-6, SI-12 | C1.2 |
| Personnel security (HR) Background screening, confidentiality agreements, and onboarding/offboarding security steps. | PS-2, PS-3, PS-6, PS-7 | CC1.4 |
| Internal audit program A risk-based internal audit program evaluates conformity and effectiveness at planned intervals. | CA-2 | CC4.1 |
Clause identifiers (NIST SP 800-53 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 NIST SP 800-53. 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.