CM-12: Information Location

Quick-reference card

What this control requires

CM-12 requires organizations to identify, document, and continuously track where sensitive information lives and who can access it. That single sentence masks a deceptively large operational challenge. Most organizations can name their crown-jewel databases but can’t tell you which middleware server cached a copy of that data last Tuesday.

The control breaks into three obligations. First, you must map the location of organization-defined information to the specific system components that process and store it. Second, you must identify and document every user with access to those components. Third, you must track changes whenever information moves to a new system or component.

The intent isn’t bureaucratic record-keeping. It’s ensuring that protection follows the data, not just the perimeter. Without a current picture of where information resides, security categorization decisions under Federal Information Processing Standard 199 (FIPS 199) become guesswork, and access controls can’t be scoped accurately.

In practice, this means your data mapping documentation, system component inventory, and access lists need to stay synchronized as your environment changes. Static spreadsheets created during initial authorization rarely survive the first cloud migration or SaaS onboarding intact.

Why it matters

The gap between where organizations think their data lives and where it actually lives is the root cause of an entire class of security failures. CM-12 exists because untracked information creates unprotected information — and unprotected information is what attackers find first.

When sensitive data drifts to systems outside your documented inventory, the controls you’ve carefully implemented around your known assets become irrelevant. A personally identifiable information (PII) dataset replicated to a development environment bypasses every production safeguard you built. A vendor integration that caches customer records in a staging bucket sits outside your monitoring scope. These aren’t hypothetical scenarios. They’re a common pattern auditors encounter during assessment fieldwork.

Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. For organizations subject to privacy regulations like GDPR or the California Consumer Privacy Act, the inability to demonstrate where personal data resides and who accesses it creates direct legal exposure. Auditors checking NIST SP 800-53 compliance will specifically look for evidence that information location documentation stays current, not just that it existed at some point.

What attackers exploit

• Shadow data stores: copies of sensitive data in unmonitored development, staging, or analytics environments
• Orphaned system components: decommissioned servers or cloud instances still holding data but removed from inventory
• Undocumented data flows: information moving between systems through integrations, APIs, or batch processes without change tracking
• Excessive access persistence: users retaining access to data locations after role changes because access documentation wasn’t updated
• Cloud sprawl: data distributed across multiple cloud regions or SaaS platforms without centralized location tracking

How to implement

The most common failure mode isn’t refusing to document information location. It’s treating the exercise as a one-time compliance activity rather than an ongoing operational capability. Organizations that build their data map during authorization and never update it will fail their next assessment.

For your organization

Step 1: Define what information you’re tracking. CM-12 applies to “organization-defined information,” which means you decide the scope. At minimum, include data classified at moderate or high impact under FIPS 199: PII, financial records, authentication credentials, intellectual property, and any data subject to regulatory requirements.

Step 2: Build and maintain your data map. Document where each information type is processed and stored, down to specific system components. This means server names, database instances, cloud storage buckets, and SaaS application identifiers, not just “the production environment.” Link this to your system component inventory (CM-08) so location data stays anchored to real infrastructure.

Step 3: Document access by user. For each system component where tracked information resides, record which users have access and at what privilege level. This connects directly to your account management (AC-02) and least privilege (AC-06) programs.

Step 4: Establish change tracking. Implement a process to capture when information moves between systems. This could be a change control record tied to your configuration management process, an automated alert from a data loss prevention tool, or a required field in your change advisory board workflow.

Step 5: Automate where possible. Manual data maps decay quickly. Data discovery and classification tools, configuration management databases, and cloud security posture management platforms can detect information location changes in near-real time. CM-12(1) specifically calls for automated tools in moderate and high baselines.

Common mistakes:

• Documenting information location at the application level instead of the component level
• Treating the data map as a static document rather than a living record
• Omitting temporary or cached copies of data (staging environments, backup locations, analytics replicas)
• Failing to update location records when systems are migrated or decommissioned
• Not connecting information location tracking to the change management process

For your vendors

What to ask in a security questionnaire:

