OSCAL Control Layer: Control Mapping Model
| Control Mapping Schema | Control Mapping Converters | Reference |
|---|---|---|
| JSON Schema | XML to JSON Converter (How do I use this?) | Outline Reference Index |
| XML Schema | JSON to XML Converter (How do I use this?) | Outline Reference Index |
Purpose
The OSCAL control mapping model provides a structured, machine-readable representation of relationships among controls and control elements defined in disparate documentary sources, including standards, regulations, frameworks, and guidelines. The OSCAL controls mapping model can be represented in XML, JSON, and YAML formats.
The purpose of the controls mapping model is not to restate or duplicate the source control content, but to formally describe how controls and requirements relate to one another across authoritative sources. These relationships are expressed using well-defined set theory concepts such as equivalent-to, equal-to, subset-of, superset-of, intersects-with, and no-relationship to capture the syntactic, semantic or functional commonality between two similar sets of concepts referred to as source and target, the overlap, and gaps between controls originating in different catalogs or profiles.
The following definitions for the mapping methods are supported in this model:
Syntactic: How similar is the wording that expresses the two concepts. This is a word-for-word analysis of the relationship, not an interpretation of the language.
Semantic: How similar are the meanings of the two concepts. This involves some interpretation of each concept’s language.
Functional: How similar are the results of executing the two concepts? This involves understanding what will happen if the two concepts are implemented, performed, or otherwise executed.
Example:
Assume the following controls defined in two distinct OSCAL catalogs referred to as source-resource and target-resource identified by their IDs captured in the map as id-ref
Source Control Snippet
<control id="s-control-1">
<title>Sample source control</title>
<part id="s-control-1_stm" name="statement">
<p>Implement TLS.
</part>
</control>
Target Control Snippet
<control id="t-control-1">
<title>Sample target control</title>
<part id="t-control-1_stm" name="statement">
<p>Implement TLS version 1.2 or above.
</part>
</control>
Analysis
Method: syntactic
The s-control-1 control only expects TLS to be implemented, so to assess the control implementation and the satisfaction of the requirement, testing for the TLS existence is sufficient. The t-control-1 control enforces particular versions of the TLS implementation to be be supported, therefore, more assessment tests must be designed and performed. In this context, with the syntactic mapping method, the relationship is subset-of
Relationship: subset-of
Method: functional
The s-control-1 control only expects TLS to be implemented, so any known TLS version (1.0, 1.1, 1.2, 1.3) meets the requirements, meaning 4 options. The t-control-1 control enforces particular versions of the TLS implementation to be be supported, therefore, only TLS 1.2 and 1.3 will meet the requirements - a total of 2 options. In this context, with the functional mapping method, the relationship is superset-of
Relationship: superset-of
A simplified snippet of the control mapping between the source and target resources showing the map relationships analyzed above is provided below:
<mapping-collection uuid="2bbd81c0-1d1c-4566-9018-7ab4a644b32d">
<metadata>...</metadata>
<provenance method=”human” status=”complete”>
<mapping-description> Syntactic mapping example</mapping-description>
</provenance>
<mapping uuid=”f09bc381-6d6a-4828-b0fa-198e1dee52c1” method=”human” method-rationale=”syntactic” status=”complete”>
<source-resource type=”catalog” href=”URI-to-source-catalog”/>
<target-resource type=”catalog” href=”URI-to-target-catalog”/>
<map uuid=”1e04b08a-e62b-412d-8fd4-60a01d3f1943” >
<relationship>subset-of</relationship>
<source type=”control” id-ref=”s-control-1”/>
<target type=”control” id-ref=”t-control-1”/>
</map>
<map uuid=”0542cacb-f129-446d-bf21-2f083b67cea0” method-rationale=”functional” >
<relationship>superset-of</relationship>
<source type=”control” id-ref=”s-control-1”/>
<target type=”control” id-ref=”t-control-1”/><>
</map>
</mapping>
</mapping-collection>
The method used for matching the statements, controls or groups of controls - syntactic, semantic or functional – can be documented for the entire collection of mappings or locally overwritten for a particular relationship.
The most appropriate matching method that supports automation best is the syntactic method when correctly applied to the information analyzed.
Rather than serving as a narrative crosswalk document, the OSCAL controls mapping model provides a precise, computable syntax for expressing mappings at multiple levels of granularity, including entire controls, control statements, control objectives, or other identifiable control components. This structured representation enables automated analysis, comparison, impact assessment, and reuse of control relationships across compliance and risk management workflows.
The controls mapping model supports many-to-many relationships and allows mappings to be defined between controls drawn from multiple OSCAL catalogs and profiles simultaneously. This capability reflects real-world regulatory and operational environments, where organizations must demonstrate how requirements from one standard are satisfied, partially satisfied, or exceeded by requirements in another.
By encoding mapping relationships in a standardized, machine-readable form, the OSCAL controls mapping model enables tools to perform functions such as gap analysis, harmonization of compliance obligations, inheritance evaluation, and change impact analysis when source controls evolve. As with other OSCAL models, this digitalized structure allows mapping information to be easily imported, exported, indexed, validated, and processed by automated systems.
In OSCAL, the controls mapping model is generalized to support mappings among any control-based artifacts represented in catalog or profile form. This abstraction allows the same mapping mechanisms to be applied consistently across cybersecurity, privacy, supply chain, and other governance domains, supporting scalable and interoperable compliance across complex, multi-framework environments.
Authors and Consumers
Control Mapping Authors and/or Consumers
An accurate control mapping artifact can be used to reduce the cost, time and resources for assessing a system's compliance against the target resource by inferring the assessment results against the source resource and the collected evidence towards the target resource assessment.
Control Mapping Organization
An OSCAL control mapping is organized as follows, which is based on the standard OSCAL document structure:
- Metadata: Metadata syntax is identical and required in all OSCAL models. It includes information such as the file's title, publication version, publication date, and OSCAL version. Metadata is also used to define roles, parties (people, teams and organizations), and locations.
- Provenance: Describes requirements, incompatibilities and gaps that are identified between a target and source in a mapping item.
- Mapping: A mapping between the source and target resources.
- Back Matter: Back matter syntax is identical in all OSCAL models. It is used for attachments, citations, and embedded content such as graphics.
