Mapping Controls Across Frameworks

Security frameworks address the same set of underlying threats even when they use different structures. Every major catalogue covers access control (who may reach which resource), change management (how systems are modified without introducing vulnerabilities), incident response (how breaches are detected and contained), cryptographic protection, and physical security. This convergence is not accidental. The major frameworks were all informed by similar threat intelligence, by operational security research dating back to the 1990s, and increasingly by each other.

NIST SP 800-53 was originally developed for US federal systems but has been widely adopted in commercial and international contexts. ISO 27002 is the code of practice companion to ISO 27001, providing implementation guidance for the controls listed in Annex A of the standard. CIS Controls were developed by practitioners as a prioritised, actionable list derived from actual attack data. PCI-DSS is a contractual standard governing payment card data environments, written by the card brands. All four address the same core security domains; the differences are in granularity, sector specificity, and the degree to which implementation guidance is prescriptive.

The table above is illustrative, not exhaustive. Each framework uses a different level of granularity, so a single NIST control family may correspond to several ISO clauses and vice versa. The mapping process fills in this detail systematically. The table's purpose is to confirm the principle: the domains are shared, and the cross-mapping problem is real and tractable.

Before building a mapping, a practitioner must understand what each framework is and is not. NIST SP 800-53 revision 5 contains roughly 1,000 individual controls and control enhancements across 20 families. It is designed as a comprehensive catalogue from which a baseline is selected based on system impact level (low, moderate, high). The full catalogue is far more detailed than any other framework; organisations not subject to US federal requirements typically select a moderate baseline as a reasonable starting point.

ISO 27002:2022 contains 93 controls grouped into four themes: Organisational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). Each control has a statement, purpose, guidance, and other information. ISO 27002 is intentionally high-level; it does not specify exact technical configurations. That flexibility makes it broadly applicable but means that two organisations can both claim ISO 27001 certification while implementing controls in quite different ways.

CIS Controls v8 defines 18 control groups with 153 safeguards. Each safeguard is assigned to an implementation group. PCI-DSS v4.0 defines 12 requirements, each with detailed sub-requirements that specify exactly what cardholder data environments must do. PCI-DSS is the most prescriptive of the major frameworks; it specifies exact password length minimums, exact log retention periods, and quarterly external vulnerability scanning. Those specifics may align with NIST or ISO requirements at a general level but are more detailed than those frameworks demand.

NIST, CIS, and ISO all publish official crosswalk documents, and these are the correct starting point for any mapping project. NIST SP 800-53B appendix contains crosswalk tables to ISO 27001:2013 and to COBIT 5. NIST has also published a mapping between the NIST Cybersecurity Framework (CSF) and SP 800-53 controls, and a separate mapping between CSF and ISO 27001. The CIS Center publishes a Controls v8 mapping workbook that aligns CIS safeguards with NIST SP 800-53, ISO 27001, SOC 2, and PCI-DSS in a downloadable spreadsheet.

These official crosswalks use common notations to qualify relationships. A one-to-one relationship means a control in framework A directly addresses the same objective as a control in framework B. A partial relationship means one framework's control is more limited in scope than the other; implementing the narrower one does not satisfy the broader one. A supplemental notation means the framework's control adds something not covered by the mapped control. Practitioners must read these qualifications, not just the control identifiers.

Official crosswalks have known limitations. They are based on the framework versions current at the time of publication, so a crosswalk written against ISO 27002:2013 may not reflect changes introduced in the 2022 revision. They also represent the framework authors' view of equivalence, which may differ from a specific auditor's interpretation. Always verify that the crosswalk version matches the framework versions you are actually being audited against.

A unified control mapping is a spreadsheet or database table that brings together the crosswalks for all frameworks an organisation must satisfy, adds the organisation's own control implementations, and tracks evidence artefacts. The standard column structure for a minimal mapping is: a unique row identifier, the control identifier in each framework (one column per framework), a plain-language description of what the control requires, the organisation's implementation statement, the evidence artefact that demonstrates compliance, and the current status for each framework (compliant, partially compliant, gap).

Building the mapping proceeds in four steps. First, select the anchor framework: the most granular or the most heavily audited framework in the organisation's context. For a US federal contractor, NIST SP 800-53 is the natural anchor. For a commercial organisation whose primary driver is ISO 27001 certification, ISO 27002 controls are the anchor. Second, import the official crosswalks to populate the other-framework columns. Third, review every row for completeness: where the crosswalk marks a relationship as partial or supplemental, the gap must be examined. Fourth, add the evidence column and populate it from existing policy, procedure, and technical artefacts.

The completed mapping becomes the master reference for all audit programmes. When an auditor from a PCI-DSS qualified security assessor firm requests evidence for requirement 7.1 (access control), the compliance team retrieves the row for access control, identifies the evidence artefact already linked, and submits it. The same artefact may be linked to NIST AC-1 and ISO 27002 clause 5.15. Next quarter, when the ISO 27001 surveillance audit occurs, the same document is submitted again without additional work.

A unified mapping makes gaps visible in a way that single-framework analysis does not. A gap at the mapping level comes in three forms. First, a control required by one or more frameworks has not been implemented at all: the organisation has no policy, no technical control, and no evidence. Second, a control has been partially implemented: a policy exists but the technical enforcement is absent, or a technical control exists but is not documented. Third, a control is implemented but the evidence is not collected or not retained in a form that auditors can use.

Gap analysis should be scored using the same scale across all frameworks so that remediation can be prioritised without framework bias. A common approach assigns three statuses: full (the control is implemented and evidenced), partial (implemented but evidence is missing or incomplete), and gap (not implemented). Each gap row is then assessed for risk: how many frameworks require this control, how severe is the exposure if it is absent, and how difficult is remediation. The resulting prioritised list drives the remediation plan and feeds into the risk register.

A control required by four frameworks and currently unimplemented is a higher priority than one required by only one framework, because remediating it closes gaps across all four audits simultaneously. This multi-framework priority calculation is only visible when all requirements are in the same mapping table. Siloed compliance programmes cannot perform this calculation and routinely under-prioritise controls that are critical across multiple regimes.

A control mapping is not a one-time artefact. Frameworks are revised: ISO 27002 was updated in 2022 with a structural reorganisation from 14 clauses to four themes and the number of controls reduced from 114 to 93. PCI-DSS moved from version 3.2.1 to 4.0 in 2022, with the latter adding new requirements for authentication and web-based attack protection. NIST SP 800-53 revision 5 was published in 2020. Each revision requires the mapping to be updated to reflect new or changed control identifiers and requirements.

The maintenance process should be triggered by three events: a published revision to any in-scope framework, the organisation adding a new compliance regime (for example, a company entering a new market that requires DPDP Act 2023 compliance in India, GDPR compliance in the EU, or HIPAA compliance in the US), or a significant change to the organisation's IT environment that affects which controls are applicable. Each event triggers a targeted update rather than a full rebuild.

The mapping should also be reviewed after each audit. Auditors sometimes interpret control requirements differently from the official crosswalk, and those interpretations should be incorporated. If a PCI-DSS auditor interprets requirement 10.3 (protecting audit logs) as requiring a specific technical configuration that the mapping currently satisfies with a general log management policy, that gap is discovered at audit time and must be documented in the mapping for the next cycle. See also audit planning and scope definition for how audit findings feed back into the compliance programme.