ISO/IEC 27001 ↔ PCI DSS
19 canonical controls in Keel's library satisfy clauses of both ISO/IEC 27001 and PCI DSS. 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 | ISO/IEC 27001 clauses | PCI DSS clauses |
|---|---|---|
| Information security policy A board-approved information security policy set, reviewed at least annually and communicated to the workforce. | A.5.1 | 12.1 |
| Risk assessment & treatment A documented process to identify, analyze, evaluate, and treat information security risks on a defined cadence. | A.5.7 | 12.3 |
| Access control policy Rules for granting, reviewing, and revoking access to systems and data based on business need and least privilege. | A.5.15 | 7.1, 7.2 |
| User provisioning & deprovisioning Joiner/mover/leaver process to grant, change, and promptly remove access across systems. | A.8.3 | 8.2 |
| Multi-factor authentication MFA enforced for remote access, administrative access, and access to sensitive systems and data. | A.8.5 | 8.4, 8.5 |
| Encryption in transit & at rest Strong cryptography protects sensitive data in transit over public networks and at rest in storage. | A.8.24 | 3.5, 4.2 |
| Logging & monitoring Security-relevant events are logged, protected, retained, and reviewed for anomalies. | A.8.15, A.8.16 | 10.2, 10.3, 10.4 |
| Vulnerability management Regular scanning, prioritization, and remediation of vulnerabilities across systems and applications. | A.8.8 | 6.3, 11.3 |
| Malware protection Anti-malware controls prevent, detect, and respond to malicious software on endpoints and servers. | A.8.7 | 5.2, 5.3 |
| Incident response A documented, tested plan to detect, triage, contain, remediate, and communicate security incidents. | A.5.24, A.5.26 | 12.10 |
| Change management Changes to systems and software are requested, reviewed, tested, approved, and tracked. | A.8.32 | 6.5 |
| Third-party / vendor risk management Due diligence, contractual safeguards, and ongoing monitoring of vendors that handle your data. | A.5.19 | 12.8 |
| Security awareness training Ongoing security awareness training for all personnel, with completion tracking. | A.6.3 | 12.6 |
| Asset inventory An inventory of hardware, software, and information assets with assigned owners. | A.5.9 | 12.5 |
| Physical security Physical access to facilities and equipment holding sensitive data is restricted and monitored. | A.7.1, A.7.2 | 9.2 |
| Secure software development Secure coding, review, and testing practices across the development lifecycle. | A.8.25 | 6.2 |
| Network security controls Firewalls/segmentation and network controls restrict traffic to and from sensitive environments. | A.8.20, A.8.22 | 1.2, 1.3 |
| Data retention & secure disposal Data is retained per policy and securely destroyed when no longer needed. | A.8.10 | 3.2 |
| Personnel security (HR) Background screening, confidentiality agreements, and onboarding/offboarding security steps. | A.6.1, A.6.5 | 12.7 |
Clause identifiers (ISO/IEC 27001 and PCI DSS) 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, PCI DSS 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.