Control statement
Develop and document a map of system data actions.
Discussion
Data actions are system operations that process personally identifiable information. The processing of such information encompasses the full information life cycle, which includes collection, generation, transformation, use, disclosure, retention, and disposal. A map of system data actions includes discrete data actions, elements of personally identifiable information being processed in the data actions, system components involved in the data actions, and the owners or operators of the system components. Understanding what personally identifiable information is being processed (e.g., the sensitivity of the personally identifiable information), how personally identifiable information is being processed (e.g., if the data action is visible to the individual or is processed in another part of the system), and by whom (e.g., individuals may have different privacy perceptions based on the entity that is processing the personally identifiable information) provides a number of contextual factors that are important to assessing the degree of privacy risk created by the system. Data maps can be illustrated in different ways, and the level of detail may vary based on the mission and business needs of the organization. The data map may be an overlay of any system design artifact that the organization is using. The development of this map may necessitate coordination between the privacy and security programs regarding the covered data actions and the components that are identified as part of the system.
From control text to operational evidence
Use Data Action Mapping as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to secure baselines, controlled change, configuration visibility, and drift management.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- approved baseline configurations
- change tickets and approvals
- configuration scans and drift reports
- software and hardware inventories
Common failure patterns
- baselines documented but not enforced
- emergency changes never reconciled
- asset inventories that omit cloud or ephemeral resources
- security-impact analysis performed after deployment
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
a map of system data actions is developed and documented.
Examine
- Configuration management policy
- procedures for identification and documentation of information location
- procedures for mapping data actions
- configuration management plan
- system security plan
- privacy plan
- system design documentation
- PII inventory documentation
- data mapping documentation
- change control records
- system component inventory
- other relevant documents or records
Interview
- Organizational personnel with responsibilities for managing information location
- organizational personnel responsible for data action mapping
- organizational personnel with information security and privacy responsibilities
- system/network administrators
- system developers
Test
- Organizational processes governing information location
- mechanisms supporting or implementing data action mapping
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.