Crosswalk pair

ISO/IEC 27001 and SOX (Sarbanes-Oxley) Section 404, control by control

24 canonical controls in Keel’s library satisfy clauses of both ISO/IEC 27001 and SOX (Sarbanes-Oxley) Section 404. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.

Start free with ISO/IEC 27001 + SOX (Sarbanes-Oxley) Section 404 See all pairs

The overlap

What the two libraries have in common

Every figure here counts canonical controls in Keel’s library, not clauses of either standard. Each standard’s own authored count is on its framework page.

Controls that satisfy both

Canonical controls that crosswalk to at least one clause of each.

In Keel’s library for ISO/IEC 27001

51% of them also map to SOX (Sarbanes-Oxley) Section 404.

In Keel’s library for SOX (Sarbanes-Oxley) Section 404

83% of them also map to ISO/IEC 27001.

Evidence artifacts expected

Across the shared controls, from Keel’s evidence guidance. Gathered once.

ISO/IEC 27001 2022 51%

24 controls of 47 in Keel’s library for ISO/IEC 27001 also map to SOX (Sarbanes-Oxley) Section 404.
SOX (Sarbanes-Oxley) Section 404 Act of 2002 §404; COSO 2013 framework, 17 principles 83%

24 controls of 29 in Keel’s library for SOX (Sarbanes-Oxley) Section 404 also map to ISO/IEC 27001.

The mapping

Controls that satisfy both

Each row is one control in Keel’s library and the clauses it answers on each side. Do the work once; both columns are then evidenced by the same artifacts.

