Appearance
Control overlap across AI governance frameworks
Most organizations do not adopt one governance framework. They adopt several, in sequence, as regulations land and customers ask for certifications. The practical question is never "which framework is best" but "how much of this next one do we already have".
This page answers that question with the actual numbers from the Modulos framework library.
Reuse happens at the Control layer
Modulos models every framework the same way. A framework template contains Requirements, the specific obligations drawn from the source regulation or standard. Each Requirement links the Controls that satisfy it, and Controls come from one shared library that spans all frameworks.
Two properties of that library decide everything on this page:
- No Requirement is ever shared between frameworks. Article 11 of the EU AI Act and clause 7.5 of ISO/IEC 42001 are different obligations with different wording, and they stay separate objects.
- Controls are shared freely. A single Control such as
MCF-53Technical Documentation is linked by Requirements in many different frameworks.
So overlap is not an approximation or a mapping exercise. Two frameworks overlap by exactly the Controls their Requirements have in common, and the figures below are set intersections over Control identifiers rather than judgment calls about similar-sounding clauses.
Frameworks in Modulos covers how this behaves in a project once you apply a second framework.
Explore the overlap
Loading Control overlap data…
Reading the matrix
Coverage is directional, and this is the part that is easy to get wrong. The share of framework B that framework A covers is not the share of A that B covers, because the two frameworks have different numbers of Controls. Implementing the EU AI Act puts most of NIST AI RMF in place, while implementing NIST AI RMF puts a much smaller fraction of the EU AI Act in place. Each cell reads row first, then column.
Switching the matrix to shared counts makes the grid symmetric, since the number of Controls two frameworks have in common is the same in both directions. The asymmetry lives entirely in what you divide that number by.
Key figures
AI application scope
Implementing all 23 frameworks separately would mean 1,206 Control implementations. On Modulos they resolve to 584 distinct Controls, a reduction of 52%. 296 of those 584 Controls satisfy Requirements in two or more frameworks.
Framework pairs sharing the most Controls:
| Frameworks | Shared Controls | Share of the first | Share of the second |
|---|---|---|---|
| ISO 27001 and NIS2 | 62 | 65% | 87% |
| OWASP - Top 10 for LLM Applications and OWASP - Top 10 for Agentic Applications | 56 | 66% | 85% |
| EU AI Act and NIST AI RMF | 54 | 48% | 89% |
| ISO 27001 and DORA | 44 | 46% | 81% |
| NIS2 and DORA | 40 | 56% | 74% |
| ISO 27001 and Cyber Resilience Act | 37 | 39% | 52% |
| EU AI Act and MAS FEAT | 35 | 31% | 92% |
| NIS2 and Cyber Resilience Act | 34 | 48% | 48% |
Controls serving the most frameworks:
| Control | Title | Frameworks served |
|---|---|---|
MCF-23 | Risk Management at Inception | 9 |
MCF-53 | Technical Documentation | 9 |
MCF-67 | Production Data Drift Monitoring | 9 |
MCF-65 | Deployed AI System Performance Monitoring | 8 |
MCF-76 | Risk Management in Operation | 8 |
MCF-55 | Testing Procedures | 7 |
MCF-58 | Model Fairness Testing | 7 |
MCF-61 | Deployment Acceptance | 7 |
MCF-68 | Deployed AI System Fairness Monitoring | 7 |
MCF-81 | Risk Management at Re-evaluation | 7 |
Organization scope
Implementing all 20 frameworks separately would mean 769 Control implementations. On Modulos they resolve to 346 distinct Controls, a reduction of 55%. 153 of those 346 Controls satisfy Requirements in two or more frameworks.
Framework pairs sharing the most Controls:
| Frameworks | Shared Controls | Share of the first | Share of the second |
|---|---|---|---|
| ISO 27001 and ISO 27701 | 66 | 96% | 84% |
| ISO 27001 and ISO 42001 | 57 | 83% | 64% |
| ISO 42001 and ISO 27701 | 57 | 64% | 72% |
| ISO 27001 and NIS2 | 52 | 75% | 64% |
| ISO 27001 and DORA | 52 | 75% | 60% |
| ISO 27701 and NIS2 | 52 | 66% | 64% |
| ISO 27701 and DORA | 51 | 65% | 59% |
| ISO 42001 and NIS2 | 48 | 54% | 59% |
Controls serving the most frameworks:
| Control | Title | Frameworks served |
|---|---|---|
OCF-1 | Governance Structure | 10 |
OCF-44 | AI Literacy and Awareness | 8 |
OCF-52 | Risk Management System | 8 |
OCF-95 | Risk criteria establishment | 8 |
OCF-97 | Risk assessment process | 8 |
OCF-123 | Document availability and suitability | 8 |
OCF-131 | External provider control | 8 |
OCF-47 | Documentation Keeping | 7 |
OCF-98 | Risk treatment process | 7 |
OCF-109 | Competence determination | 7 |
What these numbers do and do not mean
- They count Controls, not effort. Controls differ widely in cost. A shared Control still needs Evidence gathered in your own context, and a framework whose Controls are already in place is faster to reach, not free.
- A shared Control is not an automatically satisfied Requirement. Reuse means the Control already exists in your program with an owner and Evidence attached. The receiving framework's Requirement still has to be reviewed and marked fulfilled on its own terms.
- Overlap reflects how the library is authored. Where a framework was built on the shared lifecycle Controls it overlaps heavily with its neighbours. Where it was given a dedicated Control block it does not. Application-scope ISO/IEC 42001 is the clearest example: its Controls sit in their own block, so it shows little overlap with frameworks it is conceptually close to. Organization-scope ISO/IEC 42001 behaves the way you would expect.
Keeping this page current
The figures come from the Modulos platform content pack and are regenerated whenever the platform ships a new pack. The content-pack version and the date the figures were generated appear under the matrix, so it is always clear how current the numbers are.