Quick-reference card
| Field | Value |
|---|---|
| Control ID | CM-13 |
| Control name | Data Action Mapping |
| Framework | NIST SP 800-53 Revision 5 |
| Control family | Configuration Management |
| Baselines | — |
| Relevance | Organization (First Party and Third Party) |
| Risk severity | Medium |
What this control requires
CM-13 requires your organization to develop and maintain a documented map of every system operation that processes personally identifiable information (PII). The map serves as the foundation for understanding where personal data lives, how it moves, and who touches it throughout its lifecycle.
In practice, that requirement means you need to trace discrete data actions across the full PII lifecycle: collection, generation, transformation, use, disclosure, retention, and disposal. Your map must identify the specific PII elements being processed, the system components involved at each stage, and the owners or operators responsible for those components. Without this level of detail, privacy risk assessments become guesswork.
Where data action mapping breaks down is in execution. Organizations that skip the exercise consistently discover gaps during audits, where PII flows through components that no one realized were in scope. CM-13 forces that discovery to happen proactively, before an auditor or regulator finds it for you.
Why it matters
Organizations that lack a documented data action map routinely fail privacy impact assessments because they can’t identify what PII processing activities they’ve authorized. When your organization can’t demonstrate a clear, documented understanding of how PII flows through its systems, you introduce audit findings that erode trust with regulators, assessors, and business partners.
Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. For organizations subject to both NIST SP 800-53 and privacy regulations like GDPR, the absence of a data action map signals a systemic gap in your privacy program. Assessors treat this as evidence that the organization lacks the operational maturity to manage PII responsibly.
The risk compounds when you consider third-party relationships. Vendors processing PII on your behalf inherit the same mapping obligations. If your vendors can’t produce a data action map for the services they provide, the gap leaves you with an unverifiable claim that personal data is handled appropriately. That gap appears in third-party risk assessments and NIST 800-53 compliance reviews alike.
Beyond audit exposure, incomplete data action mapping makes it impossible to conduct meaningful privacy impact assessments. You can’t evaluate the risk of a data action you haven’t identified. Incomplete mapping creates a cascading failure across related controls like RA-08 and PT-02.
What attackers exploit
- Undetected lateral movement through unmapped PII-processing components that fall outside monitoring and access controls
- Third-party data exfiltration through vendor PII flows that were never documented or verified
- Privilege escalation targeting system components whose owners and operators aren’t tracked, making unauthorized access harder to detect
- Data retention gaps where PII persists in components beyond its authorized lifecycle, expanding the attack surface
- Disclosure pathways that bypass privacy controls because transformation and generation stages were never mapped
How to implement
For your organization
The hardest part of implementing CM-13 isn’t the documentation itself. It’s getting accurate, current information from every team that touches PII across your environment.
Step 1: Inventory your PII elements. Start with your existing PII inventory documentation and system component inventory. Identify every category of PII your systems process, including data you generate or transform, not just data you collect directly from individuals.
Step 2: Trace data actions across the lifecycle. For each PII element, document the specific data actions that occur at every stage: collection, generation, transformation, use, disclosure, retention, and disposal. Map these actions to the system components where they happen. Don’t rely on architecture diagrams alone. Validate with the teams that operate those components.
Step 3: Assign ownership. Every system component in your data action map needs a documented owner or operator, and auditors will check whether the individuals listed are current and whether they understand their responsibilities under the Configuration Management family.
Step 4: Integrate with existing documentation. Your data action map should overlay your system design artifacts, security plans, and privacy plans. Maintaining it as a standalone document that nobody references creates compliance risk. Embed it in the documentation your teams already use.
Step 5: Establish a change control process. Data action maps go stale fast. Tie updates to your existing change control workflow so that any system change affecting PII processing triggers a review and update of the map.
Evidence to produce: A documented data action map, updated PII inventory, system component inventory with ownership assignments, change control records showing map updates, and privacy plan references.
Common tooling categories: Data discovery and classification platforms, privacy management software, GRC tools with data mapping modules, and configuration management databases.
Common mistakes: Treating the data action map as a one-time deliverable rather than a living document. Mapping only the “happy path” of data collection and use while ignoring transformation, disclosure, and disposal. Assigning ownership to roles rather than named individuals.
For your vendors
When your vendors process PII on your behalf, their data action mapping obligations become your verification responsibility. You can’t outsource accountability for how personal data moves through a vendor’s environment.
What to ask in assessments:
- “Provide a documented map of all data actions performed on PII we share with you or that you process on our behalf.”
- “Which system components in your environment process our PII, and who owns each component?”
- “How do you track changes to your data action map when system components or processing activities change?”
- “Does your data action map cover the full PII lifecycle, including retention schedules and disposal procedures?”
Evidence to request: A data action map specific to the PII they process for your organization, their PII inventory documentation, system component inventory with ownership, and change control records demonstrating the map is actively maintained.
Red flags to watch for:
- The vendor provides a generic privacy policy instead of a specific data action map
- Their map covers collection and storage but omits disclosure to subprocessors or disposal methods
- No change control records exist for the data action map
- Component owners are listed as departments rather than identifiable individuals or roles with clear accountability
- The vendor can’t explain how their data action map relates to their privacy impact assessment process
Verification approaches: Request the data action map directly and compare it against the vendor’s service description and contract terms. Cross-reference the PII elements in their map with what you’ve authorized them to process. Ask for evidence of recent updates, particularly after system changes or new subprocessor engagements.
Evidence examples
| Evidence type | Example artifact |
|---|---|
| Data action map | Documented map identifying discrete data actions, PII elements processed, system components involved, and component owners at each lifecycle stage |
| PII inventory | Categorized inventory of all PII elements processed by the system, including data types, sensitivity levels, and applicable regulatory requirements |
| Configuration management documentation | Configuration management policy and plan defining how data action maps are maintained, reviewed, and updated alongside system changes |
| System design and privacy planning | System security plan, privacy plan, and system design documentation showing how the data action map integrates with broader security and privacy architecture |
| Change control records | Records demonstrating that data action map updates are triggered by system changes, new data processing activities, or personnel changes |
| System component inventory | Inventory of all system components that process PII, with documented owners or operators for each component |
Cross-framework mapping
No applicable content for this control.
Related controls
- AC-03 — Access Enforcement: access controls should align with the data actions and PII elements identified in your CM-13 map to ensure only authorized processing occurs
- CM-04 — Impact Analyses: system changes that affect PII processing require impact analysis, which depends on an accurate data action map
- CM-12 — Information Location: identifies where information resides, providing the foundation that CM-13 builds on by mapping what happens to that information
- PM-05 — System Inventory: the system inventory feeds directly into CM-13 by identifying the components that process PII
- PM-27 — Privacy Reporting: privacy reports rely on data action maps to accurately describe how the organization processes PII
- PT-02 — Authority to Process PII: data action mapping helps verify that every processing activity has documented legal authority
- PT-03 — PII Processing Purposes: the purposes documented under PT-03 should correspond to the data actions mapped under CM-13
- RA-03 — Risk Assessment: risk assessments for PII processing depend on the completeness of your data action map to identify what’s in scope
- RA-08 — Privacy Impact Assessments: privacy impact assessments can’t evaluate processing risks without an accurate map of data actions
Frequently asked questions
What is NIST SP 800-53 CM-13
CM-13 is a NIST SP 800-53 configuration management control that requires organizations to develop and document a map of all system data actions involving personally identifiable information. The map must trace PII through its full lifecycle, including collection, generation, transformation, use, disclosure, retention, and disposal, while identifying the system components and component owners involved at each stage. This control sits within the Configuration Management family and isn’t assigned to any baseline, meaning organizations adopt it based on their specific privacy requirements.
What happens if CM-13 is not implemented
Without a documented data action map, your organization can’t demonstrate that it understands how PII flows through its systems. Auditors will flag the absence of a data action map as a control deficiency, and related controls like RA-08 (Privacy Impact Assessments) and PT-02 (Authority to Process PII) become unverifiable. The downstream effect is that privacy risk assessments lack the foundational data they need, which can lead to regulatory findings and loss of stakeholder confidence in your privacy program.
How do you audit CM-13
Auditing CM-13 starts with requesting the organization’s documented data action map and verifying that it covers every stage of the PII lifecycle. Assessors compare the PII elements and system components listed in the map against the organization’s PII inventory documentation and system component inventory to confirm accuracy. They also review change control records to determine whether the map is actively maintained, and check that component owners listed in the map are current and accountable for their assigned processing activities.
What is a data action map
A data action map is a documented representation of every system operation that processes personally identifiable information, tracing each data action across the full PII lifecycle. It identifies the specific PII elements being processed, the system components involved in each action, and the owners or operators responsible for those components. Organizations use data action maps to provide the contextual factors needed for assessing privacy risk and ensuring that every processing activity is authorized, monitored, and aligned with privacy requirements.