ISO/IEC 27001 and SOX (Sarbanes-Oxley) Section 404 controls that satisfy both, with the clauses each maps to
Canonical control	ISO/IEC 27001 clauses	SOX (Sarbanes-Oxley) Section 404 clauses
Governance & Risk
Delegation of authority & segregation of duties Approval authority and spending limits are defined, assigned to named roles, reviewed as the organization changes, and enforced in the systems that execute transactions - so no one person can initiate, approve, record and reconcile the same transaction.	A.5.3	P3, P5, P10
Document & records control Documented information is created, approved, versioned, and controlled; records are retained and protected for a defined minimum period - measured from the document’s creation OR from the date it last was in effect, whichever is later, so a policy that stayed in force for years does not start its clock on the day it was written - and are available to the people who have to act on the procedures they describe. Documentation is reviewed on a schedule and updated when an operational, environmental or legal change has made the current version wrong. A change forced by law is documented and put into effect promptly, and where that legal change materially affects what the organization has published to individuals about how it handles their data, THAT NOTICE IS REVISED TOO, as part of the same prompt action rather than as a separate task left to whoever owns the notice. Any other change may be made at any time provided the revised version still complies and IS DOCUMENTED BEFORE THE CHANGE TAKES EFFECT - the record precedes the effective date, so a routine that documents changes in arrears does not discharge this.	7.5, A.5.37	P12
Information security policy A board-approved policy set covering information security and the handling of personal data, sized to the scale of the organization and the type of activities it actually carries out, reviewed at least annually and communicated to the workforce. The policy set states the direction the organization is taking on information security - what it commits to, and what it requires of everyone doing work for it - so it sets where the programme is going rather than only recording what it already does. One or more named individuals are designated to coordinate the programme the policies describe - the person in charge of it, named rather than implied, with the designation recorded in writing, made known to the people who need it and kept current as roles change - so there is someone who answers for the policies being carried out and not only for their being published. How far the policies go, and how far the measures they require go, is judged against four things together: the organization’s size, complexity and capabilities; its technical infrastructure and the security capabilities of its hardware and software; what the measures cost; and how likely the risks they address are and how much damage they would do. A policy may be changed at any time, provided the change is documented and is actually put into effect rather than only written down.	5.2, A.5.1	P12
Internal audit program A risk-based internal audit program evaluates conformity and effectiveness at planned intervals, and again when an environmental or operational change could have undermined what was last evaluated; each evaluation covers both technical testing and non-technical review of whether the documented policies and procedures are actually being met. The programme itself is written down - how often audits run, what methods they use, who is responsible for them, what each one covers and how it reports - and nobody audits their own work, so a finding is an independent judgement rather than a self-assessment. The results of each audit go to the management responsible for the area audited, and the programme and its results are retained as evidence that it ran.	9.2, A.5.35	P16
Management review Leadership reviews how the management system is performing at planned intervals and decides what to do about it: what will be improved, and what about the system itself has to change. Each decision leaves the review with a named owner and a date rather than as a sentiment in the minutes, the previous review’s decisions are picked back up at the next one so nothing is decided twice and never done, and the record of the review and its outputs is retained.	9.3	P16
Nonconformity & corrective action (CAPA) When something fails to meet a requirement, the first response is to contain it: the nonconforming output is controlled so it goes no further, what has already gone wrong is corrected, and the consequences of it are dealt with. Then the question of cause is asked - why it happened, and whether the same failure exists somewhere else or could happen somewhere else - and where the answer warrants action, that action is taken and tracked to closure. Afterwards the action is reviewed for whether it actually removed the cause rather than only for whether it was completed, the management system is changed where the review shows it has to be, and the nonconformity, what was done about it and the result of doing it are all recorded.	10.2	P17
Access Control
Access control policy Rules for granting, reviewing, and revoking access to systems and data based on business need and least privilege; anyone who works with sensitive data, or in a place from which it can be reached, is individually authorized for that work or supervised while doing it; and a documented emergency route exists to obtain the data when the normal access path is unavailable, with every use of that route recorded and reviewed afterwards.	A.5.15	P11
Multi-factor authentication Documented procedures verify that a person or system seeking access to sensitive data is the one it claims to be, on every path by which that data can be reached - and multi-factor authentication is the enforced mechanism for remote access, administrative access, and access to sensitive systems and data. The multi-factor mechanism itself is configured so it cannot be bypassed, so the factors it uses are genuinely independent of one another - one factor’s success granting no knowledge of and no route around another - and so access is refused unless every factor required has succeeded.	A.8.5	P11
User provisioning & deprovisioning Joiner/mover/leaver process to grant, change, and promptly remove access across systems, in which every person is issued an account of their own carrying a unique name or number, so an action in a log traces back to one named individual rather than to a shared or generic login. Each person’s right of access is recorded when it is established and reviewed on a schedule thereafter, as well as granted and changed - so what someone holds is a documented position that has been looked at again, not the accumulated residue of past requests - and what may be granted follows the organization’s access authorization rules rather than the judgement of whoever processes the request.	A.8.3	P11
Data Protection & Privacy
Encryption in transit & at rest Strong cryptography protects sensitive data in transit over public networks and at rest in storage.	A.8.24	P11
Infrastructure & Operations
Asset inventory An inventory of hardware, software, and information assets with assigned owners, in which the movement of equipment and removable media into, out of, and within the organization’s premises is recorded against the person responsible for it.	A.5.9	P11
Change management Changes to systems and software are requested, reviewed, tested, approved, and tracked.	A.8.32	P9, P11
Logging & monitoring Security-relevant events - including successful and failed log-in attempts - are logged, protected, retained, and reviewed for anomalies, and the discrepancies that review finds are reported to the people who act on them. The review runs on a defined cadence and covers the records of system activity as a set - the audit logs, the reports of who accessed what, and the record of security incidents - rather than the log stream alone.	A.8.15, A.8.16	P11
Network security controls Firewalls/segmentation and network controls restrict traffic to and from sensitive environments.	A.8.20, A.8.22	P11
Secure software development Secure coding, review, and testing practices across the development lifecycle.	A.8.25	P11
Vulnerability management Regular scanning, prioritization, and remediation of vulnerabilities across systems and applications, fed by current information about threats and weaknesses collected from outside the organization as well as from its own scans - vendor and industry security advisories for the software actually in use, and the threat feeds, bulletins and sector reporting that describe how systems like these are being attacked now - which is gathered continuously rather than at the next scan, evaluated for whether it applies here, and used to decide what is looked for and what is fixed first.	A.5.7, A.8.8	P11
Resilience & Continuity
Backups Regular, tested backups of critical data and systems with defined retention, each one a RETRIEVABLE EXACT COPY of the data it protects - complete and restorable, not a partial or lossy snapshot - including a copy taken before equipment holding that data is moved.	A.8.13	P11
Business continuity & disaster recovery BC/DR plans with defined RTO/RPO, tested periodically AND REVISED on what the testing finds and on what has changed since, to restore service after disruption - including how the critical processes that protect sensitive data keep running while the organization is operating in emergency mode, and an assessment of how critical each application and data set is, which is what sets those recovery targets and the order in which things come back.	A.5.30	P11
Incident response A documented, tested plan to detect, triage, contain, remediate, and communicate security incidents, and to mitigate - so far as is practicable - the harmful effect of a use or disclosure of personal data the organization knows breached its own policies or the law. Each incident is recorded together with its outcome - what happened, what was done about it and how it ended - as a record of that incident, which is a different artifact from the plan being documented. The mitigation duty runs to violations by the organization itself AND to violations by the processors, vendors and other parties handling that data on its behalf: the plan reaches an incident somebody else caused with the organization’s data, so learning of one triggers the same containment and remediation as an incident inside its own walls rather than a request that the other party deal with it. Where an incident carries a duty to tell someone outside the organization, the plan discharges it on the clock the applicable law sets rather than whenever the investigation happens to conclude: whether an incident is notifiable is decided against written criteria rather than argued after the fact, the regulator or supervisory authority is notified inside the deadline that regime states, the people whose data is affected are told where the risk to them warrants it, and where a deadline is missed the notification itself explains the delay instead of passing over it.	A.5.24, A.5.26	P11
Third-party Risk
Third-party / vendor risk management Due diligence, contractual safeguards, and ongoing monitoring of vendors that handle your data: the agreement obliges the vendor to comply in its own right with the security requirements that apply to it - an absolute standard, not a promise to match whatever you happen to do - to pass those obligations down to any subcontractor it brings in BY ENTERING INTO a contract or equivalent written arrangement with that subcontractor rather than by merely requiring equivalent practice of it, and to report to you, within a stated time, security incidents it becomes aware of and confirmed breaches of your data. Where a contract is not the instrument available, an equivalent written arrangement carrying the same obligations discharges the duty. The same obligations, together with the separation that keeps a related organization out of data it is not entitled to, are written into the governing document of any other arrangement that puts your data in the hands of a sponsor, parent, affiliate or plan. Diligence is not confined to security where the relationship warrants more: for suppliers significant enough to matter, the organization states the standards of conduct it expects of them - how they behave commercially and how they treat the environment around their operations - and screens candidates and incumbents against those stated expectations as part of the same selection and monitoring cycle, rather than accepting a signature on a code as evidence of it.	A.5.19	P11, P15
People & Culture
Competence management The competence each role in the management system needs is determined and written down, and the people in those roles are established as having it - on the basis of their education, training or experience rather than on the basis of holding the job. Where the competence is not there, something is done about it - training, mentoring, supervision, reassignment or hiring - and the action is afterwards evaluated for whether it produced the competence, not merely for whether it was delivered. The records that show all of this are retained.	7.2	P4
Personnel security (HR) Background screening, confidentiality agreements, and onboarding/offboarding security steps. Before a person is given access to sensitive data, and again whenever their role changes, a documented determination is made that the access their work calls for is appropriate to it - the screening informs that decision but is not the decision. What screening may ask is itself bounded: enquiries about a candidate’s health, disability or medical history are not made, and medical examinations are not required, before a conditional offer of the role has been made, and where such enquiries or examinations are made after an offer they are applied to everyone entering that role rather than to the individuals somebody chose to ask. Access is ended when their employment, or any other arrangement under which they worked for the organization, comes to an end, and whenever that determination says they should no longer hold it.	A.6.1, A.6.5	P4
Security awareness training Ongoing security and data-handling awareness training for all personnel, with completion tracking, and periodic security updates - reminders, bulletins and alerts - issued to the workforce between training cycles. New joiners are trained within a defined period of starting, anyone whose work is affected is retrained within a defined period after a material change to the policies or procedures, and every completion is recorded.	A.6.3	P4, P14
Physical & Environmental
Physical security Physical access to facilities and equipment holding sensitive data is restricted and monitored, and a person’s access is validated against the role or function that justifies it rather than only logged; visitors are controlled as a case of their own, and so is access to software programs held for testing and revision. The facility and the equipment in it are safeguarded against tampering and theft as well as against unauthorized entry. The people who have to reach the site and the equipment when a continuity or recovery plan is invoked can still get in, by a route that is planned rather than improvised; and repairs and modifications to the physical security components of a facility - doors, locks, walls, and the hardware that controls entry - are recorded.	A.7.1, A.7.2	P11

Beyond the pair

Where else this work counts

A framework is lit when a shared control above also maps to it. Unlit means none of them do — an absence, not a judgment about that standard.

Also reached by these 24 controls

AI Governance Essentials
Amazon Appstore Child-Directed Apps
Apple App Store Kids Category
CIS Critical Security Controls
COPPA
ESG Essentials
EU AI Act
GDPR
Google Play Families
HIPAA
ISO 9001
ISO/IEC 42001
NIST AI Risk Management Framework
NIST Cybersecurity Framework
NIST SP 800-171
NIST SP 800-53
PCI DSS
SOC 2
US Employment Law - Federal Baseline

Nearby pairs

The thesis

Why this is one project, not two

On a crosswalk-native model, SOX (Sarbanes-Oxley) Section 404 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.

Next step

Add SOX (Sarbanes-Oxley) Section 404 to the work you already did

Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.

Start free with ISO/IEC 27001 + SOX (Sarbanes-Oxley) Section 404 See all pairs