Map Once, Comply Many: Cross-Mapping Controls Across SOC 2, ISO 27001, and ISO 42001
Roughly two thirds of the work behind SOC 2, ISO 27001, and ISO 42001 is the same work. The trick is knowing which third is not, because that is where programmes fail.
Control cross-mapping means writing one control, implementing it once, and pointing it at the requirements of several frameworks at the same time. Done properly it removes most of the duplication between SOC 2, ISO 27001, and ISO 42001. Done carelessly it produces a mapping table that looks impressive and satisfies nobody, because a requirement was marked covered when it was only approximately covered.
The overlap is real and large. So is the residue.
Where do the three frameworks actually overlap?
At the operational security layer, almost completely. Access control, change management, encryption, logging, vendor management, incident response, business continuity, and awareness training appear in all three, phrased differently.
A single access control, properly implemented and evidenced, can satisfy a SOC 2 common criteria requirement, an ISO 27001 Annex A control, and the operational side of an ISO 42001 management system. You write the procedure once, run the nightly check once, and produce one evidence artefact that three assessors accept.
| Domain | SOC 2 | ISO 27001 | ISO 42001 | Shared? |
|---|---|---|---|---|
| Access control | Common criteria | Annex A controls | Referenced operationally | Yes |
| Change management | Common criteria | Annex A controls | Referenced operationally | Yes |
| Vendor and supplier risk | Common criteria | Annex A controls | Extended to model and data suppliers | Mostly |
| Incident response | Common criteria | Annex A controls | Extended to AI-specific incidents | Mostly |
| Risk assessment | Required | Required, formalised | Required, AI-specific | Partly |
| Management review | Not required as such | Required | Required | No |
| Statement of applicability | Not required | Required | Required | No |
| AI impact assessment | Not required | Not required | Required | No |
| Data and model lifecycle | Not required | Partly | Required, central | No |
The pattern: the further down you go, the less transferable the work becomes. The bottom four rows are where teams underestimate effort by a wide margin.
What is genuinely different, and why it matters
Three differences do real damage when they are glossed over.
ISO wants a management system, not just controls. ISO 27001 and ISO 42001 both require a governing layer around the controls: scope definition, a documented risk methodology, objectives, internal audits, and management review with recorded decisions. SOC 2 has no equivalent. A company with excellent SOC 2 controls can still fail an ISO certification audit for having no management system at all, and this surprises people every year.
ISO 42001 assesses impact on people, not just risk to the organization. Security frameworks ask what could harm the business. ISO 42001 asks additionally what the AI system could do to the individuals it touches: unfair outcomes, unexplained decisions, harm from a wrong answer accepted without review. That is a different analysis with a different output, and it cannot be inherited from a security risk register. Our AI governance tooling treats it as its own assessment for that reason.
Scope statements are not interchangeable. ISO 27001 scope is usually drawn around systems and locations. ISO 42001 scope is drawn around AI systems and their lifecycle. Copying one into the other produces a scope that either covers nothing meaningful or commits you to far more than you intended.
How do you build the mapping without lying to yourself?
Use one honest rule: a control is only mapped to a requirement if the same evidence would satisfy both assessors without modification.
That rule kills most of the optimistic mappings. If satisfying ISO 42001 needs the same access review plus an extra field recording whether the accessed system was an AI system, then the control is not fully mapped; it is mapped with a gap, and the gap needs an owner.
Practical sequence:
- Write controls in your own language, not the framework's. Frameworks change. A control called "quarterly access review with documented removals" survives; a control called "CC6.2" does not.
- Map each control outward to every framework requirement it satisfies, and record the evidence artefact once.
- Mark partial mappings honestly with the delta written out. Partial is fine. Unlabelled partial is what fails an audit.
- List the orphans. Requirements with no control are your actual project plan. In most first ISO 42001 efforts, the orphans are the AI impact assessment, the data lifecycle documentation, and the management review.
- Keep one evidence trail, not three. Three trails drift apart within a year.
Does one certification give you a head start on the next?
Yes, substantially, and the sequence matters.
Teams that already hold SOC 2 typically find ISO 27001 reachable, because the control substance exists and the missing pieces are the management system layer and the statement of applicability. Teams going from ISO 27001 to ISO 42001 have the governance machinery and need the AI-specific content: the system inventory, impact assessments, data lifecycle, and human oversight arrangements.
Going the other direction, ISO 42001 first, is usually a mistake unless AI governance is the only thing your buyers ask about. The security foundation carries more weight in most Canadian procurement conversations today.
For a plain comparison of what each standard is for before you commit, ISO 42001 vs SOC 2 covers the decision itself.
This is general information, not legal advice.
Valdra holds one control set mapped across frameworks, so a single piece of evidence answers to SOC 2, ISO 27001, and ISO 42001 at once, and the orphaned requirements show up as a work list rather than a surprise. The ISO 27001 and SOC 2 readiness views share the same underlying controls.
Frequently asked questions
What is control cross-mapping?+
It is the practice of writing and implementing a control once, then linking it to the requirements of several frameworks it satisfies. One access review can serve SOC 2, ISO 27001, and the operational layer of ISO 42001, producing a single evidence artefact for three assessments.
How much overlap is there between SOC 2 and ISO 27001?+
At the operational security layer the overlap is very high: access control, change management, encryption, logging, vendor risk, incident response, and training appear in both. The gap is the management system layer, which ISO requires and SOC 2 does not.
Can I map ISO 42001 onto my existing security controls?+
Partly. The operational controls transfer well, but ISO 42001 adds requirements that have no security equivalent: an AI impact assessment focused on effects on people, data and model lifecycle documentation, and an AI-specific scope. Those are new work, not mapped work.
When should a control be marked as only partially mapped?+
Whenever the same evidence would not satisfy both assessors without modification. If one framework needs an extra field, a wider population, or a different frequency, the mapping is partial and the difference should be written down with an owner.
Which framework should a Canadian company pursue first?+
Usually SOC 2 or ISO 27001, because security is what most Canadian buyers ask about in procurement. ISO 42001 first makes sense mainly when AI governance is the specific thing your customers or regulators are asking you to demonstrate.
Should controls be named after framework references?+
No. Name them in your own operational language, such as quarterly access review with documented removals. Framework references change between versions, and control sets named after clause numbers become unreadable and need rewriting each cycle.
AI governance and privacy compliance, simplified.
Valdra helps Canadian companies govern AI and meet PIPEDA and Law 25 — hosted in Canada.
Try Valdra
