One control library, seven frameworks: how the cross-mapping actually works

An organisation holding ISO 27001, SOC 2 and PCI DSS, and subject to DPDPA, is typically evidencing user access review four times a year in four formats for four audiences. Same control. Same underlying activity. Four separate evidence packages, four sets of questions, four teams pulled off delivery.

That duplication is entirely avoidable, and removing it is usually the highest-return piece of governance work available to a multi-framework organisation.

The unit of the library is the control, not the requirement#

The mistake that undermines most attempts at this is building the library around framework requirements. You end up with an ISO section, a SOC 2 section and a PCI section, each containing near-identical entries, and the duplication has been documented rather than removed.

The library's unit must be the thing your organisation does. One entry per control, with framework requirements as attributes of that entry.

An entry looks like this:

id: IAM-07
title: Periodic access certification
statement: >
  Access rights to in-scope systems are reviewed by the system owner at least
  quarterly. Entitlements that are no longer required are revoked within five
  working days of the review. Reviews and revocations are recorded.
owner: Head of IT Operations
frequency: Quarterly
evidence:
  - Access review export per system, signed by owner
  - Revocation tickets with timestamps
  - Exception register for accepted retentions
automation: Identity provider API — entitlement snapshot and diff
mappings:
  iso-27001: [A.5.18, A.8.2, A.8.3]
  iso-27701: [A.7.2.1]
  soc2: [CC6.1, CC6.2, CC6.3]
  pci-dss: ['7.2.4', '8.2.6']
  nist-csf: [PR.AA-05, GV.RR-02]
  dpdpa: [Sec 8(4) reasonable security safeguards]
  iso-42001: [A.4.2]

One control. One owner. One frequency. One evidence set. Six frameworks satisfied.

What makes the mapping honest#

Cross-mapping is easy to do badly. Two disciplines keep it defensible.

Map at the level of intent, and record where coverage is partial. A control can fully satisfy one framework's requirement and only partially satisfy another's. Recording that distinction is what lets you find the genuine gaps rather than assuming a mapped control means a satisfied requirement.

We use three coverage states: full, partial, and contributes. A partial mapping carries a note describing what else is needed.

Do not map to the strictest interpretation and assume the rest follow. PCI DSS requires access review at least once every six months for some requirements; ISO expects it at planned intervals; SOC 2 depends on your own stated commitments. Setting quarterly satisfies all three — but the control statement must say quarterly, and the evidence must show quarterly, or the strongest claim fails.

Where the savings actually come from#

Three places, in descending order of value.

Evidence collection. One artefact serving several frameworks is the largest single saving. The access review export that satisfies ISO A.5.18 satisfies SOC 2 CC6.2 without modification, provided your repository is indexed by control rather than by audit.

Assessment. A single gap assessment against the unified library reports your position against every framework simultaneously — designed to replace three or four separate framework assessments with one.

Audit fieldwork. With a mapped library and a control-indexed repository, an auditor's prepared-by-client list is a lookup rather than a scavenger hunt. This is where engineering time is recovered.

The saving is not linear. The first framework costs what it costs. Each additional one draws on controls the library already evidences, so the marginal work shrinks to whatever is genuinely framework-specific.

The framework-specific residue#

Cross-mapping does not eliminate everything, and claiming it does is how organisations get caught.

Genuinely framework-specific work that no amount of mapping removes:

• ISO 27001 — the management system clauses. Context, leadership, planning, internal audit, management review. These are not controls and do not map to SOC 2 or PCI at all.
• SOC 2 — the system description. A narrative document with no equivalent elsewhere, and one auditors scrutinise closely.
• PCI DSS — cardholder data flow diagrams, segmentation testing and ASV scanning. Highly specific and not reusable.
• DPDPA — multilingual notice delivery and verifiable parental consent. No international framework has an equivalent obligation.
• ISO 42001 — AI impact assessment and lifecycle controls. Overlaps ISO 27001's structure but its content is distinct.

Budget for this residue explicitly. It is typically 20–30% of a framework's effort, and pretending otherwise is what turns an accurate savings estimate into an overrun.

Implementation sequence#

A note on platforms#

Compliance automation platforms ship with their own control libraries and mappings. These are a reasonable starting point and a poor finishing point, because they describe a generic organisation rather than yours.

The failure we see most often: a platform's generic control says something the organisation does not actually do, the team cannot evidence it, and rather than adapting the control they either fake the evidence or disengage from the platform. Both outcomes are worse than a spreadsheet.

Adapt the library to how your organisation genuinely operates, then load it. The platform should reflect your control environment, not define it.

Keeping it current when frameworks move#

A library built once and never revised becomes a liability within about two years. ISO 27001 restructured Annex A in 2022. PCI DSS v4.0 introduced future-dated requirements that became mandatory in 2025. DPDP Rules are still being notified in stages. ISO 42001 did not exist three years ago.

Three mechanisms keep a library alive without turning maintenance into a programme of its own.

A named owner and a review cadence. Quarterly is enough. The review asks three questions: has any mapped framework published a revision, has any control's owner or frequency changed, and has any new obligation arrived that the library does not cover. Fifteen minutes per framework, four times a year.

Version the library, not just the documents. When a framework revision lands, you need to know which controls were affected and which evidence was collected under the old mapping. A library with a version number and a changelog answers an auditor's "when did this control change?" question. One without it does not.

Treat a new framework as an extension, never a fork. The temptation when adding, say, ISO 42001 is to build a separate AI control set because the domain feels different. Resist it. Map the new requirements onto existing controls where they genuinely overlap — access control and change management are the same controls whether the asset is a database or a model — and add only what is genuinely new.

What the library is worth in an acquisition#

An underrated benefit, and one that lands with CFOs when the compliance argument does not.

In a technology acquisition, the buyer's diligence team asks what certifications the target holds, what the control environment looks like, and how much work integration will require. An organisation that can hand over a versioned, cross-mapped control library with evidence indexed against it answers all three in a single artefact.

The alternative — four framework-shaped folders with overlapping, differently-worded controls and evidence organised by audit — reads as a control environment that exists to pass audits rather than to manage risk. That distinction affects diligence findings, and diligence findings affect price.

A well-maintained library is capable of shortening a technology diligence phase by weeks. That is not why you build one, but it is worth knowing when you are arguing for the budget, because it converts a compliance cost into an asset with a realisable value at exit.

The same argument applies in reverse when you are the acquirer. A target that hands over a coherent control library is telling you something about how the organisation is run, well beyond the security function.

Our Digital Trust Governance practice builds these libraries, and the assessment workbook — 218 unified control statements cross-mapped across six frameworks — is published as our Multi-Framework Gap Assessment Workbook.