Control rationalisation: you have 400 controls and need 120

Nobody designs a bloated control set. It accumulates. You certify to one framework, add a second, take on a regulator, win a customer with its own schedule — and each arrives with its own control list, implemented alongside rather than merged into what exists. Three years later you have several hundred controls, many saying nearly the same thing, each with an owner, a review cycle and an evidence requirement.

What the bloat costs

• Evidence collected several times for what is substantively one control.
• Owners disengage when asked to attest to near-identical statements repeatedly.
• Reviews slip, because the volume is unmaintainable.
• Inconsistent answers — the same question answered differently in two places, which auditors and customers notice.
• Coverage becomes unclear. With 400 controls nobody can say what is genuinely protected.

The target: one control set, many mappings

The principle is simple and rarely applied: maintain one internal control, mapped to every external requirement it satisfies. The requirement lists stay separate — you still report against ISO, SOC 2, the ECC or PCI as needed — but the thing you actually operate exists once.

The test of a rationalised set: when an auditor asks how you meet a requirement, you point at one control, one owner and one piece of evidence — and that same control answers the equivalent requirement in three other frameworks.

How to do it

1. Inventory every control you currently claim, from every source, in one list.
2. Group by control objective, not by wording. "Review user access quarterly" and "Perform periodic entitlement recertification" are the same control.
3. Write one canonical control per group, at the strictest level any framework demands. If one requires quarterly and another annually, the canonical control is quarterly.
4. Map every source requirement to the canonical control. This mapping is your proof of coverage, so it must be complete.
5. Check for orphans — requirements that map to nothing are genuine gaps you have just discovered.
6. Assign one owner per canonical control.
7. Retire the duplicates, keeping the mapping so you can always explain what happened to them.

Where it goes wrong

• Merging at the wrong level. Collapsing "access review" and "privileged access review" into one control loses a distinction auditors test separately.
• Averaging down. Two frameworks with different frequencies must resolve to the stricter one, not a compromise.
• Losing the mapping. Without it you cannot prove coverage, and the exercise reads as controls being deleted.
• Doing it during an audit window. Rationalise between cycles, not while an assessor is looking at a control set that is mid-change.

Proving you did not lose coverage

This is the part that makes it defensible. Keep a documented crosswalk showing, for every requirement in every framework, which canonical control satisfies it. Produce a before-and-after count and a written rationale. An auditor seeing a control set drop from 400 to 120 will ask what was lost; the crosswalk answers in one document.

Realistic outcome

Organisations running three or four frameworks typically collapse to somewhere between a quarter and a half of their original count, because the overlap between frameworks is genuinely large. The saving is not in the count itself but in the recurring effort: fewer owners to chase, fewer reviews, and evidence gathered once.

Key takeaways

• One canonical control, mapped to many requirements.
• Resolve differing frequencies to the strictest, never an average.
• The crosswalk is your proof of coverage — never discard it.
• Rationalise between audit cycles, and before adding another framework.