Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

02.04 Mapping Controls Across Frameworks

Cross-framework control mapping is what stops a multi-framework program from doing the same control test work three times. Here's why mapping matters, how SimpleRisk represents it, and when to use the productized SCF/UCF Extras versus building mappings by hand.

Why this matters

Most working compliance programs run more than one framework. A SaaS company may run NIST CSF as the spine, ISO 27001 as a certification target, and SOC 2 as the report customers ask for. A federal contractor may run NIST RMF and 800-53 alongside FedRAMP. A healthcare organization may run HIPAA and SOC 2 and the CIS Critical Controls. The exact combination varies, but the count is rarely one.

Here's the thing: those frameworks overlap heavily. An access-control requirement appears in ISO 27001 (A.5.15), NIST CSF (PR.AA-1), NIST SP 800-53 (AC-2), SOC 2 (CC6.1, CC6.2), and PCI DSS (Requirement 7), all saying basically the same thing. Without cross-framework mapping, the program tests "access control" five separate times (once for each framework) and produces five separate evidence trails for what's structurally one piece of work. The bookkeeping is the bottleneck, and the bottleneck only gets worse as frameworks get added.

Cross-framework mapping fixes this. When you map a SimpleRisk control to its peers in other frameworks, one piece of test work generates evidence for every framework the control is mapped to. The compliance posture rolls up across frameworks; the dashboards report against multiple frameworks from the same underlying data; the audit conversation for a second framework benefits from the test work the program already did for the first. The payoff is large enough that the tooling for cross-framework mapping is one of the load-bearing parts of any multi-framework program.

The other reason mapping matters: it's how SimpleRisk's reporting answers the question "what's our compliance posture across all our frameworks." Without mapping, the dashboards can answer "what's our ISO 27001 posture" and "what's our SOC 2 posture" separately, but they can't tell you the overlap is 80% and the actual coverage gaps are concentrated in the 20%. With mapping, the unified view lets the program prioritize the work that has the highest cross-framework payoff.

How frameworks describe this

The major frameworks each acknowledge the cross-mapping problem and address it in different ways:

  • NIST Cybersecurity Framework (CSF) v2.0 publishes "informative references" — explicit mappings from each CSF subcategory to controls in NIST SP 800-53, ISO 27001, COBIT, ISA 62443, and others. The mappings are reference material, not a productized tool, but they're the closest thing to an authoritative cross-walk between the major frameworks.
  • NIST Risk Management Framework (RMF) assumes 800-53 as its control catalog and doesn't ship explicit cross-mappings; the implicit mapping is "everything is 800-53." The challenge for an RMF program comes when it also has to satisfy a non-NIST framework; that's where cross-mapping work has to happen.
  • ISO/IEC 27001 Annex A is its own catalog; ISO doesn't publish mappings to other frameworks. Cross-mapping ISO controls to peers in NIST or SOC 2 is left to the implementing organization (or to a meta-framework like the SCF or UCF that does the mapping work commercially).
  • SOC 2 Trust Services Criteria are deliberately abstract to support different organizational implementations. The auditor maps the abstract criteria to the organization's specific control implementations during the audit; the SimpleRisk-side mapping is between TSC criteria and other frameworks the program runs.
  • Secure Controls Framework (SCF) and Unified Compliance Framework (UCF) are meta-frameworks built around cross-framework mapping. Both ship pre-built mappings between hundreds of frameworks, with the SCF organized around control objectives and the UCF organized around regulatory citations. Both are productized in SimpleRisk as Extras (see below).

The mappings are imperfect by definition. NIST 800-53's AC-2 and ISO 27001's A.5.15 cover overlapping but not identical ground; a perfect mapping doesn't exist because the frameworks were drafted by different bodies with different priorities. The mappings published by NIST, by SCF, and by UCF are all expert judgment about which controls are equivalent enough for cross-framework evidence to be reasonable. Treat them as starting points, not as guarantees.

How SimpleRisk implements this

SimpleRisk represents cross-framework mappings in the framework_control_mappings table. Each row links one control (control_id) to one framework (framework), with optional reference_name and reference_text columns for narrative annotation. A single SimpleRisk control can carry mappings to many other frameworks; the unique key is on (control_id, framework), which means one mapping per source-control to target-framework pair.

