In short
- Frameworks overlap heavily at control level even where their language differs
- Normalise requirements first; map controls second — doing it in the other order embeds the duplication
- A mapping is only defensible if it records who approved it and against what version
- Coverage analysis is the deliverable: it shows what is genuinely uncovered
An organisation holding ISO/IEC 27001 wins an enterprise customer that requires SOC 2. A regulator introduces a new resilience expectation. A large client sends a bespoke control questionnaire. Each of these arrives as a separate list of requirements, and the common response is to treat each list as a separate programme — with its own controls, its own evidence collection and its own testing cycle.
The result is an environment where access control is implemented once but documented, tested and evidenced three times, by three people, on three schedules. Effort scales linearly with the number of frameworks. It should not.
Why the duplication happens
Frameworks describe the same underlying control objectives in different vocabulary and at different levels of granularity. One standard states a single requirement covering privileged access; another splits the same ground across four. Because the text does not match, the requirements are treated as distinct — and once separate controls exist, separating the evidence follows naturally.
The second cause is organisational. Frameworks are usually adopted at different times, under different sponsors, with different deadlines. Nobody has an incentive to reopen last year's implementation to merge it into this year's.
The method
1. Normalise requirements before touching controls
Take every framework in scope and decompose it into atomic requirements — a single testable statement each. Record the source framework, clause reference and version alongside each one. Do not attempt any mapping yet. The output is a flat requirement catalog that is deliberately redundant: near-identical requirements from different sources sit next to each other, which is exactly what you want to see.
2. Build the canonical control set from the requirements
Group requirements that can be satisfied by a single operating control. Write the control to satisfy the most demanding requirement in the group — not the average. A control written to the weakest requirement in its group will fail against the strongest, and you will discover that during an audit rather than during design.
Keep the control set smaller than you expect to need. Most organisations arrive at a canonical set substantially smaller than the sum of their framework control lists, because the overlap is genuinely that large.
3. Map, and record the reasoning
Map each control to every requirement it satisfies. A mapping that records only 'control X satisfies requirement Y' is not defensible under audit. It needs to carry who made the decision, when, against which version of the framework, and what the rationale was. When a framework is revised, that record is what lets you determine which mappings need re-examining rather than re-doing all of them.
4. Analyse coverage
The coverage matrix is the point of the whole exercise. It shows, per framework, which requirements have a mapped control and which do not. Unmapped requirements are your real gap list. Controls mapped to nothing are candidates for retirement — they are consuming testing effort without satisfying an obligation.
5. Test once, evidence once
With mapping in place, a single control test satisfies every requirement mapped to that control. This is where the effort reduction actually lands. It also improves quality: one well-designed test performed properly beats three superficial ones performed to meet three separate deadlines.
What good looks like afterwards
- Adopting a new framework is a mapping exercise, not an implementation programme
- A customer questionnaire is answered from the existing control set and its evidence
- Control testing is scheduled once per control, not once per framework
- Gap reporting is a query against the coverage matrix rather than a manual review
- Retiring a framework removes mappings without stripping controls other frameworks still rely on
None of this requires a platform to start — a first pass can be done with a spreadsheet and discipline. It does require a platform to survive, because the maintenance burden is what kills it. That is the specific problem the Unified Control Framework in SecureGRC exists to solve: a canonical control library, a normalised requirement catalog, versioned mappings with retained rationale, and a coverage matrix that stays current as frameworks are adopted and revised.
