One control set, many frameworks: the only way multi-framework compliance scales

Organisations that end up with three compliance programmes did not choose to. Each framework arrived separately, brought its own control list, and was implemented alongside the last. The result is the same work done three times and three sets of evidence that slowly disagree.

The principle

Maintain one internal control set. Map each control to every external requirement it satisfies. Report against each framework from that mapping. The requirement lists stay separate; the thing you operate exists once.

The test of whether you have it: when an auditor asks how you meet a requirement, you point to one control, one owner and one evidence item — and the same control answers the equivalent requirement in three other frameworks.

What it requires in practice

1. A canonical control per objective, written at the strictest level any framework demands. Where one requires quarterly and another annually, the control is quarterly — never an average.
2. A complete crosswalk from every requirement to the control that satisfies it. This mapping is your proof of coverage.
3. Evidence stored once, mapped to every requirement it serves. One access review export answering four frameworks.
4. One owner per control, not one per framework.
5. One recurring schedule. The activity runs at the highest frequency any framework demands, once.

The saving is not in the control count. It is in recurring effort: fewer owners to chase, fewer reviews to run, and evidence gathered once instead of three times, every cycle, forever.

Where the overlap actually is

Across ISO 27001, SOC 2, the NCA ECC, SAMA CSF and PCI DSS, the substance converges on the same domains: identity and access, change management, vulnerability management, logging and monitoring, backup and recovery, incident response, supplier security, HR security and governance.

What differs is wording, prescriptiveness, evidence format and how the result is scored — rarely the underlying practice. That is why mapping works, and why parallel programmes are so wasteful.

What does not map

Be honest about the residue, because pretending it maps is how programmes fail assessments:

• Scoring models. Implementation versus maturity are different questions from the same evidence — score twice, do not average.
• Jurisdiction-specific obligations — residency, reporting clocks, registration, representatives. These are not controls and need their own register.
• Evidence format expectations, including language.
• Genuinely unique requirements, which exist in every framework and are usually few.

Proving you did not lose coverage

Keep the crosswalk as a maintained artefact. When someone asks why your control set is smaller than the sum of the frameworks, the crosswalk answers in one document. Without it, consolidation looks like controls were deleted.

Sequencing a second framework

1. Map the new framework's requirements to your existing controls.
2. Identify requirements that map to nothing — the genuine delta.
3. Close only that delta.
4. Extend evidence mapping to cover the new requirements.
5. Add any jurisdiction-specific obligations to the register.

Done this way, the second framework typically costs a fraction of the first. Done as a fresh programme, it costs nearly the same again.

Key takeaways

• One canonical control per objective, at the strictest frequency required.
• The crosswalk is your proof of coverage — maintain it as an artefact.
• Score implementation and maturity separately; never average them.
• Non-control obligations need their own register.