Crosswalk pair
ISO/IEC 42001 and SOX (Sarbanes-Oxley) Section 404, control by control
5 canonical controls in Keel’s library satisfy clauses of both ISO/IEC 42001 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.
ISO/IEC 42001 counts as one of your plan’s paid frameworks, or from $39/mo as an add-on. SOX (Sarbanes-Oxley) Section 404 counts as one of your plan’s paid frameworks, or from $49/mo as an add-on. See plans and pricing.
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.
5
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
38
In Keel’s library for ISO/IEC 42001
13% of them also map to SOX (Sarbanes-Oxley) Section 404.
32
In Keel’s library for SOX (Sarbanes-Oxley) Section 404
16% of them also map to ISO/IEC 42001.
15
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
ISO/IEC 42001 13%
5 controls of 38 in Keel’s library for ISO/IEC 42001 also map to SOX (Sarbanes-Oxley) Section 404.
-
SOX (Sarbanes-Oxley) Section 404 16%
5 controls of 32 in Keel’s library for SOX (Sarbanes-Oxley) Section 404 also map to ISO/IEC 42001.
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.
| Canonical control | ISO/IEC 42001 clauses | SOX (Sarbanes-Oxley) Section 404 clauses |
|---|---|---|
| Governance & Risk | ||
| 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. Records are protected for as long as they are kept, and against more than deletion: against loss, against destruction, against falsification, against being read by somebody with no entitlement to them, and against being released outside the organization without authority. The protection applied to a class of record is decided from the requirements attached to it - what the law, the regulator or the contract demands of that record type, and what it would cost if it were lost or altered - rather than from where it happens to be stored. Records are held so that a change to one is attributable and detectable rather than silent, the storage medium and format are chosen to remain readable for the whole retention period and the information is migrated before either stops being so, and the ability to retrieve a record intact is exercised rather than assumed. What the set of documented information consists of is itself a decision rather than an accumulation: it comprises the documented information the standard the system is built against explicitly requires, plus whatever else the organization determines is necessary for the system to be effective - and the second half is decided against the size of the organization and the kind of activity, product and service it deals in, the complexity of its processes, and the competence of its people, so a small organization is not judged against a large one’s binder and a large one cannot claim a small one’s. | 7.5 | 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 program 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 judgment rather than a self-assessment. The results of each audit go to the management responsible for the area audited, and the program and its results are retained as evidence that it ran. It rests on a documented assessment, authorization and monitoring policy with supporting procedures, issued to the roles it binds, owned by a named official, and reviewed and updated on a defined cadence. Independence is a property of the assessor and not only of the reporting line: assessments are carried out by assessors or assessment teams with no responsibility for what they are assessing and no stake in the result - internal to the organization but outside the area, or brought in from outside it - and the organization states what level of independence it requires before the assessment is commissioned rather than judging it afterwards. That independence extends to the ongoing case as well as the scheduled one: where controls are monitored continuously between audits, independent assessors monitor them too, so the periodic audit is not the only unbiased look the organization ever takes. What an evaluation produces is treated as an input to improvement and not only as a conformity verdict: the findings, the observations and the opportunities each audit identifies are recorded as improvements with owners and dates and carried into the organization’s improvement process, so an audit changes something rather than closing. Where a regime names the parties an assessment result must reach, such as a regulator, a certifying body or the customers the assessed service serves, the results go to those parties as well as to the management responsible for the area audited. | 9.2 | 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. The risk management strategy is one of the review’s standing subjects: what the strategy actually produced is reviewed for what it says about the direction being taken, and the strategy itself is then reviewed and adjusted for whether it still covers the requirements the organization is under and the risks on its register - so a strategy the year has overtaken is changed at the review rather than reaffirmed by it. The review is planned rather than convened, and what it has to consider is fixed in advance: the status of actions from previous reviews; changes in the external and internal issues that bear on the system; the satisfaction of customers and the feedback of other interested parties; how far the objectives set for the system have been met; how the processes are performing and whether what the organization delivers conforms; the nonconformities raised and the corrective actions taken; the results of monitoring and measurement; audit results; how external providers are performing; whether the resources the system has are adequate; the effectiveness of the actions taken on risks and opportunities; and the opportunities for improvement on the table. An input that is missing on the day is recorded as missing rather than passed over, so the review is answerable for what it did not see as well as for what it decided. Where the organization develops or uses AI, the AI governance program is a standing subject of the same review rather than a separate forum: what the AI systems in scope did, what the risks and impacts recorded against them showed, and what should change - taken with the rest of the agenda by the same leadership, so an AI decision is weighed against the organization’s other commitments instead of beside them. | 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. Each failure is rated for how serious it is and put in front of the people who actually have the authority to fix it, on a timescale set by that rating rather than by the next scheduled meeting - and where the rating warrants it, that includes senior management and the governing body. 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. Open findings are held in one plan of action rather than in the report each came from: a single tracked list carrying every weakness and deficiency the organization has found - from an assessment, an audit, a scan, a test, an incident or a report from outside - with the remediation intended for each, the milestones it will pass and the date it is due, updated as findings are closed and as new ones arrive rather than rebuilt at the next review. | 10.2 | P17 |
| 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 |
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, which is an absence rather than a judgment about that standard.
Also reached by these 5 controls
- AI Governance Essentials also reached
- Amazon Appstore Child-Directed Apps not reached
- Apple App Store Kids Category not reached
- CIS Critical Security Controls not reached
- COPPA also reached
- ESG Essentials also reached
- EU AI Act not reached
- FedRAMP 20x not reached
- FedRAMP Consolidated Rules also reached
- FedRAMP Rev5 Class B also reached
- FedRAMP Rev5 Class C also reached
- FedRAMP Rev5 Class D also reached
- GDPR not reached
- Google Play Families not reached
- HIPAA also reached
- ISO 9001 also reached
- ISO/IEC 27001 also reached
- NIST AI Risk Management Framework not reached
- NIST Cybersecurity Framework also reached
- NIST SP 800-171 also reached
- NIST SP 800-53 also reached
- PCI DSS not reached
- PIPEDA not reached
- SOC 2 also reached
- US Employment Law - Federal Baseline not reached
Nearby pairs
- SOX (Sarbanes-Oxley) Section 404 and SOC 2 27 shared controls
- SOX (Sarbanes-Oxley) Section 404 and ISO/IEC 27001 24 shared controls
- SOX (Sarbanes-Oxley) Section 404 and NIST SP 800-53 21 shared controls
- SOX (Sarbanes-Oxley) Section 404 and FedRAMP Rev5 Class C 20 shared controls
- SOX (Sarbanes-Oxley) Section 404 and FedRAMP Rev5 Class D 20 shared controls
- SOX (Sarbanes-Oxley) Section 404 and NIST Cybersecurity Framework 20 shared controls
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 42001. 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.