What is control mapping?

Control mapping is the practice of linking a security control, or a requirement in one framework, to the related requirements in other frameworks. It lets an organisation do the work once and show how that work answers several expectations, such as ISO/IEC 27001, SOC 2, the NIST Cybersecurity Framework and a national standard.

A mapping is a statement of relationship, and it is rarely a statement of equivalence. Two requirements can overlap heavily, overlap partly, or sit at very different levels of detail. Treating a partial overlap as a full match is the most common source of audit surprises.

What NIST says about mappings

NIST’s Cybersecurity Framework 2.0 uses the term “Informative References” for this. It describes them as mappings that indicate relationships between the Core and various standards, guidelines, regulations and other content, which help inform how an organisation may achieve the Core’s outcomes. The framework also points out that some references are narrower than a Subcategory: a particular control from NIST SP 800-53 may be one of many references needed to achieve a single outcome. Other references are higher level, such as a policy requirement that partly addresses several Subcategories.

NIST also runs the National Online Informative References (OLIR) Program. Its report, NISTIR 8278 Rev. 1, defines an Online Informative Reference as a standardised expression of the relationships between concepts from standards, guidelines and regulations, and says the programme encourages and facilitates defining them. The OLIR programme page describes a catalogue of reference data and a tool for generating derived relationship mappings against a focal document.

Mappings also appear in national standards. The Saudi NCA says its Essential Cybersecurity Controls are linked to relevant national and international legislative and regulatory requirements.

Why it matters

Most clients face more than one expectation. A software supplier may need SOC 2 for customers, ISO/IEC 27001 for European tenders, and a regional baseline for a particular market. Without mapping, each one becomes a separate project with its own spreadsheet, its own evidence requests and its own owners.

With mapping, the organisation keeps one set of controls and one body of evidence. When a new framework appears, the question becomes “what is new?” instead of “where do we start?”. Our guide to the multi-framework compliance playbook shows how that plays out for a service line.

How an MSP or vCISO delivers it

1. Pick one primary framework. Choose the one that most closely matches the client’s strongest requirement, and treat the others as mapped views.
2. Build a control library. Write each control once, in plain language, with a single owner.
3. Map using a published source where one exists. Use an official or well-documented mapping, and record its name, version and date. If you build your own mapping, say so.
4. Record the strength of each relationship. A simple scale, such as full, partial or related, avoids overstating coverage.
5. Attach evidence once. One piece of evidence, such as an access review, can support several requirements.
6. Check partial matches by hand. Where a mapping is partial, add a note about what additional evidence the second framework asks for.
7. Revisit when frameworks change. Versions are updated, and a mapping that was correct for the old version may not be for the new one.

For readiness work against a single framework, see the gap assessment guide. To see the frameworks GetCybr supports, visit the frameworks page.

Common mistakes

• Assuming mapped means compliant. Satisfying one framework’s requirement does not by itself satisfy another’s. Check the detail.
• Using an undated mapping. Frameworks are revised. Record the version of both ends.
• Copying a mapping from a vendor or a blog without checking. Prefer official mappings or ones you have reviewed.
• Mapping at the wrong level. A mapping from a high-level principle to a single technical control hides detail.
• Forgetting regional or legal scope. Some frameworks apply only to certain entities, as with the Saudi NCA controls. A mapping does not change who must comply.
• Letting the mapping go stale. Assign an owner to review it when a framework version changes.

Where GetCybr fits

If you deliver several frameworks to several clients, GetCybr is a platform for holding a shared control library, the mappings between frameworks and the evidence attached to each control, so that one piece of work can be shown against more than one framework. It does not decide whether a partial match is enough for an auditor; that stays with your team and the client’s assessor. You can browse the supported frameworks on the frameworks page.

Sources

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, February 2024. The CSF page lists Informative References as mappings and links to the full document (NIST CSWP 29), which is the source for the description of Informative References.
• NIST Computer Security Resource Center, National Online Informative References (OLIR) Program. Source for the programme description, the reference catalogue and the derived relationship mapping tool.
• NIST Computer Security Resource Center, NISTIR 8278 Rev. 1, National Online Informative References Program: Overview and Uses. Source for the definition of an Online Informative Reference.
• National Cybersecurity Authority (Saudi Arabia), Essential Cybersecurity Controls (ECC). The linked ECC-2:2024 document is the source for the statement that the controls are linked to national and international requirements.