• How do you document the location of customer data within your infrastructure?
• Can you provide a current data flow diagram showing where our data is processed and stored?
• What process do you follow to update data location documentation when systems change?
• Who within your organization has access to the systems where our data resides?
• Do you use automated tools to discover and classify information across your environment?

What evidence to request:

• Data mapping documentation or data flow diagrams specific to your data
• System component inventory showing where your information is processed
• Access control lists for systems handling your data
• Change control records demonstrating that data location changes are tracked
• Most recent audit or assessment results covering CM-12

Red flags:

• The vendor cannot specify which systems process your data beyond naming a cloud provider
• Data flow diagrams are dated more than 12 months ago with no evidence of updates
• The vendor has no automated discovery capability despite operating in a complex or multi-cloud environment
• Access documentation is missing or incomplete for systems handling your information assets
• No change management process connects infrastructure changes to data location updates

Evidence examples

Cross-framework mapping

Related controls

• AC-02, Account Management: Defines and manages user accounts, providing the identity layer that CM-12’s access documentation depends on.
• AC-03, Access Enforcement: Enforces the access policies that CM-12 documents, ensuring only authorized users reach information locations.
• AC-04, Information Flow Enforcement: Controls how information moves between systems, directly supporting CM-12’s requirement to track location changes.
• AC-06, Least Privilege: Limits user access to the minimum necessary, reducing the scope of access that CM-12 must document.
• AC-23, Data Mining Protection: Protects against unauthorized extraction of information from documented locations.
• CM-08, System Component Inventory: Maintains the component-level inventory that CM-12 maps information to. The two controls are operationally inseparable.
• PM-05, System Inventory: Provides the system-level view that CM-12’s component-level tracking rolls up into.
• RA-02, Security Categorization: Determines the security category of information, which drives which information types fall under CM-12’s scope.
• SA-04, Acquisition Process: Ensures new system components acquired through procurement include information location requirements.
• SA-08, Security and Privacy Engineering Principles: Guides system architecture decisions that affect where information is processed and stored.

Frequently asked questions

What is NIST SP 800-53 CM-12

CM-12 requires organizations to identify and document where specific information types are processed and stored, which users can access those locations, and any changes to where that information resides. The control applies to moderate and high baselines in NIST SP 800-53 Revision 5 and sits within the Configuration Management family. Unlike broader inventory controls like CM-08 (which tracks system components), CM-12 focuses specifically on the relationship between information and infrastructure. You need to know not just what systems you have, but what data lives on each one and who can reach it.

What happens if CM-12 is not implemented

Without CM-12, organizations lose visibility into where sensitive information actually resides, creating blind spots that undermine every downstream security control. Access controls can’t be scoped accurately if you don’t know which systems hold the data, and incident response teams can’t contain a breach if they can’t identify all locations where compromised data was processed or stored. From an audit perspective, missing CM-12 documentation signals a systemic gap in configuration management maturity, and assessors will question whether the organization can demonstrate compliance with related controls like AC-02, AC-06, and CM-08 if the foundational data mapping is absent. For organizations handling PII, the inability to locate personal data on demand creates direct exposure under GDPR Article 30 and similar regulations.

How do you audit CM-12

Auditors assess CM-12 by examining data mapping documentation, PII inventories, system component inventories, and user access lists to verify that information locations are identified and current. They compare documented locations against actual system configurations to detect drift, including systems processing data that aren’t in the inventory or documented locations that no longer exist. Assessors also review change control records and interview system administrators to confirm that processes exist for updating location documentation when infrastructure changes occur. Where automated discovery tools are deployed, they test whether those tools identify information types on the system components specified in the organization’s scope.

What is the difference between CM-12 and CM-08

CM-08 (System Component Inventory) tracks the hardware, software, and firmware components in your environment, while CM-12 tracks where specific information types reside on those components and who can access them. Think of CM-08 as your infrastructure map and CM-12 as the data overlay on top of it. You can have a complete component inventory and still fail CM-12 if you haven’t documented which data lives on which components. The two controls are operationally linked because CM-12’s information location records reference the component identifiers that CM-08 maintains.