Control Mapping: Satisfying Multiple Frameworks With One Control Set

If you answer to more than one framework, you have probably noticed they ask for many of the same things in different words. Control mapping is the practice of linking each of your internal controls to every external requirement it satisfies. You design, operate and evidence a control once, and it counts toward SOC 2, ISO 27001, PCI DSS and the NIST Cybersecurity Framework at the same time.

Done well, mapping cuts duplicate work and gives auditors consistent answers. Done badly, it produces a spreadsheet that claims coverage you don't actually have. This post covers how to build a mapped control set, which published crosswalks to start from, and where mappings usually go wrong.

What is a common control framework?

A common control framework is a single set of control statements that you own, written in your own terms, with each control mapped to the external requirements it covers. The frameworks become different views of the same underlying controls rather than separate programs.

Each control in the set should record a few basic attributes:

The key point is the direction of the mapping. You start from what you actually do and map outward to requirements. You don't create a separate control for every line of every framework.

Why map controls instead of running each framework separately?

Running frameworks in parallel creates predictable problems. Control owners get the same evidence request from three auditors in slightly different forms, and policies drift apart because each framework has its own version. A mapped control set fixes most of this:

• One policy set instead of a policy library per framework
• One evidence request per control, per period
• Consistent answers to auditors and customers
• Faster gap analysis when a new framework arrives, because you compare it against controls you already run

Which framework versions should you map to?

Mappings are only as good as the versions they reference. As of this writing, these are the versions most small and mid-sized organizations are working with:

Two version changes deserve attention. ISO 27001:2022 regrouped and renumbered Annex A, so a mapping built against the 2013 edition's 114 controls won't line up cleanly. PCI DSS 4.0 also renumbered many requirements. If some of your assessments still run against PCI DSS 3.2.1, map to both versions until you move over.

Which crosswalks can you start from?

Don't build every mapping from scratch. Several free, published crosswalks give you a starting point. Treat them as a first draft to validate, not a final answer.

NIST's OLIR program

NIST's National Online Informative References (OLIR) Program hosts a catalog of mappings between NIST documents, such as the Cybersecurity Framework and SP 800-53, and other standards and frameworks. Subject matter experts submit the mappings using a standard format.

A useful feature of OLIR is that each mapping states the type of relationship between two elements. The options include "equal," "subset of," "superset of," "intersects with" and "not related to." That vocabulary is worth adopting in your own mappings.

NIST SP 800-53 Rev. 5 mappings

NIST publishes mapping spreadsheets between SP 800-53 Rev. 5 and the Cybersecurity Framework, along with a mapping from SP 800-53 Rev. 5 to ISO/IEC 27001. SP 800-53 is detailed enough to act as a hub that connects other frameworks.

Check the edition of every target before relying on a mapping. The informative references built into CSF 1.1, for example, point to ISO/IEC 27001:2013 and SP 800-53 Rev. 4 rather than the current editions.

CIS Controls v8 mappings

The Center for Internet Security publishes mappings from CIS Controls v8 to a range of other frameworks. Because the safeguards are specific and action-oriented, CIS works well as a technical baseline. It also helps you check whether a high-level requirement is backed by concrete practice.

CSA Cloud Controls Matrix

The Cloud Security Alliance's Cloud Controls Matrix (CCM) v4 has 197 control objectives across 17 domains, written specifically for cloud environments. It includes mappings to other standards, including ISO/IEC 27001 and the AICPA Trust Services Criteria. For cloud-first organizations it can serve as the spine of a common control framework, with the other frameworks mapped onto it.

How do you build a control mapping?

A workable process for a small team looks like this:

1. List your obligations. Record each framework, its version, and its scope. The PCI DSS cardholder data environment, the SOC 2 system boundary and the ISO 27001 ISMS scope are often different.
2. Pick a spine. Use one framework's structure, such as ISO 27001 Annex A, CIS Controls v8 or the CSA CCM, or your own set of control domains.
3. Write control statements in your own words. Describe what you actually do, specifically enough that someone could test it.
4. Map using published crosswalks as a draft. Then check each link against the full requirement text.
5. Record the relationship strength. Note whether each control fully meets a requirement or only partly does, and write down what's missing.
6. Attach owners, frequencies and evidence to every control.
7. Schedule reviews. Revisit the mapping when a framework version changes or a control changes.