The UI lives on the control edit modal in /governance/index.php. Open the Controls tab, click any control, and the modal that opens has a Mapped Control Frameworks section showing the existing mappings with Add Mapping, Edit Mapping, and Delete Mapping controls. The field labels in the mapping form:

  • Framework — dropdown of installed frameworks (other than the control's own framework). The mapping target.
  • Reference Name — the framework-native identifier of the peer control in the target framework (for example, "A.5.15" if mapping to ISO 27001's access-control clause). Defaults to the source control's number if left blank.
  • Reference Text — optional narrative describing the mapping relationship. Useful for "this is a partial mapping; the target also requires X" annotations.

There is no dedicated v2 API endpoint for control mappings — they're created and edited through the control update form, not through a standalone CRUD interface. Programmatic mapping creation is supported through the control update endpoint (PATCH /api/v2/governance/controls/{id} with the mappings array in the body), but the mapping itself is a property of the control rather than a first-class resource.

For programs that need cross-framework mapping at scale (more than a few frameworks, more than a few hundred controls), the manual mapping path through the UI is impractical. Two productized solutions handle the bulk of the work:

  • The ComplianceForge SCF Extra ships the Secure Controls Framework with pre-built mappings to 200+ frameworks. Activate the Extra and the mappings load asynchronously into framework_control_mappings; subsequent framework installations from the SCF backbone inherit the mappings automatically. The Extra is free to use after registration. See The ComplianceForge SCF Extra.
  • The UCF Extra ships the Unified Compliance Framework's regulatory-citation database. The UCF approach is structured around regulations (HIPAA, GDPR, SOX, the long list) rather than around control objectives, which makes it the right answer for organizations whose compliance burden is heavy on regulatory citation. The Extra is paid (requires a UCF API key); see The UCF Extra.

For programs that need a few specific cross-mappings rather than a whole catalog, the manual UI path is the right tool. Map the controls that genuinely overlap; leave the rest unmapped. A partial mapping is more useful than no mapping; a fabricated mapping (mapping controls together that don't actually overlap) is worse than no mapping because it generates false-positive evidence.

Common pitfalls

A handful of patterns recur when teams approach cross-framework mapping.

  • Mapping every control to every framework, indiscriminately. Some controls genuinely overlap across many frameworks; some are framework-specific. Mapping a SOC 2 Trust Services Criterion to every PCI DSS requirement just because both relate to "security" produces evidence that doesn't hold up at audit. Map the controls that genuinely overlap; leave the framework-specific ones alone.

  • Treating an automated mapping as a guarantee. The SCF and UCF mappings are expert judgment about control equivalence; they're useful starting points, not authoritative endpoints. A serious assessor may disagree with a specific mapping (NIST 800-53 AC-2 isn't perfectly equivalent to ISO A.5.15; the scopes overlap but don't match exactly). Be ready to defend each mapping in the audit conversation, and adjust mappings the assessor pushes back on.

  • Skipping cross-framework mapping when running multiple frameworks. A multi-framework program without cross-mapping does the same control test work N times, where N is the number of frameworks. The first quarter the program isn't doing the same work three times pays for the SCF Extra (or a few hours of manual mapping setup) several times over. If the roadmap has more than one framework on it, get the mapping in place from the start.

  • Building mappings by hand when the SCF or UCF would do it. A team manually mapping ISO 27001 to NIST CSF to SOC 2 to PCI DSS (a half-week of careful work) is doing work the SCF Extra completed at activation in five minutes. Manual mapping is the right path for a custom framework or for a small program with two well-understood frameworks; for the standard public frameworks, the productized Extras almost always win on time-to-value.

  • Mapping at the family level instead of the control level. "AC family maps to A.5 clause" doesn't generate testable evidence; the families contain dozens of controls each, and the mappings between them aren't one-to-one. Map at the control level (AC-2 to A.5.15 to PR.AA-1 to CC6.1) even though it's more work. The granular mapping is what makes evidence rollup work; the family-level mapping doesn't.

  • Forgetting to update mappings when a framework version changes. ISO 27001:2022 reorganized the Annex A control structure; mappings built against ISO 27001:2013 don't transfer cleanly to the 2022 version. When upgrading a framework version, audit the existing mappings and update them; otherwise, the mappings reference controls that no longer exist or that have changed scope.

  • Treating reference_text as optional. The narrative annotation in Reference Text is what helps a future reader (the next reviewer, the next auditor, the next program owner) understand why a particular mapping was made. Leaving it blank produces a mapping that's right or wrong with no way to evaluate the reasoning. Spend the extra minute writing two sentences; the audit conversation later goes faster.

  • Assuming the test result transfers automatically. A passing test on AC-2 is evidence for the mapped controls in other frameworks, but it isn't automatically a passing test for them — the auditor for SOC 2 may want to see the AC-2 evidence reframed in SOC 2 vocabulary. Mapping reduces the test work; it doesn't eliminate the framework-specific narrative the audit conversation expects.

Related