What CM-12 information location asks you to prove about your data
When an assessor or a contract asks where defined information lives, the honest answer is a documented, current map of where it is processed and stored, which system components hold it, who can reach those components, and how that location has changed over time. CM-12 in NIST SP 800-53 Rev. 5 asks for exactly that. The organization owns the answer. An implementation partner can help build the inventory, the records and the tooling that keep it current, but only the organization can state where its information is, and an independent assessor tests whether the documented answer matches reality. The control does not ask for a perfect data catalog on day one. It asks that the organization can show, for the information it has defined as in scope, where that information sits and who controls access to it.
The risk CM-12 addresses is unknown copies of sensitive data outside the controls the organization thinks apply. Those copies appear in database replicas, backups, log pipelines, analytics exports, SaaS tools, shared drives and developer environments, often created for a short task and never removed. The control is hard because location drifts. A service moves to a new cluster, a backup target changes region, or a team adds a logging agent, and the documented picture stays the same until someone updates it. Ask the system owner to walk through every place a defined data type can land, including recovery copies and non-production environments, and compare that walk against the component inventory maintained under CM-8. Gaps between the two lists are where the finding usually sits.
CM-12 is selected in the moderate and high baselines in SP 800-53B Release 5.2.0 but not in the privacy baseline, so the requirement applies to systems at those impact levels. The enhancement CM-12(1), automated tools to support information location, is also selected in the moderate and high baselines. Confirm with your assessor whether they expect the enhancement to be implemented or whether the organization can justify a manual approach for its environment, and record that decision in the system security and privacy plan. Whichever route you take, the evidence must show the location record is kept current, reviewed when systems change, and traceable to the people responsible for access.
Which systems, data and third parties CM-12 covers
CM-12 is only as complete as the boundary it is drawn around. The decisions below set which information types, components, owners and third-party locations end up in the location record, and they connect to AC-2, AC-3, AC-6, CM-8, PM-5, RA-2, SA-4, SA-8, SA-17 and SC-4, which are scoping context rather than requirements of CM-12 itself.
Defined information types
Start with the information types the organization has already defined as in scope, such as customer records, cardholder data, health data or internal financial files. CM-12 requires the location record to follow those definitions, so a type that is not named in the scope statement tends to be missed. Confirm which types the data classification scheme and any privacy inventory (see PM-5 and RA-2 for context) already name, and record any gaps before mapping locations.
Storage components inside the boundary
Databases, file shares, object stores, backups, log stores and replicas are the components where defined information most often sits unnoticed. Each copy counts as a location, including staging copies and exports. Check whether the component inventory maintained under CM-8 lists these storage points at a level of detail that lets you answer where each information type lives.
Endpoints and portable devices
Laptops, workstations, mobile devices and removable media can hold copies of defined information through synchronization, downloads and local caches. Record which endpoint groups are allowed to hold each information type and which are not. Tools such as an endpoint inventory agent can show where software and hardware are present, but they do not, on their own, show which files hold regulated data.
Owners and users with access
For each location, name the team that owns the component and the groups that can reach the data there. CM-12 asks for the users with access to the systems and components holding the information, so the owner and access lists must be kept together. Access grants traced under AC-2, AC-3 and AC-6 should feed this list, not a separate spreadsheet that drifts over time.
Third-party hosted locations
SaaS platforms, managed backups, outsourced support tools and cloud regions often hold defined information outside the organization's own data centers. Capture the hosting provider, region, subprocessor chain and contractual location commitments for each one. Supplier diligence under SA-4, SA-9 and SA-17 (context only) should supply the facts, and the contract file should confirm them.
Location changes and their triggers
Migrations, region moves, new backup targets and provider changes all change where information is processed and stored, and CM-12 requires those changes to be documented. Tie the location record to change control and impact analysis so that a new storage location cannot go live without an entry. Ask who approves a location change and whether the record is updated before or after the change.
How an assessor tests CM-12 with examine, interview and test methods
An assessor testing CM-12 Information location works from the SP 800-53A procedure for the control, which breaks it into 7 determination statements. Each statement is a yes or no question the assessor must answer with evidence, and the assessor applies the examine, interview and test methods to reach that answer. The organization's job is to have the right documents, people and processes ready for each method, because an assessor cannot infer where information lives from a tool dashboard alone. The 7 determination statements are the checklist to read before preparing anything else.
For the examine method, the assessor reviews documents that describe where defined information is processed and stored. The SP 800-53A examine objects for CM-12 include the configuration management plan, system architecture documentation, PII inventory documentation, data mapping documentation, the list of users with access to systems and components, and change control records. Confirm that these documents agree with one another. A data map that omits a component named in the architecture diagram, or an access list that includes accounts the change records never mention, is the kind of mismatch that generates findings.
For the interview method, the assessor asks personnel who manage information location and user access to explain how the organization knows where defined information resides and who can reach it. The test method examines whether the organizational processes governing information location actually run as written. An assessor may ask for a recent location change and trace it through the change record, the updated architecture documentation and the access list. Before the assessment, run that same trace yourself on one real change and fix any gap you find.
What assessors request for CM-12 and where findings usually come from
This table maps each SP 800-53A assessment method for CM-12 to the objects an assessor asks for, the evidence that satisfies it and the findings that typically follow when the evidence is weak. Read it as a preparation checklist: each row is a place where an assessor will look, and the right-hand column shows where teams usually lose points.
| Assessment method | Evidence requested | Common findings |
|---|---|---|
| Examine: configuration management plan and architecture | Plan sections covering where defined information is processed and stored, plus system architecture diagrams showing the components that hold it | Plan omits information location entirely, or diagrams do not match the components named in the inventory |
| Examine: PII inventory and data mapping documentation | PII inventory listing data elements, system locations and owners, with data maps tracing flows between components | PII inventory does not match the data maps, so a store appears in one record and not the other |
| Examine: list of users with access and change control records | Current list of users with access to each system and component, plus change records showing when location changed | Access lists are not tied to specific locations, or change records do not show location moves |
| Interview: personnel responsible for information location | Named owners who can explain where information sits, how records are kept and who approves a move | Owners cannot describe locations beyond the primary system, or responsibilities are unassigned |
| Interview: personnel responsible for user access to information | Access owners who explain how user access is granted and reviewed for each location | Access reviews cover applications but skip backups, replicas, logs or shared file stores |
| Test: organizational processes governing information location | Walkthrough of the process for recording a new location or changing one, with records from a sample of recent changes | Process exists on paper, but recent changes were made without updating location documentation |
| Test: automated location tooling (CM-12(1), moderate and high baselines) | Evidence that automated discovery or inventory tooling reports locations and that its output is compared with the documented record | Tool output is not reconciled with documentation, or scans cover only part of the environment |
How to implement CM-12 step by step
This sequence turns CM-12 into a living record of where defined information is processed and stored, which components hold it, who can reach those components, and how the record stays current. Each step produces an artifact an assessor can examine and test.
Define the information types in scope
Start by naming the information types the organization has defined for CM-12, such as customer records, payment data, health data or personal data, and agree the boundary of each. The owner is usually the system owner with input from privacy and compliance staff. The step is done when each information type has a written definition, an owner and a link to the system security and privacy plan, so an assessor can see exactly what the location record must cover.
Inventory the components that hold the information
Identify every system component that processes or stores each defined information type, including servers, databases, virtual machines, SaaS tenants, backup targets, endpoints and network devices. This inventory should be aligned with the CM-8 component inventory so the same asset identifiers appear in both records. Your IT or platform team usually produces it, often from an asset management tool such as GLPI or from discovery data. The step is done when each component has an identifier and a list of the information types it holds.
Map processing and storage locations
For each information type, document where it is processed and stored, including physical site, data center, cloud region, network zone and the component that performs each function. Architecture diagrams and data flow records are the usual inputs, and the map should show copies, caches and backups as well as primary stores. The step is done when every information type has a location entry that a reviewer can trace from source to final storage, and gaps are logged as open items with an owner.
Record who has access at each location
For each location, record the users, administrators, service accounts and external parties that can reach the information or the components that hold it. Pull the access lists from directory groups, system role assignments and privileged access records, then reconcile them with the account management process in AC-2. The step is done when each location has a current access list with the date it was generated and a named owner who confirms it, which is the evidence CM-12 assessors look for in the list of users with system and component access.
Define the change trigger that updates the record
Define which events require the location record to be updated, such as a new cloud region, a migration, a new SaaS integration, a new backup destination or a change in hosting provider. Link these triggers to the change control process in CM-3 and the impact analysis in CM-4, so a change request cannot close without a location update. The step is done when the triggers appear in the change procedure with a named approver, and a sample change record shows the location entry was revised before the change was marked complete.
Set review cadence and automated tooling
Set a periodic review of the location record and agree the review frequency with the system owner, based on the organization's own risk management process. For moderate and high baselines, which select the CM-12(1) enhancement for automated tools, evaluate tooling that discovers or reports where information resides and who can access it, and document how those tools feed the record. Confirm each tool's capabilities against its own documentation in your environment. The step is done when the review is recorded with its date and reviewer, and the automated outputs are retained as evidence for the next assessment.
What the CM-12(1) automated tools enhancement adds at moderate and high
CM-12(1) is the automated tools enhancement to CM-12 Information location. It is selected in the moderate and high security control baselines in SP 800-53B Release 5.2.0, and not in the low baseline or the privacy baseline. At those impact levels, the base requirement to document where defined information is processed and stored, on which components, who can reach them, and how that location changes is no longer enough on its own. The organization must also use automated tools to support that location tracking. Confirm your baseline selection against your own system categorization before planning work, because the enhancement only applies where your system is categorized moderate or high.
In practice, automation usually means three things working together: discovery tools that find where data sits on servers, endpoints and cloud storage, tagging or classification that marks which components hold defined information, and inventory feeds that keep the location record current. Many organizations link these feeds to their data maps and to the component inventory described under CM-8, so that a new database or storage bucket appears in the location record without someone updating a spreadsheet by hand. The control does not name specific products. Confirm tool coverage against your own environment: list each repository, SaaS application and backup target that holds defined information, and check that every one is reached by a discovery or inventory source. Gaps in that list are where assessors will look first.
An assessor will still want to see that the tools' output is reviewed and retained. Ask for the discovery scope and schedule, the criteria used to tag or classify components, and records showing that a person reviewed exceptions, such as unknown locations or data found outside approved components, and decided what to do about them. Keep dated exports or snapshots of the location record so that the state of the system at any assessment point can be shown, and keep records of location changes so the history is traceable. Automated output that nobody reviews and nobody can reproduce is weak evidence, even when the tool itself is well configured. An independent assessor decides whether the evidence satisfies the enhancement. The organization owns the process, and an implementation partner can prepare the tooling and evidence collection but does not issue the assessment.
Evidence that passes a CM-12 test and how to keep it current
An assessor testing CM-12 looks for a documented, current answer to where defined information lives, which components hold it, who can reach those components, and how moves were approved. The cards below cover the artifacts that answer those questions and the routine that keeps each one accurate between assessments.
Information location register
This is the core artifact: a register listing each category of defined information, the system components that process or store it, the locations (regions, data centers, cloud accounts, backup sets) and the owner. Check that every entry traces to a component in the inventory and that the register names the information types your SP 800-53 plan defines, not only the ones that are easy to find. Review it on a set schedule and after any migration, since a stale register is the most common gap an assessor finds.
Architecture and data flow diagrams
Diagrams show how information moves between components, including replication, backup, logging pipelines and administrative paths. Assessors use them to test whether the register is complete, so trace one data class end to end and confirm every hop appears. Store diagrams under version control with a date and author on each revision, and tie each revision to the change record that caused it.
Component inventory extracts
Inventory exports from your asset tracker or endpoint agent prove that the components named in the register exist, are running and are listed under the right location. Pull extracts on a fixed cadence, filter them by the location tags used in the register, and reconcile the counts. Mismatches between the inventory and the register usually mean an unregistered component or an untracked move, and both need a documented resolution.
Access lists per location
For each location in the register, keep a list of the accounts and groups that can reach the systems and components holding the information, with the role that grants access. Assessors compare these lists against the access control records, so confirm that privileged and service accounts appear and that departed staff have been removed. Recertify the lists on a fixed cadence and record who approved each recertification.
Change records for location moves
Any change that moves defined information to a new region, provider, data center or component should produce a change ticket with the impact analysis, approval and implementation date. Assessors sample these records to confirm that location changes were reviewed before they happened and that the register was updated afterward. Keep the register update inside the same change workflow so that no move can close without a matching register entry.
PII inventory cross-reference and sign-off
Where the defined information includes personally identifiable information, cross-reference each register entry to the PII inventory and data mapping documentation the organization already keeps. Record a named reviewer's sign-off on the cross-reference at a defined frequency, so the assessor can see who confirmed that the locations still match the PII records. Ask your privacy lead to confirm which location entries drive notices or retention rules.
What meeting CM-12 costs in money and effort
This table breaks the cost of meeting CM-12 into its components, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. No figures are given because none were supplied, so request quotes from a written scope and compare line items on the same basis.
| Cost component | One-time or recurring, and who is paid | Cost drivers and how to reduce them |
|---|---|---|
| Data discovery and location mapping | One-time for the initial map, then recurring when systems change. Paid to internal staff, with optional implementation partner time. | Number of systems, data stores and locations holding defined information. Reduce by starting from existing architecture and PII inventory documents and scoping to the defined information types first. |
| Tooling or licenses | Recurring where commercial. Self-hosted open-source platforms such as GLPI, Wazuh and XWiki or BookStack remove license spend but not hosting or staff time. | Commercial license tier, user count and endpoint count. Reduce by confirming which open-source tools cover the inventory and documentation needs before buying. |
| Engineering time to link inventories | One-time for integration, recurring for maintenance. Paid to platform or security engineers, internal or through a fixed-scope partner engagement. | Number of inventory sources that must be matched to access lists and data maps, and whether identifiers are consistent. Reduce by agreeing naming and asset identifiers early. |
| Ongoing evidence upkeep | Recurring. Paid to internal owners who review location records and change records on a defined schedule. | Frequency of location changes such as cloud migrations, new processors or backups. Reduce with change control that requires a location update as part of approval. |
| External review or testing | Optional and periodic. Paid to an independent assessor or a security testing provider, scoped separately. | Depth of review and number of locations sampled. Ask whether the quote covers only document review or also technical verification of where data resides. |
| Auditor sampling | Recurring per assessment cycle. Paid to the independent assessor, who issues any report. | Number of locations, changes and user access records the assessor selects for testing. Reduce by keeping location records current and traceable to source systems. |
Who owns CM-12: your team, a partner and the auditor
Your organization owns CM-12. The control asks you to identify where defined information is processed and stored, which system components hold it, who can access those components, and how the location changes over time. Those are management decisions about your data and your risk, so they cannot be delegated to a vendor or a consultant. Your security, data governance and system owner roles must agree on what counts as defined information and which locations are approved.
- Defining the information in scope: name the data types, such as customer records or payment data, that the register covers, and confirm them against your data classification scheme.
- Approving locations: decide which systems, regions and hosting arrangements are acceptable for each data type, and record who signed off.
- Owning access decisions: approve who may reach each component that holds the information, and review those lists on your own schedule.
- Approving location changes: route moves between systems, regions or providers through your change control body before they happen.
- Maintaining the register: keep the record current, and assign a named owner who answers for its accuracy.
Before engaging anyone, confirm that you can name the owner of each of these decisions, because an assessor will ask for the person as well as the document.
An implementation partner such as DeployOpen can help prepare the systems and records that CM-12 depends on. Work is defined by a written scope that names the environments, the tools and the deliverables. The partner does not decide where your data may live, does not approve access, and does not sign the register on your behalf. Its role is to make your decisions visible and repeatable.
- Building the inventory feed: configure discovery and inventory tooling so that component records are populated from the systems themselves rather than typed from memory.
- Preparing the register and templates: draft the location register structure, the access list format and the change record template for your review and approval.
- Configuring the records: set up version history, role-based permissions and retention for the wiki, documentation and asset tools that hold the evidence.
- Producing evidence exports: run reports from those tools so your team can show locations, access lists and change history on request.
- Documenting the process: write down how the records are maintained, so the process can continue after the engagement ends.
Confirm in the statement of work which artifacts are delivered, who approves them, and who maintains them after handover.
The independent auditor, assessor or certification body tests CM-12 and reports on whether it is met. That independence is the point of the process. The auditor examines the documents and records, interviews the people who run them, and tests whether the stated process works in practice. Neither the implementation partner nor your own team issues that conclusion.
- Examining the evidence: the assessor reviews your configuration management plan, architecture documentation, data mapping and the access and change records you produce.
- Interviewing staff: the assessor asks the owners of location and access decisions to explain how they work day to day.
- Testing the process: the assessor may sample a recent location change or access grant and trace it through the records.
- Reporting findings: the report and any certificate come from the assessor, not from DeployOpen or from your team.
- Keeping independence: a partner that wrote the register should not also be the party that judges it, so confirm the assessor's independence rules before you hire the partner.
Ask the assessor, before work begins, which evidence it expects and in what form, so that the partner's deliverables match what will be tested.
Most organizations outsource the preparation work for CM-12 and keep the decisions. Preparation includes building discovery tooling, configuring the records systems, drafting templates and collecting evidence. Decisions include approving locations, approving access and approving changes. Assessment is always separate, and it should be contracted directly by you with an independent party.
- Usually outsourced: tool configuration, initial inventory population, template drafting, and evidence exports.
- Usually kept in-house: approval of data locations, access grants, change approvals and the ongoing accuracy of the register.
- Never outsourced to the preparer: the assessment itself, including the conclusion, report and certificate.
- Cost drivers: the number of systems, data types and locations in scope, and how much of the inventory must be built from scratch.
- Ongoing costs: staff time to maintain the register and the access reviews continues after the one-time setup.
When requesting a quote, ask the partner to split the price between one-time setup and recurring support, and ask the assessor to state its fee basis separately.
Where CM-12 programs usually fall short
Most CM-12 gaps are not missing policies. They are location records that drift from reality: a SaaS tool or backup target nobody listed, an access view that cannot be produced per location, or a move that happened without a record update. Each card below names one gap and the check that exposes it.
Shadow SaaS and backups missing
Location records usually list the production servers and miss the places where defined information also lands: SaaS collaboration tools, exported reports, backup repositories and disaster recovery copies. Ask which components hold copies of the defined information, not only which ones run the application. Compare your location register against cloud billing data, identity provider application lists and backup job definitions. Any component found in those sources but absent from the register is a CM-12 finding.
No access view per location
CM-12 covers which users have access to the systems and components where information is stored, not only the list of locations. Many programs hold a user directory and a component list but cannot show who can reach a given location. Produce, for each location, the accounts and groups with access, using exports from the directory and the component's own permission model. A location without a current access list cannot be assessed as documented.
Location changes without record updates
A migration to a new region, a vendor change or a move of a database to a new host often happens through a change ticket that closes without touching the location register. The CM-12 requirement covers changes to where information is processed and stored, so the change record and the location record must agree. Check a sample of recent infrastructure and SaaS changes and confirm each one updated the register before it closed.
PII inventory and data maps disagree
The PII inventory, the data map and the location register each describe the same information, and they often diverge. One lists a processing location the others omit, or a data map shows a flow that no inventory entry explains. Pick one data element with personal information and trace it through all three documents. Where the sources disagree, record which one is authoritative and correct the others on a fixed cycle.
No named owner for locations
When no one owns the location records, they decay quietly. Engineering assumes architecture owns them, architecture assumes the asset team does, and the asset team only sees components enrolled in its tooling. Assign one accountable role for the location register, define who updates it for each type of change, and record that assignment in the configuration management plan. Ask the owner to name the last location change they recorded and when.
CM-12 questions buyers ask before bringing in help
How much effort does CM-12 information location take?
The effort depends mainly on how many systems, components and data flows the organization has to document, and on how current its existing inventories and architecture diagrams already are. CM-12 asks for a record of where defined information is processed and stored, which components hold it, who can access those components, and how the location changes over time. Most of the work is discovery and reconciliation: matching what the architecture documents say against what is actually deployed, including cloud regions, backups, logs and third-party services. A smaller, well-documented environment with a current component inventory needs far less work than a sprawling estate where data moves through many tools. Ask any prospective partner to break the estimate into discovery, documentation, validation and ongoing change tracking, and to state which of those they will do and which the organization must staff.
Can our team handle CM-12 in-house?
Often yes, if the team has someone who knows the data flows and access model, and if the inventory tooling is already in place. The organization always owns its controls, so internal staff must be accountable for the location record, its approval and its upkeep. The harder part is sustaining the record after launch: every new cloud service, data store or migration changes the answer, and CM-12 expects changes to location to be captured. Teams that struggle usually lack an owner for the record, not technical skill. Before deciding, check whether you can name an accountable owner, whether change requests already reference the systems they affect, and whether someone can keep the record current without a separate project each quarter.
What does a implementation partner need from us for CM-12?
A partner needs access to the people and records that describe your environment, and clear decisions about scope. Typical inputs include the system architecture documentation, the configuration management plan, data mapping or PII inventory documents, lists of users with access to systems and components, and recent change control records. The partner also needs named contacts who can explain how data moves and who approves changes. In a fixed-scope engagement, these inputs and the systems in scope are agreed in writing before work starts, so gaps in access or documentation should be raised during scoping rather than mid-project. Ask the partner to list every input it requires and the date by which you must provide each one.
How long does a CM-12 project take?
No duration is fixed for CM-12, so the timeline should be agreed in the written scope rather than assumed from a template. The main drivers are the number of in-scope systems, how well existing inventories match reality, how many people must be interviewed, and whether the organization must first agree on what counts as defined information and its locations. Access reviews and change approval cycles also set the pace. Ask the partner to show the phases, the dependencies on your staff and the points where your approval is required, and to state what happens if discovery reveals undocumented systems. A timeline that does not reference those dependencies is not yet a plan.
Can a consultant or partner issue the CM-12 assessment?
No. A partner can prepare the systems, documentation and evidence that CM-12 requires, but it cannot issue an assessment result, report or certification. Assessments under SP 800-53 are performed against the SP 800-53A procedures by the organization's own assessment function or by an independent assessor, depending on the program. The assessor will examine documents such as the architecture documentation and access lists, interview the personnel responsible for information location and user access, and test whether the organizational processes actually operate. Keep the roles separate in your contract: the organization owns the control, the partner prepares the evidence, and the assessor reaches the conclusion.
Does CM-12 apply to low baseline systems?
Based on the SP 800-53B Release 5.2.0 baseline selections, CM-12 is part of the moderate and high baselines but is not selected for the low baseline or the privacy baseline. That selection governs the required controls for a system at a given impact level, so a low-impact system would not be assessed against CM-12 under the baseline alone. Your contract, authorizing official, or overlay may still require it, and good practice may justify documenting locations anyway. Confirm the impact categorization of each system and the baseline your agreement cites before scoping, because a mistaken impact level changes the effort more than any other single decision.
Which tools help produce CM-12 evidence?
Tools help with discovery and with keeping a record current, but they do not decide what counts as compliant. An asset management system such as GLPI can hold the component records, and its Assets module is documented to track computers, network equipment and other hardware, populated manually or by its agent. Wazuh's Syscollector module can collect hardware, operating system, software and user details from endpoints for inventory views and reports. A wiki such as XWiki keeps version history of the location documentation, showing what changed, when and by whom, while BookStack's role-based permissions can help document who can view or edit that content. Confirm each tool's coverage against your own environment, especially cloud services and data stores that agents cannot reach.
Self-hosted tools that produce CM-12 location and access evidence
Four self-hosted open-source platforms can each produce part of the CM-12 evidence set, but none of them documents information location on its own. The organization still has to decide which records answer the location question and who keeps them current. GLPI Assets, licensed under GPL-3.0-or-later, manages computers, monitors, software, network equipment, peripherals, printers, phones and racks. Native inventory built into GLPI since version 10, fed by the GLPI Agent, can populate those asset records automatically, which gives the assessor a component list tied to physical or virtual location fields that the organization defines.
Wazuh, licensed under GPL-2.0-only, adds an independent view of where the system components actually are and what they hold. Its Syscollector module collects hardware, operating system, installed software, network interfaces, running services, users and groups from each endpoint and stores the results in the Wazuh indexer, where dashboard views and reports can show them. Confirm that the endpoints you need are enrolled, that collection covers the components in your boundary, and that the user and group data matches your access list for the systems that store the information. Comparing the two inventories often exposes components that appear in one source but not the other.
XWiki (LGPL-2.1-or-later) and BookStack (MIT) hold the narrative location records. XWiki keeps every change to a page under version control, recording what changed, when and by whom, so a dated history of location changes is available for review. BookStack assigns abilities through roles and lets permissions be overridden per role at the shelf, book, chapter or page level, which can show who may view or edit location documentation. Confirm how role overrides are configured in your instance and export the permission view for the assessor. Neither wiki records system behavior, so treat them as the documented intent that the inventory and telemetry must support.
How DeployOpen prepares CM-12 location records and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the location records for CM-12 are built from the systems you actually run. We prepare the inventory, access and change records that an assessor will examine, while your organization keeps ownership of the control and independent assessors issue any report.
How we scope
- Engagements are fixed-scope, with the CM-12 boundary agreed in writing before work starts.
- We confirm which information types, such as PII inventories and data mappings, fall under CM-12 for your system.
- The written scope names the components, hosting locations and user populations whose location records we will prepare.
How we build
- We deploy an asset register such as GLPI and link each processing or storage component to its owning system record.
- We configure Wazuh Syscollector inventory on endpoints so hardware, software and services are recorded from the source.
- We set up role-based access in the tools that hold location records so the list of users with access can be exported and reviewed.
How we hand over
- We deliver a location register, system architecture diagrams and data flow documentation that match the examined components.
- We document the change process for moving information to a new location, including approval and update of the records.
- We hand over a walkthrough of the evidence set so your personnel can explain the records to an assessor during interviews.
How we support
- Ongoing support is available as a retainer for keeping location records current after infrastructure changes.
- We can review the records at a cadence your organization sets, and update them after hosting or component changes.
- Retainers can include periodic reviews of access lists and location changes ahead of your next assessment.