How does evidence reuse work?

Evidence reuse is where mapping pays off. You collect a scan report, access review or change record once and tag it with every requirement it supports. Three rules keep it honest.

Meet the strictest requirement

When frameworks disagree on frequency, retention or specificity, design the control to the strictest one. Vulnerability scanning shows why. PCI DSS 4.0 requires internal and external scans at least once every three months, with external scans performed by an Approved Scanning Vendor. CIS Controls v8 calls for internal scans at least quarterly and external scans at least monthly. SOC 2 lets you set your own frequency. A control that scans externally every month, with a quarterly scan by an Approved Scanning Vendor, satisfies all three.

Log retention works the same way. PCI DSS 4.0 requires at least 12 months of audit log history, with the most recent three months immediately available. If your general logging standard keeps less, the in-scope systems need to meet the PCI figure.

Match the scope

Each auditor samples from their own population. A PCI assessor wants evidence from systems in the cardholder data environment. A SOC 2 auditor wants evidence from the system described in your report. If a control covers the union of all scopes, make sure your evidence can be filtered to each one.

Align the calendars

A SOC 2 Type II period, an ISO 27001 surveillance audit and an annual PCI DSS assessment rarely line up by default. Where possible, set control frequencies and evidence windows so one run of a control lands inside every audit that needs it. Ask your auditors early whether they will rely on shared evidence, and in what form.

Who should own controls and the mapping?

Ownership needs two layers.

Control owners operate a control and produce its evidence. They should be the people who do the work, such as the infrastructure lead for vulnerability scanning or the HR manager for onboarding checks. Assign owners to your controls, not to framework requirements. Nobody should own "ISO 27001 Annex A 8.8" as a separate task from the scanning they already run.

The mapping owner is usually someone in compliance or GRC. They maintain the crosswalk, track framework changes, confirm new controls are mapped, and field auditor questions about coverage. Without a named mapping owner, the spreadsheet decays after the first audit.

How do you avoid over-mapping?

Over-mapping means claiming a control satisfies a requirement it only partly addresses. It's an easy mistake to make and an expensive one to discover in the middle of an audit. Warning signs include a single control mapped to dozens of requirements, mappings based on matching keywords, and a policy document mapped as if it proved the practice.

To keep mappings accurate:

• Use relationship types. Borrow OLIR's vocabulary. A control that "intersects with" a requirement leaves a gap you need to close elsewhere.
• Map to the requirement text, not the heading. Prescriptive frameworks hide specifics in the detail. A generic "strong passwords" control won't satisfy a PCI DSS requirement that sets a minimum length and character mix.
• Separate policy from practice. A policy can satisfy a requirement to have a policy. It doesn't satisfy a requirement to do something.
• Trace a sample. Before each audit, pick a handful of requirements and follow them from mapping to control to evidence. If you can't produce the evidence, the mapping is wrong.

Frequently asked questions

Can we use a spreadsheet for control mapping?

Yes. A spreadsheet works well for two or three frameworks and a few dozen controls. As the numbers grow, maintaining links by hand becomes error-prone, but the structure described above works in any tool.

Is there a single mapping between SOC 2 and ISO 27001?

There is no official one-to-one equivalence. Published crosswalks, including the CSA CCM's mappings, link both to common controls. Check which edition of ISO 27001 a mapping targets, since many still reference 2013.

What happens when a framework releases a new version?

Treat it as a gap analysis against your existing control set. Most requirements will map to controls you already run. Update the references, then focus effort on the requirements that are genuinely new.

Should the mapping drive how we design controls?

Only partly. Controls should first address your own risks. Mapping then shows how those controls satisfy external requirements and where you need to add or adjust something.

Key takeaways

• Build one set of controls in your own words and map outward to each framework.
• Start from published crosswalks, then validate every link against the requirement text.
• Check versions carefully, especially ISO/IEC 27001:2022 and PCI DSS 4.0 against their predecessors.
• Design each control to the strictest frequency, retention and scope among the frameworks it serves.
• Name control owners and a mapping owner, and trace sample requirements to evidence before every audit.