Control mapping: how to map one control set across several frameworks

You hold ISO 27001. Now an enterprise prospect wants a SOC 2 report, the board is asking about ISO 42001, and the team has started a fresh spreadsheet for each one. Three frameworks become three projects, three evidence requests and three sets of owners chasing the same screenshots. Control mapping stops that.

Control mapping links each framework requirement to the internal controls that meet it, so one control and one piece of evidence can count towards several frameworks. This guide is for the head of security or GRC lead at a UK B2B tech firm adding a second or third framework. It covers the many-to-many model, the relationship types an auditor will ask about, a seven-step method, a worked example, whether to build or license a map, and how to keep it current.

What is control mapping?

Control mapping is the record of which of your internal controls meet which framework requirements, and how fully. You map from each requirement to your own controls, record how completely each control covers each requirement, and update the map when a framework changes. Done well, one control and one set of evidence serve several frameworks at once.

The relationship is many-to-many. One control, such as a quarterly access review, can count towards a requirement in ISO 27001, SOC 2 and Cyber Essentials. One requirement, such as managing access rights, usually needs several controls working together: joiner and leaver steps, approval of new access, and the periodic review.

That shape is why a two-column list breaks. A control mapping is a table of pairs, with one row for each requirement and control that relate, plus a note on how strong the link is. For the frameworks themselves, start with our ISO 27001 overview and our NIST Cybersecurity Framework entry.

Why map requirements to your controls, not framework to framework?

Map every framework to your own control set because your controls are what an auditor actually tests. A framework-to-framework crosswalk tells you two documents talk about similar things. It does not tell you what your firm does, who owns it, or where the evidence lives. Your controls sit in the middle, and every framework points at them.

Mapping framework to framework also multiplies the work. With three frameworks you need three pairwise maps, and a fourth framework brings three more. Mapped to a single control set, each new framework is one more map against controls you already run.

A crosswalk between two standards describes the standards. A control mapping describes your business.

What relationship types should a control mapping record?

A control mapping should record how much of each requirement a control covers, not just that the two are related. NIST's set theory style offers five relationship types: equal, subset of, superset of, intersects with, and no relationship. Each pairing also states a rationale, so a reviewer can see why the link was made and test it.

NIST IR 8477, NIST's February 2024 guidance on mapping standards, regulations and frameworks, defines those five types. It also defines a looser "concept crosswalk" style, which only says two concepts are related and says nothing about how. A spreadsheet of ticks works the same way, and gives an auditor the least to test.

The table below puts the five set theory types in plain terms, with the question each one answers for an auditor.

NIST IR 8477 pairs each relationship with one of three rationales: syntactic (how similar the wording is), semantic (how similar the meaning is) or functional (how similar the results are when both are carried out). For control mapping, functional is usually the right lens, because an auditor cares what your control achieves, not how its description reads.

Relationship types matter at audit because they turn a link into a claim someone can check. "Subset of, functional: covers the periodic review only; joiner and leaver steps are in AC-02" tells an auditor exactly where to look. A bare tick tells them nothing.

How do you build a control mapping, step by step?

Build a control mapping in seven steps: set the use case and scope, list requirements at a useful level of detail, write your controls once in your own words, pair each requirement with controls using a relationship and rationale, attach evidence to controls, close the gaps the map exposes, and have control owners review it.

Step 1: Set the use case and scope

Write one sentence saying who will use the map and why. For example: "The GRC lead and our auditors need to see which of our controls meet ISO 27001 and SOC 2 Security, so that evidence is collected once." NIST IR 8477 recommends documenting the intended users, the purpose, the types of concepts being mapped, the direction and how exhaustive the mapping will be.

Name the frameworks, editions and scope boundaries in that sentence. Scope creep in a control mapping is as expensive as scope creep in an audit.

Step 2: List requirements at the right level of detail

List each framework's requirements as rows, carrying only the identifier and short title, never the full text. Pick a level of detail you can sustain. NIST IR 8477 warns that mapping at the lowest level is not always practical: "Just because you can map at the lowest level does not mean you should."

For most lean firms, the useful level is the one the auditor tests: the Annex A control, the SOC 2 criterion, the Cyber Essentials requirement area.

Step 3: Write your controls once, in your own words

Write each internal control as a short statement of what your firm does, who owns it, how often it runs and what evidence it leaves. Give each one a stable ID of your own, such as AC-03. These statements are yours, so they can be shared, versioned and changed without touching anyone's copyright.

Running and governing that control set as a living system is a bigger subject than mapping. Here the aim is a list stable enough to map against.

Step 4: Pair each requirement with controls

Work through the requirement list. For each requirement, name every control that contributes, the relationship type and a one-line rationale. Mark any requirement with no control as a gap rather than leaving it blank. Blank rows are where audit findings hide.

Step 5: Attach evidence to controls, not requirements

Record the evidence against each control: the review record, the ticket, the system export. Because requirements point at controls, every framework that maps to a control inherits its evidence.

Step 6: Close the gaps the map exposes

Sort the map by relationship. "Intersects with" and "subset of" rows, where no other control covers the remainder, are your remediation list. Fix them by extending an existing control where you can, and add a new control only when the work is genuinely different.

Step 7: Review with control owners and freeze a version

