Map Once, Satisfy Many: How Control Mapping Actually Works

The duplication problem

Ask a compliance lead how many controls they maintain and the honest answer is usually "it depends who is asking". There is an ISO 27001 set for the certification body, a NIST CSF view for the board, a regulator-specific set for the supervisory submission, and often a fourth internal set that predates all of them.

In practice these sets overlap heavily. Access review, encryption in transit, supplier due diligence, incident response testing: the same operational activity appears in every framework, described in slightly different language, evidenced separately, and reviewed on four different calendars.

The cost is not the mapping work itself. The cost is that the same control drifts into four different states of truth, and nobody can say with confidence which one reflects what the organisation actually does.

What "map once, satisfy many" means concretely

The idea is straightforward: maintain one internal control library that describes what your organisation actually does, then map each framework requirement onto those controls.

The direction matters. Teams that get this wrong start from the framework and generate controls from it, which produces a control set per framework, exactly the outcome they were trying to avoid. Teams that get it right start from the operating reality and treat frameworks as views onto it.

A worked example. Your organisation runs quarterly privileged access reviews. That is one control. It has one owner, one procedure, one evidence trail, one review cadence. Mapped outward, that same control contributes to:

• ISO/IEC 27001 Annex A access control requirements
• NIST CSF under Protect (Identity Management and Access Control)
• Your sector regulator's access governance domain
• Your internal audit's own testing programme

Four obligations, one activity, one set of evidence. When the review runs, all four are satisfied simultaneously and the evidence is collected once.

The four relationship types you actually need

Mapping is not a simple one-to-one lookup. A control library that only supports "control X satisfies requirement Y" will misrepresent reality within a month. You need at least four relationship types:

Full satisfaction. The control fully meets the requirement. The clean case, and less common than people expect.

Partial satisfaction. The control addresses part of the requirement; other controls cover the rest. This is the majority of real mappings. A framework requirement about "secure development" is rarely satisfied by one control.

Supporting. The control does not satisfy the requirement but is relied on by something that does. Asset inventory rarely satisfies a requirement directly, yet a dozen other controls become unverifiable without it.

Gap. The requirement is not met by anything today. Explicitly modelling gaps is what turns a control library into a remediation plan instead of a filing cabinet.

If your tooling collapses these into a single "mapped / not mapped" flag, your coverage reporting is telling you something more optimistic than the truth.

Where the approach breaks down

Control mapping is genuinely useful, and it is oversold. Three honest limitations:

Evidence is not always transferable. Two frameworks may require the same control but demand different evidence: one accepts a system-generated report, the other requires an attestation signed by the control owner. Mapping the control does not map the evidence. Good tooling tracks evidence requirements separately from control mappings.

Assessment depth differs. A requirement satisfied at "documented" maturity for one framework may need "measured and improved" for another. A binary mapping hides this. Maturity has to be assessed per framework, against the same control.

Regulators do not accept your mapping as authoritative. The mapping is your internal reasoning about why a control satisfies an obligation. A supervisor is entitled to disagree. Treat mappings as a defensible argument you can show your working for, not as a settled fact.

Getting the control library right

A few properties separate libraries that hold up from ones that quietly rot:

1. Controls describe activities, not intentions. "Access is reviewed quarterly by the system owner" is testable. "Appropriate access governance is maintained" is not.

2. Every control has exactly one accountable owner. Shared ownership means no ownership by the second audit cycle.

3. Granularity is consistent. Mixing "encrypt all data at rest" with "rotate TLS certificates on the payment gateway" in the same library makes coverage percentages meaningless.

4. Controls outlive frameworks. When a regulator issues a new version, you remap requirements onto existing controls. You do not rebuild the library. If a framework update forces a library rebuild, the library was really a framework checklist wearing a disguise.

What to do first

If you are consolidating from framework-specific control sets, resist the urge to start with the mapping. Start by writing down what your organisation actually does: the real activities, real owners, real cadences, without looking at any framework. It will be uncomfortable, and shorter than you expect.

Then map the frameworks onto it. The gaps that appear in that exercise are the honest ones, and they are considerably more useful than a coverage percentage derived from four overlapping checklists.

---

Sentinel Unity models jurisdictions, authorities, domains, and controls as first-class objects, so a single control library can carry mappings to every framework you answer to, including regulators specific to your market. See how the control engine works.