What CM-13 data action mapping requires and why it is hard
CM-13 requires your organization to develop and document a map of its system data actions, meaning the system operations that process personally identifiable information (PII) across its life cycle. If a privacy or compliance lead has been told CM-13 applies, or has been asked for a data action map, the deliverable is a documented inventory of where and how PII moves and changes inside the system, from collection through use, storage, sharing and disposal. The control catalog frames this as a configuration management control, so the map is expected to sit alongside your other configuration records rather than live only in a privacy notice or a spreadsheet kept by one team. The control statement has no organization-defined parameters and no control enhancements in Release 5.2.0, so its wording applies as written and the scope is set by what you decide counts as a system operation that processes PII.
The privacy risk CM-13 addresses is that an organization cannot protect, limit or account for PII it has not located in its own processing. Data actions that were never written down are the ones that get copied into analytics pipelines, logs, backups and vendor integrations without review. CM-13 sits outside the SP 800-53B low, moderate and high baselines and outside the privacy baseline, so it is not selected by default. Your organization needs to decide, through tailoring or an overlay, whether it is in scope, and that decision should be recorded in the system security and privacy plan. Confirm the current baseline selections in the SP 800-53B profiles before you state to an assessor or customer that CM-13 is or is not required.
The work is hard for two reasons. First, PII flows are rarely documented: product teams know the features that collect data, but the downstream operations, such as a nightly export, a support tool that caches a field, or a debugging log that captures identifiers, are often unknown even to the owning team. Second, the map must be kept current. Each change to a feature, integration or data store can add or remove a data action, so the map has to be tied to change control and to the component inventory. Ask who owns the map, what triggers an update, and which change records show that a new data action was reviewed. Those answers, more than the first draft, determine whether the map passes assessment.
Which systems and teams CM-13 applies to once it is selected
CM-13 sits outside the SP 800-53B low, moderate, high and privacy baselines, so it enters scope only when the organization selects it through tailoring or an overlay. Once selected, the work follows the systems that handle PII and the people who own the data, and it shares inputs with several related controls.
Selecting CM-13 through tailoring
Because CM-13 is not in any SP 800-53B baseline, someone must record the decision to add it when the system's control baseline is tailored. Document the reason, such as a privacy requirement from a contract or regulator, and the system or systems it covers. Confirm whether an overlay from your authorizing body already selects it, since an overlay may change the expected scope. Keep the selection record with the system security and privacy plan so assessors can trace why the control is in place.
Systems that process PII
CM-13 applies to the system operations that process PII across its life cycle, so the first scoping step is an inventory of which systems collect, use, store, share or delete personal data. Include batch jobs, integrations, analytics pipelines and support tooling, not only the primary application. Check each system against the data it actually touches rather than the purpose it was built for, because PII often reaches systems that were never documented as personal data processors.
Data stores and third parties
Each data store that holds PII and each external party that receives it defines a boundary of the data action map. Identify databases, object storage, backups, logs, caches and exports, along with any processor or service provider that touches them. Confirm which of these locations are already recorded under CM-12 information location, since the two controls draw on the same inventory and drift apart when maintained separately.
Privacy and data owners
The people who own data flows must agree on the map before it can be trusted. Assign a privacy lead and a data owner for each system in scope, and name the personnel who answer assessor interview questions about data action mapping. Confirm that these roles match the responsibilities in your PM-5 system inventory and PT-2 authority documentation, so the same person is not described differently in two places.
Related controls that share inputs
Several controls draw on the same data action map: AC-3 access enforcement, CM-4 impact analyses, CM-12 information location, PM-5 system inventory, PM-27 privacy reporting, PT-2 and PT-3 processing authority and purpose, RA-3 risk assessment, and RA-8 privacy impact assessments. Update the map once and feed it to each control rather than maintaining separate copies. Changes to a data flow should trigger a review under CM-4 and RA-8 at the same time.
How an assessor tests CM-13 under SP 800-53A
This table compares the single determination statement for CM-13 with the examine, interview and test methods SP 800-53A Rev. 5 pairs with it, along with the objects an assessor names for each method. Read each row as a question the assessor will ask, the evidence that answers it, and where organizations usually fall short.
| Assessment method and objects | Evidence requested | Common findings |
|---|---|---|
| Determination statement: the organization develops and documents a map of system data actions that process PII across its life cycle | Current data action map covering collection, use, storage, sharing, retention and disposal, with a version date and an owner | Map exists only as a point-in-time diagram with no owner or review date |
| Examine: configuration management plan, PII inventory documentation, data mapping documentation | CM plan section showing data action mapping as a managed item, linked PII inventory entries, dated map revisions | CM plan never mentions data action mapping, so the map sits outside configuration control |
| Examine: change control records and system component inventory | Change tickets showing the map was reviewed when a system, data flow or component changed, and inventory entries tied to each data action | Map not updated after new services, integrations or storage locations were added |
| Interview: organizational personnel responsible for data action mapping and for managing information location | Named owner, documented responsibilities, and consistent answers from privacy, IT and system owners about how flows are recorded | Privacy and engineering teams describe different flows, or no one can name the map owner |
| Interview: organizational personnel with responsibilities for managing information location | Confirmation that the data action map matches where information is actually processed and stored, as documented under CM-12 | Map and information location records disagree on which systems hold PII |
| Test: mechanisms supporting or implementing data action mapping | Demonstration of the tool or repository used for the map, its access controls, version history and export of the current map | Map kept in unversioned documents or shared drives with no record of who changed what |
| Coverage check: third-party and external flows | Map entries for processors, sub-processors, SaaS services and transfers, with the contracts or data flow records behind them | Third-party flows missing or described only at the vendor name level, with no data action detail |
How to build a data action map that survives an assessment
This sequence turns CM-13 from a single sentence into a map an assessor can trace, from the systems in scope through the people who own each data action to the approval that proves the map is current.
Confirm the systems in scope
Start by listing the systems, services and environments that process personally identifiable information, using the system boundary already documented in your security and privacy plan. Name the business owner for each system and record which ones are excluded and why. Output: a scoped system list signed off by the system owner, which becomes the boundary the rest of the map must stay inside. An assessor will compare this list against the boundary, so any mismatch should be resolved here.
Inventory PII categories
For each in-scope system, identify the categories of personally identifiable information it holds or handles, such as contact details, identifiers, account data, health or employment records, and note whether any category is sensitive under your legal obligations. Work with privacy and records owners rather than relying on engineering assumptions alone. Output: a PII inventory that lists each category, its source and the systems where it appears. Assessors commonly examine PII inventory documentation as evidence for this control, so keep it dated and versioned.
Identify each data action and its components
Walk each PII category through its life cycle and record every data action: collection, use, storage, sharing, transfer and disposal. For each action, name the system operation that performs it and the components that carry it out, such as an application module, database, integration job, backup or third-party connection. Output: a data action register where every row links one operation to one or more components. Illustrative example: a customer onboarding form collects contact details, a batch job transfers them to a reporting database, and a nightly backup stores a copy.
Assign owners to each data action
Assign a named owner to every data action and a separate technical custodian for each component that performs it. The owner decides whether the action is still needed and whether it is lawful; the custodian keeps the component working as documented. Interview-based assessments ask who is responsible for data action mapping and who manages information location, so the answers must match the register. Output: an ownership table that names people or roles, with a record of who confirmed each assignment.
Link the map to inventory and information location records
Cross-reference each component in the data action register with the system component inventory and the information-location records that show where defined information is processed and stored. Every component named in the map should appear in the inventory, and every location in the information-location records should map back to a data action. Output: a traceability matrix that lets an assessor start from any PII category and follow it to a component, a location and an owner. Gaps found here usually mean either an undocumented component or a stale data action.
Set a review trigger tied to change control
Define the events that require the map to be updated, including new or changed data actions, new components, new third-party sharing or transfers, and decommissioning. Route these triggers through the configuration change control process so that a proposed change cannot be approved without checking its effect on the data action map. Output: a written trigger list and a change record template field that asks whether the map is affected. Assessors commonly review change control records to confirm that this link works in practice.
Record approval and version the map
Have the accountable owner and the privacy lead approve the completed map, then store it under version control so that each revision records what changed, when and by whom. Keep the approval record with the map and the previous versions available for comparison. Output: an approved, versioned data action map with a date, approver and change history. This is the document you hand to the assessor, together with the register, the inventory extract and the change records that show the map is maintained.
Which evidence passes a CM-13 review
An assessor testing CM-13 looks for a documented map of system data actions and for records showing that the map is maintained. The cards below cover the artifacts named in the assessment procedure and how each one stays current between assessments, so the map reflects the system an assessor sees on the day of testing.
The data action map itself
This is the core artifact: a documented list of the system operations that process PII across its life cycle, such as collection, storage, use, sharing, transfer and disposal. For each operation, record the system components involved, the PII categories touched and the business purpose. Check that every operation named in the map can be traced to a real function in the system. Keep the map in a controlled repository so that its state at any date can be shown.
PII inventory and data mapping documentation
Assessors examine the PII inventory and the data mapping documentation as supporting objects. The inventory lists the PII elements held, while the mapping documentation shows how those elements move between components. Confirm that the two documents use the same identifiers as the data action map, so a reviewer can follow one PII element from inventory to operation to component without reconciling different naming schemes.
Change control records for map updates
A data action map that changes with the system needs change records behind it. When a new feature, integration or data flow is approved under the configuration change control process, the change ticket should show whether the data action map was updated, who reviewed the privacy effect and when the map was revised. Sample several recent changes and confirm that each one that alters PII handling has a matching map entry.
Component inventory tie-in
Each data action names the components that carry out the operation, so the map depends on the system component inventory. Reconcile the two: every component referenced in the map should appear in the inventory, and every inventory entry that processes PII should appear in at least one data action. Gaps in either direction are a common finding, and they usually appear after cloud or container changes that were not recorded.
Approved configuration management plan section
The configuration management plan should state that the data action map is a managed configuration item, name the role that owns it, describe how it is updated and set the review cycle. Confirm that the plan section has been approved by the organization's designated authority and that the approval date and version are on record. An assessor will compare what the plan says with what the map and change records actually show.
Version history and dated reviews
Between audits, keep the map under version control so that each revision records what changed, when and by whom, and so that earlier versions can be compared or restored. Schedule dated reviews by the owner of the map and record the reviewer's sign-off, even when no change was needed. Tools such as XWiki keep page version history, and BookStack permissions can restrict who may edit a page while others read it. Confirm the review frequency with your own policy, since the control does not set one.
Keeping the data action map accurate as systems change
A data action map decays the moment a system changes and nobody tells the privacy function. New features, a new analytics integration, a changed log shipper or a vendor's new sub-processor can each add a data action that touches PII without appearing in the map. Most of these changes pass through engineering and procurement without a privacy review, so the map describes the system as it was at its last update. For CM-13, the practical goal is to close that gap at the point where changes are already controlled, rather than relying on periodic manual reviews to catch drift.
The most reliable hook is the change control process the organization already runs under CM-3 and the impact analysis required by CM-4. Build a question into the change request template that asks whether the change creates, alters or removes any data action involving PII, and make a completed map update a condition for approving that kind of change before implementation. CM-12 information location provides the second check: when a change moves PII to a new component, region or service, the location record and the data action map should be updated together. Confirm with your change board how these records are linked, because an assessor will ask to see a change that touched PII and the map entry it produced.
The document tool's version history is the evidence that the map was kept current. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and BookStack records edits through its page history, so an assessor can compare versions and trace each update to a change request. Confirm that the platform you choose retains this history for the full review period, that page edits are attributable to named accounts, and that the roles allowed to edit the map are limited to the privacy and engineering owners named in your change procedures. A map with no dated trail of updates is hard to defend, even if its contents are accurate.
What a CM-13 data action map costs in money and effort
This table lists each cost component of a CM-13 data action map, who carries it, whether it is one-time or recurring, and what moves it up or down. No prices or durations are supplied for this control, so use the drivers and quote questions to compare written scopes. Read the one-time rows first, then the recurring rows, since most of the lasting cost sits in keeping the map current.
| Cost component | One-time or recurring, and who is paid | What drives it up or down | What to ask for in a written quote |
|---|---|---|---|
| Discovery and interviews with system owners | One-time. Internal staff time, plus any partner time if scoped in | Number of systems, business processes and owners who touch PII. Interviews run longer when data flows are undocumented | Named systems in scope, list of owners to interview, and the output format for interview notes |
| Building the first data action map | One-time. Internal privacy and engineering staff, plus any partner time if scoped in | Number of data actions (collect, store, use, share, retain, delete), PII categories and third parties receiving data | Deliverable format, the level of detail per data action, and which PII categories are covered |
| Privacy review of data actions | Recurring. Privacy office or DPO time, usually internal | Frequency of review, number of processing purposes, and regulatory obligations such as GDPR where they apply | Review cadence, approver roles, and how review findings are recorded and tracked |
| Document tooling and licenses | Recurring. Zero license cost for self-hosted open-source wiki or documentation platforms, but hosting and administration time still apply | Choice of platform, hosting location, backup and access control requirements | Hosting model, backup and restore approach, version history retention, and role-based access settings |
| Keeping the map current through change control | Recurring. Internal change board and system owner time | Rate of system change, number of new integrations, and whether CM-3 and CM-4 workflows already flag data flow changes | How map updates are tied to change tickets, who approves them, and how stale entries are detected |
| External review or implementation support | Optional, fixed-scope. Paid to an implementation partner or privacy consultant | Whether internal staff have the capacity, the number of systems in scope, and whether an existing map needs rework | Written scope, deliverables, exclusions, and confirmation that the partner prepares evidence without issuing any assessment result |
| Auditor sampling and assessment | Per assessment. Paid to the independent auditor or assessor | Assessment scope, number of systems sampled, and whether the map is available and current at the start of testing | Sampling approach, evidence request list, and the assessor's fee basis as stated in their engagement letter |
Who owns CM-13 and what can be outsourced
Your organization owns CM-13 in full. The control requires you to develop and document a map of the system operations that process personally identifiable information across its life cycle, and the accountability for what that map says stays with you. Your privacy office, data owners and system owners decide which operations count as data actions, where personal data enters, moves, is stored and is deleted, and which risks those operations create.
- Map content: Confirm which data actions exist, who performs them and which components carry them out.
- Data owner approvals: Record sign-off from the people accountable for each data set before the map is treated as current.
- Change control trigger: Define which system changes require the map to be reviewed, and connect that rule to your change control process.
- Ownership of privacy decisions: Keep decisions about lawful basis, retention and risk acceptance inside your governance structure.
- Interview readiness: Name the personnel who manage information location and data action mapping, since an assessor will interview them.
Before engaging anyone, confirm that a named owner can answer for every data action on the map.
An implementation partner can prepare the work that surrounds the map, but cannot decide privacy risk or sign off the document. A partner such as DeployOpen typically helps with preparation: structuring the document, running discovery workshops with your teams, collecting component links from the systems in scope and setting up version-controlled storage on infrastructure you host. The content of each data action remains your decision.
- Document structure: Build a template that matches the way your organization records data actions and links them to the CM-12 information location records.
- Discovery workshops: Facilitate sessions where owners describe operations, which the partner then records for your review.
- Component links: Collect references from the configuration management plan, PII inventory and system component inventory.
- Self-hosted version control: Set up storage in your environment, for example a self-hosted wiki with page history, so every change to the map records what changed, when and by whom.
- Limits: The partner does not decide privacy risk, approve the map or sign it off as the organization's position.
Ask any partner to state in writing which tasks it performs and which remain with your named owners.
An independent auditor, assessor or certification body tests CM-13 and issues any report or conclusion. The auditor uses the SP 800-53A procedure for the control, which contains one determination statement and examine, interview and test methods. Examine objects include the data mapping documentation, PII inventory, change control records and system component inventory. Interview objects include the personnel responsible for data action mapping, and test objects include the mechanisms that support the mapping.
- Examine: The auditor reviews whether the map exists, is documented and covers the life cycle of personal data.
- Interview: The auditor asks owners how the map is kept current and how changes trigger updates.
- Test: The auditor checks whether the supporting mechanisms, such as version history and change records, work as described.
- Independence: A partner that wrote the map or helped with it cannot write the assessment conclusion, so the auditor's findings must come from its own testing.
- Reporting: Only the auditor issues the report that states whether the control is met.
Confirm the auditor's independence rules and the scope of its engagement before the fieldwork begins.
How XWiki and BookStack keep the data action map under version control
A data action map is only useful if reviewers can see what changed, who changed it and who approved it. XWiki and BookStack are open-source wiki platforms that can hold the map, its approvals and its history inside your own infrastructure, but they record documentation changes only. Discovering where PII actually flows still depends on your people, your system owners and your technical analysis.
XWiki version history
XWiki keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions of a data action map and roll back to an earlier version when an unapproved edit appears. For CM-13, this gives the organization a dated trail showing how each data action was added, altered or retired over the system's life cycle. Confirm that your retention and backup settings keep the full history available for the period your assessor will sample.
BookStack role-based permissions
BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. You can let system owners edit the data action pages for their own systems while limiting privacy staff to review and approval. This separation supports the CM-13 expectation that the people who maintain the map are the people responsible for it. Check that the role model matches your documented responsibilities before you grant edit rights broadly.
Recording approvals alongside the map
Version history shows what changed, but it does not prove that a privacy owner reviewed the change. Store approval records, such as the reviewer name, date and the version approved, in the same wiki or in a linked change control record. Auditors testing CM-13 commonly look for this link between an approved map version and the change control records for the systems it describes. Confirm with your assessor which approval format they accept before you design the workflow.
What these tools do not discover
Neither XWiki nor BookStack scans code, databases or data flows to find personally identifiable information. Someone must identify the system operations that collect, use, store, share and delete PII, then document them. The tools only hold and version that documentation. Treat them as the record of the map, and plan separate discovery work, such as interviews with system owners and reviews of data stores, to build its content.
Common questions about CM-13 data action mapping
Is CM-13 required by default under NIST SP 800-53?
No. CM-13 is not selected in any SP 800-53B baseline, including the low, moderate and high security baselines and the privacy baseline. It applies only when an organization selects it, either by tailoring a baseline or through an overlay that a contract, agency or program requires. Check the baseline selection in your system security and privacy plan, and check any contract or overlay language, because that is where an obligation to implement CM-13 would normally appear. If no document requires it, the control is a voluntary privacy practice that still supports the PII controls you do select.
How long does it take to build a data action map?
No duration has been established for this work, so confirm it in the written scope rather than relying on a general estimate. The main drivers are the number of systems that process PII, how many data actions each one performs across collection, use, storage, sharing and disposal, how well existing data flow diagrams and PII inventories are documented, and how many system owners must review the results. A single system with current diagrams is a very different job from a multi-system environment with undocumented interfaces. Ask the partner to state which systems, data actions and review rounds the timeline covers.
Can our own team build the data action map without outside help?
Yes, if your team has privacy and engineering knowledge of the system and the time to document it. The assessor will look for a documented map, evidence that it reflects the system as operated, and evidence that the responsible people reviewed it. Internal teams often struggle to see data actions that happen in batch jobs, third-party integrations or support workflows, so an outside reviewer can help find gaps. Decide which part you will own internally and which part you want a partner to prepare, and write that split into the scope before work starts.
What do system owners need to provide for the map?
System owners supply the operational detail that the map depends on. Typically they confirm which functions handle personally identifiable information, the data sources and recipients, where data is stored and processed, how long it is retained, and how it is disposed of. They also review drafts and confirm that the map matches production behavior. Ask each owner to name a technical contact who can answer questions about interfaces, logs and data stores, because most delays come from waiting for those answers rather than from the documentation itself.
How does CM-13 differ from CM-12 information location?
CM-13 maps the system operations, or data actions, that process PII across its life cycle, so it describes what the system does with personal data. CM-12 documents where defined information is processed and stored, on which components, who has access there and how that location changes. The two controls overlap in practice because both depend on a PII inventory and component records, but they answer different questions. CM-13 is about operations and flows, while CM-12 is about locations and access. Keep them as linked documents so a change in one prompts a review of the other.
Can a consulting partner issue a certificate for CM-13?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, including a documented data action map and its supporting records. Only an independent assessor or certification body can issue an assessment report, attestation or certificate. For SP 800-53, the assessment is performed against the procedures in SP 800-53A, and the authorizing official or the organization's own process determines the outcome. Ask any partner to show how their work feeds the assessment rather than replaces it.
How do we keep the data action map current between assessments?
Treat the map as a controlled document. Assign an owner, store it in a version-controlled location, and require a review whenever a change affects PII handling, such as a new feature, integration, vendor or retention rule. Self-hosted tools can help: XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack lets you limit editing rights by role at the shelf, book, chapter or page level. Confirm that either tool meets your own access and record-keeping requirements before you adopt it.
Where organizations fall short on CM-13 and how to close each gap
CM-13 is easy to satisfy on paper and hard to keep current in practice. The gaps below share a root cause: the data action map is treated as a one-time document rather than a governed record tied to the systems, changes and people that create the data flows it describes.
Map covers only the main application
Many maps describe the primary application and skip the flows that leave it: identity providers, analytics, backup services, support tooling, email relays and vendor-hosted components. CM-13 asks for a map of system operations that process PII across its life cycle, so third-party and downstream operations belong in scope. Check the map against your system component inventory and your data processing agreements to find flows the map omits.
Map has no owner or review date
A spreadsheet saved to a shared drive with no named owner goes stale after the first release. Assign an accountable owner, record the date of the last review and set a trigger for re-review, such as a new data category or a new processor. Use a wiki with version history so the reviewer can see what changed, when and by whom.
Map is not linked to change control
When a new feature starts processing PII but the data action map is not updated, the change record shows a security review that never looked at data flows. Add a required question to the change request template asking whether the change creates, alters or removes a data action. Link approved changes back to the affected entries in the map.
PII categories are undefined
Without a defined list of PII categories, teams label the same data differently and the map cannot be tested for completeness. Agree on a categorization that your privacy office and security team both use, and tag each data action with the categories it processes. This also gives assessors a consistent basis for comparing the map with the PII inventory.
Approvals are missing
A map that nobody approved has no authority behind it. Record who reviewed and accepted the map, typically the system owner together with privacy and security representatives, and keep that approval with the document. Assessors interview the people responsible for data action mapping, so confirm those people can explain the approval and the review history.
Privacy and security keep separate versions
When privacy keeps one map and security keeps another, the two drift apart and each team relies on an incomplete picture. Maintain one authoritative map with defined views for each function, and reconcile differences during each review cycle. Restrict edit rights so that only the named owner or approvers can change the authoritative version.
How DeployOpen prepares CM-13 evidence in your environment
DeployOpen plans, implements and documents the data action map for CM-13 inside your own infrastructure, under a fixed-scope agreement with deliverables and timelines agreed in writing before work starts. In practice, that means working with your privacy office, system owners and configuration management staff to identify the system operations that process personally identifiable information across its life cycle, recording them in the map, and keeping the map linked to the PII inventory, data mapping documentation, configuration management plan and system component inventory that the assessment objects for CM-13 name. Where your platforms use self-hosted open-source tools for documentation and version history, such as XWiki for versioned pages or BookStack for role-based editing permissions, DeployOpen can configure them so that changes to the map are recorded with who made them and when, and so that edit rights match the people accountable for the data flows. Your organization still owns the map, decides which operations are in scope, and approves each version.
DeployOpen does not issue audit reports, attestations or certifications. An independent assessor tests CM-13 against the procedure in SP 800-53A, and that assessor, not DeployOpen, decides whether the evidence is sufficient. Before you request a quote, confirm with your assessor which records they expect, how they want the map presented, and whether the privacy baseline or an overlay applies, because CM-13 is not selected in any SP 800-53B baseline and its inclusion depends on your tailoring decisions. The next step is to send us your system boundary, the privacy and configuration documents you already maintain, and the assessor's requirements, so that we can draft a written scope and quote that states exactly which records we will prepare and which decisions remain with your team.