Ask each control owner to confirm the controls and rationales they own, then save a dated version of the map. Auditors and customers will ask what the map looked like at a point in time, and a dated version answers that in one file.

What does a worked control mapping example look like?

A single quarterly access review shows how control mapping works in practice. One control, written once, links to requirements in four frameworks with different relationships. Two links are partial, so the map points straight at the other controls you need. The example uses identifiers and short titles only, and every judgement in it is ours.

The control, in our own words: AC-03 Quarterly access review. Every quarter, each system owner reviews who has access to their in-scope systems, confirms each account is still needed at its current level, and raises tickets to remove or reduce anything that is not. The security lead checks that every review was completed and every ticket closed. Evidence: the signed review record and the closed tickets.

Each summary in the table is our own paraphrase, and no relationship or rationale is taken from a published crosswalk.

The map shows two things a spreadsheet of ticks would hide. First, AC-03 never meets any of these requirements alone, so an auditor will expect to see the companion controls named. Second, the same review record is evidence for all four rows, so the review is run, signed and stored once.

The detail behind ISO 27001's access rights control is on our A.5.18 access rights page. For the SOC 2 side, see our guide to the Trust Services Criteria. The full pairing of those two frameworks is a bigger job than one control and deserves its own page.

Should you build your own control mapping or license one?

Build your own control mapping when your scope is two or three frameworks and you want a map you can share freely. License or reuse a published map when you need many frameworks quickly, and read its licence first. Either way, the map an auditor tests is the one pointing at your controls.

There are three main sources to start from:

1. NIST's Online Informative References (OLIR). The NIST OLIR programme publishes mappings between NIST documents, such as the Cybersecurity Framework and SP 800-53, and other standards. NIST's announcement of CSF 2.0 describes a searchable catalogue of informative references covering more than 50 other cybersecurity documents.
2. The Secure Controls Framework (SCF). A large meta-framework with mappings to many standards. Its terms of use apply the Creative Commons Attribution-NoDerivatives 4.0 licence: you may use it with credit, but you may not distribute modified versions. The terms say this includes derivatives made with AI, and that offering derivative SCF content requires a commercial licence.
3. The standards themselves. ISO makes its standards available under a paid licence that restricts copying, so we recommend that any map you share outside your firm carries only clause numbers and short titles, never the requirement text.

The licence question is practical, not academic. If your customer-facing trust centre or tender response publishes a modified copy of a no-derivatives crosswalk, you may be breaching the licence. A map built on your own control statements, with requirement IDs and titles only, avoids the problem.

A free crosswalk saves time on day one. It cannot tell you which of your controls is missing.

How do you keep a control mapping current when a framework changes?

Keep a control mapping current by recording the edition of every requirement, watching each framework for new releases, and re-mapping only the requirements that changed. When a new edition lands, map old requirements to new ones first, then carry each control link across or flag it for review.

Framework changes are not rare. IAF MD 26, the transition rules issued by the International Accreditation Forum (whose work passed to the Global Accreditation Cooperation in 2026), records that the information security controls fell from 114 in 14 clauses to 93 in 4: 11 new, 24 merged from existing controls and 58 updated. Certified firms had to complete the transition by 31 October 2025.

The NIST Cybersecurity Framework moved too. NIST released CSF 2.0 on 26 February 2024 and added a sixth function, Govern, according to NIST's release announcement.

A practical maintenance routine:

1. Tag every requirement row with its framework edition.
2. Assign one owner per framework to watch for new editions, regulator guidance and certification body notices.
3. When an edition changes, map old requirement IDs to new ones, then re-test only the control links that touch changed requirements. NIST IR 8477 notes that set theory mapping suits exactly this: comparing a new version of a standard with the previous one.
4. Review the whole map at least once a year, and again whenever you add or retire a control.

How does control mapping feed evidence reuse and audits?

Control mapping lets you collect evidence once against each control and present it to every framework that maps to that control. Before an audit, filter the map by framework to produce that auditor's view: requirement, controls, relationship, rationale and evidence location. Gaps and partial coverage show up before fieldwork, not during it.

The same map answers customer questionnaires. When a security questionnaire asks about access reviews, the answer, the owner and the evidence already sit against AC-03, whichever framework the customer names.

The map also changes the shape of the compliance year. Instead of one evidence scramble for each certification, controls run on their own cadence and leave evidence as they go. Each audit then becomes a filtered view of work already done. That is where compliance starts to look like an engineered system rather than an annual project.

What are the most common control mapping mistakes?

The most common control mapping mistakes are mapping one framework straight to another instead of to your own controls, recording links without a relationship type or rationale, and assuming every requirement pairs one-to-one with a control. Each makes coverage look more complete than it is, and each surfaces at audit as a finding.

Watch for these in particular:

1. Mapping framework to framework. A crosswalk between two standards says nothing about what you do. Map each framework to your controls instead.
2. No relationship, no rationale. A tick in a cell cannot be tested. Record the type and one line of reasoning.
3. Assuming one-to-one. Most requirements need several controls, and most controls serve several requirements.
4. Copying a licensed crosswalk into a published document. Check the licence before anything leaves the building.
5. Freezing the map. A map with no edition tags quietly goes stale after the next revision.

Get these right and the map stops being a spreadsheet you rebuild for each audit. It becomes the index to a control set that proves several frameworks at once.

Frequently asked questions