A control library is an organization's single, maintained catalogue of its internal controls, each with a description, owner, frequency and evidence, mapped to the risks and requirements it addresses. Framework mapping, often called a crosswalk, records how the requirements of one framework relate to those of another, or to the controls in the library. Mapping lets one tested control provide evidence for several frameworks, such as SOC 2, NIST CSF 2.0 and PCI DSS v4.0.1, but only to the extent the requirements actually match. NIST's mapping guidance distinguishes relationships such as equal, subset, superset and intersecting, and requirements that map to nothing are kept visible as gaps.
A control library is a maintained catalogue of an organization's internal controls, in which each control is recorded once with its objective, description, owner, frequency, type and the evidence it produces, and is linked to the risks it mitigates and the requirements it helps satisfy. Framework mapping is the practice of recording how requirements in one control framework, standard or regulation relate to requirements in another, or to the controls in the library. A document that records these relationships is commonly called a crosswalk.
The two work together. Organizations are often subject to several overlapping frameworks at once, for example a SOC 2 examination for customers, PCI DSS for card data and a regulator's cybersecurity rule. Without a library and mappings, each framework tends to acquire its own list of controls, and the same underlying activity is documented and tested several times.
What a control record contains
| Field | Content |
|---|---|
| Identifier and objective | A unique ID and the risk or requirement the control exists to address. |
| Description | What is done, by whom, how often and with what system, specific enough that a tester can check it. |
| Owner | The person accountable for operating the control, usually a first-line role. |
| Type and nature | Preventive or detective; manual, automated or IT-dependent manual. |
| Frequency | Per event, daily, weekly, monthly, quarterly or annually. |
| Evidence | The record the control leaves behind: a log, approval, ticket, reconciliation or report. |
| Mappings | Links to the risks in the risk register, to the requirements in the regulatory inventory, and to each framework requirement it supports. |
| Test history | Design and operating-effectiveness test results, exceptions and related issues. |
Common controls
A common control is a control that serves many systems, business units or frameworks at once and is operated centrally. NIST Special Publication 800-37 Revision 2 (the Risk Management Framework) defines a common control as a security or privacy control that is inherited by multiple information systems or programs, and includes a task (P-5) for identifying and documenting them. Typical examples are the policy framework, security awareness training, identity and access management, and incident response. Identifying common controls is usually an early step in building a library, because these controls appear in almost every framework and are frequently documented more than once.
Frameworks commonly mapped
- NIST Cybersecurity Framework (CSF) 2.0 (February 2024). Organizes cybersecurity outcomes into six Functions (Govern, Identify, Protect, Detect, Respond and Recover), divided into categories and subcategories. NIST publishes informative references that map CSF 2.0 subcategories to other documents, such as NIST SP 800-53, and makes them available through its Cybersecurity and Privacy Reference Tool and the National Online Informative References (OLIR) Program.
- AICPA 2017 Trust Services Criteria (revised points of focus, 2022). The criteria used in SOC 2 examinations. The common criteria incorporate the 17 principles of the COSO Internal Control: Integrated Framework (2013), with supplemental criteria for logical and physical access, system operations, change management and risk mitigation. The AICPA publishes mapping documents from the criteria to other frameworks, including NIST CSF, NIST SP 800-53 and ISO/IEC 27001.
- COSO Internal Control: Integrated Framework (2013). Five components and 17 principles, often used as the top level of a library because most control frameworks can be organized under its components.
- PCI DSS v4.0.1 (June 2024). The PCI Security Standards Council's data security standard for payment card data, organized around twelve principal requirements. Version 4.0.1 was a limited revision of v4.0 that clarified guidance without adding or removing requirements; v4.0 was retired on December 31, 2024.
How a crosswalk is built
A crosswalk is built by comparing each requirement in a source document with each potentially related requirement in a target document and recording the relationship. NIST Interagency Report 8477 (February 2024), Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines, describes three styles of mapping that NIST accepts for the OLIR program:
- Concept crosswalk: records only that two concepts are related, without characterizing the relationship. It is faster to produce than the other styles and conveys less information.
- Supportive relationship mapping: records whether one concept supports, or is supported by, another, for example whether a control helps achieve an outcome.
- Set theory relationship mapping: records the logical relationship between two concepts as one of five types: subset of, intersects with, equal, superset of, or no relationship.
The set theory types make the reliability of a mapping explicit. If a library control is equal to, or a superset of, a framework requirement, testing the control can provide evidence for that requirement. If the control merely intersects with the requirement, part of the requirement is not covered, and the uncovered part needs another control or a documented gap.
Testing once for several frameworks
The practical purpose of a mapped library is that a single test of a control can be cited as evidence for every requirement it maps to. A quarterly access review, for example, may support a SOC 2 criterion on logical access, a CSF 2.0 subcategory on access permissions, and a PCI DSS requirement on reviewing user accounts. Testing it once, with a sample and method that satisfy the strictest of those requirements, avoids three separate tests.
The approach has limits:
- Different specificity. Frameworks state requirements at different levels of detail. PCI DSS often prescribes frequencies, lengths and configurations; the Trust Services Criteria state criteria that an organization meets with controls of its own design. A control that satisfies a general criterion may not meet a prescriptive requirement.
- Different scope. A control tested across the SOC 2 system may not have been tested across the cardholder data environment, or the reverse.
- Different assessors and standards of evidence. A SOC 2 report is issued by a CPA firm under AICPA attestation standards; a PCI DSS assessment follows the PCI Security Standards Council's assessment procedures. Each assessor decides independently whether evidence is sufficient.
- Mapping error. Mappings are judgments. Published mappings from standard-setters are a starting point, and NIST IR 8477 notes that the person performing a mapping chooses the rationale, so two careful mappings can differ.
- Version drift. When a framework is revised, as CSF moved from 1.1 to 2.0 and PCI DSS from 3.2.1 to 4.0 and 4.0.1, mappings to the earlier version need review.
Keeping unmapped requirements visible
A crosswalk records coverage, and it also records the absence of coverage. Requirements that map to no control, and requirements whose only mapping is an intersecting one, are the gaps a readiness assessment or gap analysis exists to find. Good practice keeps them as explicit entries, each with an owner and a remediation decision, rather than omitting them from the crosswalk. A crosswalk that shows only the requirements that were matched can make coverage look more complete than it is.
Where control libraries are kept
Small programs keep a control library and crosswalks in spreadsheets. Larger programs typically keep them in GRC software, which links each control to risks, requirements, tests, evidence and issues, and can import published mappings such as NIST's informative references or the AICPA's mapping documents. The quality of the library depends on the precision of the control descriptions and on the maintenance of the mappings, not on the tool.
Primary sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 26, 2024): The six Functions and the categories and subcategories of CSF 2.0.
- NIST, CSF 2.0 Informative References: NIST's published mappings from CSF 2.0 to other documents, and the OLIR Program.
- NIST, Cybersecurity and Privacy Reference Tool (CPRT): Browsable and downloadable NIST reference data and mappings.
- NIST IR 8477, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines (February 2024): Concept crosswalk, supportive relationship and set theory relationship mapping styles.
- NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations (December 2018): Common controls and Task P-5, common control identification.
- AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022): The SOC 2 criteria and their alignment with the COSO 2013 principles.
- AICPA, Mapping: 2017 Trust Services Criteria to NIST CSF: One of the AICPA's published mappings from the criteria to other frameworks.
- COSO, Internal Control: Integrated Framework (2013): Five components and 17 principles of internal control.
- PCI Security Standards Council, PCI DSS v4.0.1 (June 2024): The current version of the Payment Card Industry Data Security Standard.