What 03.04.11 information location asks you to prove about CUI
03.04.11 Information location requires you to identify and document where CUI is processed and stored, which system components hold it, and any changes to those locations. In a Rev. 3 contract or assessment, the assessor will expect a current answer to a simple question: where does the CUI in this environment actually live? Your organization owns the answer. An implementation partner can help you build the inventory, map the flows and set up the records, but only the independent assessor (or the DoD assessment process, where it applies) judges whether the evidence holds up. The risk is rarely the main file server. It is the copies nobody counted: a spreadsheet exported to a laptop, a shared drive synced to a personal cloud account, a ticket attachment in an unmanaged SaaS tool, a backup set in a second region, or a log export sent to a vendor. Each one is a component that processes or stores CUI and falls outside your system boundary if nobody recorded it. NIST added this requirement in Rev. 3 and tied its source control to CM-12 in SP 800-53 Rev. 5, which covers information location. Because Rev. 2 has no matching requirement, a team that only tracked Rev. 2 controls will find no existing record to point to. The work is hard for three reasons: CUI is often not labeled in the systems where it sits, staff move files without thinking about it, and the component inventory (03.04.10) and access records must agree with the location records. The assessment procedure in SP 800-171A Rev. 3 for this requirement has five determination statements, assessed through examining documents, interviewing people and testing the processes that govern information location. In plain terms, the assessor will look for a written policy and plan that explain how CUI locations are identified and recorded, check that the records exist and match what they found in the environment, ask the people who run and use the system whether the records are right, and test whether a change in location is documented when it happens. Confirm the exact wording of each determination statement in the NIST assessment publication before you build your evidence list, since the examine, interview and test objects are the reference for what to produce.
Which systems, data flows and third parties fall under information location
Information location is only as complete as the list of places CUI actually lives. The cards below cover the repositories, endpoints, tenants and external parties that belong on that list, and the boundary decisions that decide how many of them an assessor will expect you to document.
CUI repositories and file shares
Start with every place CUI is stored on purpose: document management systems, engineering data vaults, shared drives and ticketing attachments. Record the system, the owning team and the folder or database where CUI resides. Repositories created by staff for convenience, such as a project share or a spreadsheet export, are the usual gap. Ask each data owner where their CUI copies were made and whether any were deleted.
Endpoints and removable media
Laptops, workstations and phones that open CUI hold local copies through downloads, caches, sync clients and printed output. Each device that processes or stores CUI is a component that belongs in the location record, and so are the users who can reach it. Check whether personal devices or unmanaged browsers are allowed to open CUI, because those devices are often left off the list.
Cloud tenants and SaaS collaboration
Email, chat, video recording, wikis and file sync services can hold CUI without anyone designating them as storage. Each tenant, workspace and integration that receives CUI needs an entry, with its administrators and retention settings noted. Confirm with each provider whether it is in scope for your system security plan and which data centers or support access paths apply.
Backups, logs and recovery copies
Backups, snapshots, replicas and disaster recovery sites are copies of CUI in another location, and assessors expect them to be documented. Log stores and monitoring platforms can also capture CUI in event data. List where each copy is kept, how long it is retained and who can restore it. Backup media stored offsite should appear in the same record as primary storage.
Data flows between systems
Information location is more than a list of stores. Map the paths CUI takes between systems, including interfaces, file transfers, API calls, email relays and print or scan jobs. Each hop changes where CUI sits and who can see it, so the flow diagram should match the location register. Flows that cross the system boundary should be tied to the agreements that govern them.
External service providers holding CUI
Any external provider that stores, processes or can access CUI extends your location list, even when the provider runs the infrastructure. Identify each provider, the CUI it holds, the locations it uses and the agreements that set its obligations. Ask providers to confirm where data is hosted and which subcontractors can reach it, since those details are needed to document changes in location.
How an assessor tests 03.04.11 under SP 800-171A Rev. 3
This table maps each assessment method in SP 800-171A Rev. 3 for 03.04.11 to the objects an assessor examines, interviews or tests, and the evidence that usually satisfies it. Read it as a checklist of what to have ready before an assessment, and note the common findings in the last rows, since they show where organizations most often fall short.
| Method or area | What the assessor looks at | Evidence to have ready | Where it usually fails |
|---|---|---|---|
| Examine: policy and procedures | Configuration management policy and procedures that cover how CUI locations are identified and documented | Approved configuration management policy, procedure text, revision history and owner sign-off | Policy names CUI locations in general terms but no procedure says who records them or how often |
| Examine: plan and procedures for information location | The configuration management plan and the procedures for identifying and documenting where CUI is processed and stored | Documented information location procedure, plan section and a current list of CUI-processing components | Procedure exists but does not cover changes, so the list drifts from reality |
| Interview: personnel managing information location | Staff who maintain the location records and decide where CUI may be processed or stored | Named owners, their responsibilities in writing and examples of records they updated | Owners cannot describe how a new cloud service or endpoint is added to the record |
| Interview: personnel managing user access | Administrators who grant access to systems and data holding CUI | Access request records and a description of how access follows the location record | Access team does not know which components hold CUI, so access is not tied to locations |
| Interview: personnel operating or maintaining the system | Operators who deploy, move or back up systems and data | Walkthrough of a recent deployment or migration and how the location record was updated | Operators store CUI in backups, file shares or collaboration tools that are missing from the record |
| Test: processes governing information location | The working process that records locations and reacts to changes, tested against actual system behavior | Sample of inventory entries compared with live system data, change tickets and location update logs | Locations documented once at onboarding but not reviewed after system, vendor or data-flow changes |
| Test: link between CUI locations and access rights | Whether the components listed as holding CUI are the same ones covered by access controls and information flow rules | Mapping of each CUI location to its access roles, with evidence that roles were reviewed after the last change | No link between CUI locations and access rights, so unlisted systems inherit broad access |
| Test: documented changes to locations | Whether each change to a CUI processing or storage location was recorded and approved | Dated change records showing what changed, who approved it and when the location record was updated | Changes made through cloud consoles or vendor tools without a matching record entry |
How to build an information location record that survives an audit
This sequence turns 03.04.11 into a working record: it defines what CUI the boundary covers, finds and maps every component that handles it, ties those locations to the people and paths that reach them, and keeps the record current through a defined change trigger and named review owner.
Define the CUI boundary and data types
Start by agreeing, in writing, which CUI categories the organization receives, creates, or transmits, and which contracts or agreements they come from. Name the system boundary that the record covers, including the enclave if one exists. The business owner and the security lead sign off on this scope. The step is done when a short scope statement lists each CUI type, its source contract, and the boundary it falls inside, and that statement is referenced from the system security plan.
Discover where CUI is processed and stored
Search for CUI across the boundary, using interviews with data owners, a review of business applications, file shares, collaboration tools, email, backups, and removable media, and where possible automated discovery tools. Record each repository as a candidate location, including copies created by sync clients and exports. The output is a raw discovery list. Confirm the list is complete by checking it against the contract deliverables and the data flows the organization already documents.
Map each component and its owner
For every location in the discovery list, identify the system component that hosts it, such as a server, virtual machine, cloud service tenant, endpoint, or storage array, and name a technical owner and a business owner. Pull component identifiers from the configuration management database or the component inventory so the record matches 03.04.10. The output is a location register with one row per component, its CUI data types, its hosting environment, and its owners. A row is complete when someone other than the author can locate the component from the register.
Tie locations to users and access paths
For each registered location, document which roles and accounts can read, write, or administer the CUI, and the paths they use to reach it, such as a direct console session, a remote access gateway, a sync client, or an API. Export the access lists from the directory and application platforms rather than relying on memory. This connects the register to the access control and information flow records. The check is that every location has a current access list and every access path appears in the boundary diagram.
Set the change trigger for updating the record
Write down the events that require a change to the register before the change goes live. Typical triggers include a new or retired component, a new CUI repository, a change of hosting provider or region, a new integration, and a change to who can access a location. Link each trigger to the change control process so that a change request cannot close without a register update. The output is a short trigger procedure that the change board and the system owners both acknowledge.
Assign review ownership and record cadence
Name one accountable owner for the register and a backup, and decide how often a full review happens and what evidence it leaves behind. The review should reconcile the register against the component inventory, the access lists, and the boundary diagram. Confirm the review frequency in the organization's own policy, since the requirement leaves that choice to the organization and any federal agency may set parameters. The output is a signed review record, with the date, reviewer, discrepancies found, and corrections made.
Store the record where auditors can test it
Keep the register, the trigger procedure, and the review records in a controlled, versioned location so that an assessor can see history, not just the current state. A wiki with version history or a document management system with access control can serve this purpose, and the organization should confirm that the chosen platform keeps prior versions and restricts edits to named owners. Cross-reference the record from the system security plan. The step is complete when an assessor can trace a single CUI location from the policy to the component, the access list, and the change history.
Using GLPI, Wazuh, XWiki and BookStack to keep location evidence current
GLPI's Assets module is a natural place to hold the component records that 03.04.11 depends on. It tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks, and records can be entered by hand or pushed automatically by the GLPI Agent, which uses native inventory built into GLPI since version 10. Each asset record can then be linked to the location, owner and purpose of the system it belongs to, so an assessor can see which components sit in the CUI boundary.
- Manual entry: Staff add records for assets that cannot run an agent, such as network appliances, racks and printers in a secure room.
- Agent-based inventory: The GLPI Agent pushes hardware and software data, which reduces drift between the record and the real device.
- Location fields: Use site, room and rack fields to show where each CUI-handling component physically resides.
- Change history: Update records when hardware moves or is retired, and keep the record of who made the change.
Before relying on GLPI for an assessment, confirm which asset fields your version provides and how inventory is scheduled in your environment.
The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each monitored endpoint. The data is stored in the Wazuh indexer and shown in inventory views and reports in the dashboard. This gives the security team an independent view of what is actually running on endpoints, which can be compared with the records kept elsewhere.
- Hardware and software: Syscollector reports what each endpoint has installed, which helps confirm that recorded components match reality.
- Network exposure: Open ports and network interfaces show where a system connects, which supports the question of where CUI can travel.
- Services and accounts: Running services, users and groups show who can reach the data on a system.
- Reports: Inventory views can be exported or reviewed on a schedule for assessment files.
Confirm which endpoints run the Wazuh agent and whether servers, network devices and cloud resources are covered, since Syscollector only reports from systems where the agent is installed.
XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For 03.04.11, this makes a wiki page describing the CUI locations a usable record of how those locations changed over time, which supports the requirement to document changes to where CUI is processed and stored.
- Location register: Keep one page per system or data store that lists the components holding CUI and their locations.
- Change trail: Each edit shows the author and timestamp, which provides the who and when for each location change.
- Comparison: Diff views let an assessor see exactly what moved, was added or was removed.
- Rollback: Restore a prior version if an edit is found to be wrong, while keeping the bad version in the history.
The wiki records what people wrote, not what is true, so pair each change entry with a reference to the ticket or approval that authorized it.
BookStack controls who can read and edit documentation through roles. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. This matters for location records, because the documents that show where CUI sits are themselves sensitive and should only be visible to people with a need to know.
- Role design: Create roles such as location record editors and read-only auditors, then assign users to them.
- Granular overrides: Restrict a single book or page that describes a CUI enclave while leaving general procedures open.
- Shelf structure: Group location records, change procedures and evidence under shelves that match the system boundary.
- Access review: Export role assignments and permission settings for periodic review of who can see location information.
Confirm the permission model in the version you run and test a restricted page with an account that holds only the intended role before the evidence is shared.
Which evidence artifacts pass 03.04.11
An assessor testing 03.04.11 looks for a records set that shows where CUI lives, which components hold it, who can reach it, and how changes to those locations were approved. The artifacts below connect to each other, so one update to a system or a role should flow through all of them rather than being rebuilt at audit time.
CUI location register
This is the core record: a list of each system, repository, backup and endpoint type where CUI is processed or stored, with the data owner and the reason the location holds CUI. Assessors compare it against what they see in the environment, so an entry missing from the register is the most common gap. Keep one owner for the register and tie each row to a system security plan identifier. Review it at each change window and after any new integration, not once a year.
Component inventory extracts
Inventory exports show which hardware, operating systems, software and network interfaces exist on each system that holds CUI. Pull them from the tools that already run in the environment instead of maintaining a separate spreadsheet. Check that every CUI row in the register maps to at least one inventoried asset, and that retired assets are removed with a date. Ask the assessor which extract format and filters they expect before the review.
Data flow diagrams
Data flow diagrams show how CUI moves between components, including ingress points, internal transfers, backup copies and outbound exchanges to external services. They give the assessor a way to verify that the register is complete, because any arrow that leaves the documented boundary is a location that needs an entry. Label each flow with the protocol and the storage endpoint. Update the diagram in the same change record that adds a new connection.
Change records for location updates
When a system or component that processes CUI is added, moved, replaced or decommissioned, the change record should state which location entry changed and why. Assessors look for this link between the configuration change process and the location documentation. Make the location update a required field in the change template so it cannot be skipped. Keep a version history of the register so you can show what the location picture looked like on a given date.
Access role mappings
Because 03.04.11 ties location to knowing which users can reach CUI, an assessor will ask for a mapping from each CUI location to the roles that have access to it. Export the roles from the directory or application and record which ones grant read or write rights on each location. Review the mapping whenever a role is created or changed, and remove roles that no longer have a documented business need. A stale mapping suggests the location record is not being maintained.
Policy, plan and sign-off records
The register, diagrams and mappings should cite the configuration management policy, the configuration management plan and the procedure for documenting information location. Each review should carry a dated sign-off by the named owner, showing who reviewed the artifacts and what changed. Store these in a versioned wiki so the history of edits and approvals is visible without extra work. Confirm the review frequency with your assessor and your contract, because the requirement does not fix one for you.
What meeting 03.04.11 costs in effort and tooling
This table breaks down the cost components of meeting 03.04.11 Information location, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written scope and to compare quotes on like-for-like terms. No figures are given because none are supplied for this requirement; ask each provider for estimates tied to your own environment.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it |
|---|---|---|---|
| Discovery and CUI data mapping | Your staff with an implementation partner or consultant | One-time, then revisited on change | Number of repositories, file shares, collaboration tools and business units handling CUI |
| Asset and component inventory setup | Implementation partner or internal platform team | One-time setup, recurring upkeep | Number of endpoints, cloud accounts, servers, network devices and mobile devices in scope |
| Open-source tooling licensing | No license fee for GPL, MIT or LGPL components; hosting and staff time still apply | Recurring hosting and maintenance | Infrastructure size, retention needs and whether tools run in air-gapped or enclave networks |
| Configuration and integration engineering | Implementation partner or internal engineers | One-time, with later upgrades | Connections to identity, ticketing, cloud APIs and existing CMDB or asset records |
| Documentation of location changes | Asset owners, change managers and security staff | Recurring with every system or data flow change | Frequency of system changes, cloud migrations and third-party onboarding |
| Third-party and external service mapping | Your procurement and security teams, with provider input | Recurring as vendors change | Count of third parties that store, process or can access CUI, and contract flow-down terms |
| Independent review of the evidence | Your internal reviewer or an external assessor, paid by you | Recurring at each assessment cycle | Scope size, sampling depth set by the assessor and number of locations covered |
| Assessor sampling and evidence requests | Assessor fees paid by you | Recurring per assessment | How consistently records match reality, and how quickly evidence can be produced on request |
Who owns the location record: your team, a partner and the assessor
Three parties touch the information location record, and each has a different job. Your organization owns the decision about where CUI lives and who approves changes. An implementation partner can prepare discovery, records and tool configuration, while only an independent assessor issues results. NIST places compliance responsibility on the federal agency that holds the contract, so the contract is the starting point for every role below.
Ownership of the location decision
Your organization decides which systems and components may process or store CUI, and that decision belongs to a named person with authority over the system boundary. 03.04.11 expects you to know where CUI sits and to document changes to those locations. A partner can draft the record, but an internal owner should sign off on every entry, every new location and every move. Check that the owner can explain why each location is approved, not only where it is.
Initial discovery as a partner task
Discovery is the work most often outsourced: tracing where CUI enters, is processed, is stored and is backed up across endpoints, servers, cloud accounts, email and collaboration tools. A partner with hands-on access can run this against your environment and produce a first draft of the location record. Ask for the method, the data sources used and a list of anything found but not yet confirmed by your staff. Discovery results should be reviewed by the people who run those systems.
Tool setup and record keeping
Inventory and documentation tools can hold the location record, but they only help if they are configured to reflect your CUI boundary. GLPI's Assets module can record computers, software, network equipment and racks, and Wazuh's Syscollector can gather endpoint hardware and software data for inventory reports. A partner can configure these tools and link them to a documented location register, which your team then maintains. Confirm which fields your team will update and who reviews the output.
Change approvals stay in-house
Under 03.04.11, changes to where CUI is processed or stored must be documented. Approving those changes is an internal control, so the approval workflow, the approver list and the review cadence should stay with your staff. A partner can build the form, the ticket path or the wiki page that captures each change, but should not be the party that signs off on it. Ask who can approve a move of CUI to a new cloud region or a new endpoint type, and make sure that person is named in your procedures.
Version history as audit trail
A location record is only credible if its history can be shown. Wiki platforms that keep version history can show what changed, when and by whom, and let reviewers compare versions. XWiki keeps every page change under version control and allows rollback, which suits a location register that assessors may ask to see over time. Confirm that access to the wiki is limited to people who need it, since the register itself describes where CUI lives.
The assessor issues the results
An independent assessor examines the location record, interviews the people who manage it and tests whether the process works, using the SP 800-171A Rev. 3 procedures for 03.04.11. Neither your partner nor your team can issue an assessment result for this requirement. Before the assessment, confirm with the contracting agency which assessment path applies, since the federal agency holding the contract is responsible for how compliance is checked. Ask the assessor which evidence they expect to see for each determination statement.
Questions buyers ask about 03.04.11 cost, effort and scope
How much effort does 03.04.11 information location take to implement?
The effort depends mainly on how many systems, data stores and component types hold CUI, and on whether anyone has already recorded where that data lives. No researched figure for hours or duration is available for this requirement, so treat any number you hear as unverified until a written scope confirms it. The work breaks into three parts: identifying every system component that processes or stores CUI, documenting those locations in a maintained record, and setting a procedure that records every later move or change. A small, single-enclave environment with a current asset inventory is a much shorter exercise than a multi-site organization whose CUI is spread across email, file shares, SaaS tools and endpoints. Ask the partner to show how they will count systems and data flows before agreeing to any timeline.
Can we do 03.04.11 information location in-house?
Yes, many organizations do this internally, because the requirement is a documentation and tracking discipline rather than a specialist technical control. The work needs people who know the CUI data flows, administrators who can confirm which components hold CUI, and an owner who keeps the record current. Organizations usually bring in outside help when the CUI boundary is unclear, when the environment has many shadow systems, or when internal staff lack time to map it. Whichever route you choose, the organization owns its controls. An implementation partner can prepare the inventory, the records and the evidence, but only an independent assessor issues assessment results, and the organization must still answer for the requirement under its contract.
What does information location need from our staff?
The requirement needs three kinds of people: those who understand where CUI moves, those who operate and administer the systems, and those who manage user access. SP 800-171A Rev. 3 looks for interviews with personnel responsible for managing information location and user access, and with personnel who operate, use or maintain the system, so these roles must be able to explain the setup consistently. Expect to name a single accountable owner, give administrators a routine for logging changes, and train staff to notify that owner when a file share, cloud tenant or device changes. Staff who can answer assessor questions from the same record are more valuable than a long document nobody reads.
Why does CMMC Level 2 have no matching ID for 03.04.11?
CMMC Level 2 assesses the 110 requirements of NIST SP 800-171 Rev. 2, and 03.04.11 is one of 19 requirements that NIST added in Rev. 3. NIST's change analysis maps no Rev. 2 requirement to it, so the CMMC Level 2 practice set has no matching identifier. The federal rule under 32 CFR Part 170 makes the Level 2 requirements identical to Rev. 2, which is why DoD contractors assessed at that level are not tested on information location as a separate item. Organizations should not read the absence as permission to skip the work, because contracts and future baselines may reference Rev. 3, and the same data-location knowledge supports other Rev. 2 requirements. Confirm with your contracting officer which version governs your award.
How does DoW Class Deviation 2026-O0025 affect our Rev. 2 baseline work?
The deviation directs contracting officers to use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly, and it cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. For most current DoD contracts, the Rev. 2 work is therefore the priority, and 03.04.11 is not part of that baseline. Keep the Rev. 3 information location record as a separate, optional workstream unless your contract or contracting officer says otherwise. Note that a FAR overhaul proposed rule would move contractors to Rev. 3 with ODP values published by the DoW CIO, and that rule was not final as of October 2026, so plan the record now and confirm its status with your contracting officer.
What drives the cost of information location up or down?
Cost follows scope and state of your records. The main drivers are the number of systems and locations that may hold CUI, the number of CUI data flows between them, how many third-party services are involved, and whether a current asset inventory already exists. Costs are one-time for the initial mapping and recur for maintenance, because every new system, migration or change must update the record. Internal labor is usually the largest component if you do the work yourself. If you hire a partner, the price is set by the written scope, not by a list rate, and DeployOpen does not publish a price list. No researched figure for these costs is available here, so ask each provider to itemize them.
What should we ask a partner to include in a fixed-scope quote?
A fixed-scope quote should list the environments in scope, the components and data stores to be mapped, the documents and records to be produced, and the procedure for updating them. Ask who performs each task, what the organization must supply, and which deliverables are one-time versus recurring. Confirm the record format, such as the tools used to hold component inventories and wiki pages with version history, and whether those tools will run in your own infrastructure. Require a clear statement that the partner prepares evidence but does not issue assessment results, and confirm which independent assessor the organization will use. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Primary sources for 03.04.11
Start with the requirement itself. NIST's Rev. 3 page for 03.04.11 Information location states the obligation: identify and document where CUI is processed and stored and which system components hold it, and document changes to those locations. Read it alongside the discussion text, which ties the requirement to knowing which components handle CUI and which users can reach it. That link between location and access is what your access control and information flow controls depend on, so the requirement should be read as an input to those families, not as a standalone inventory exercise.
Next, read the assessment procedure in SP 800-171A Rev. 3 for 03.04.11. This is what an assessor will use to test you. It lists five determination statements and the examine, interview and test methods, so it tells you which documents to have ready (configuration management policy, the plan and procedures for recording information location), which people must be able to explain the process (those who manage information location and user access, and those who operate and maintain the systems), and which processes will be tested in practice. Confirm the current assessment objects with your assessor before you build the evidence set, because they decide what a reviewer will ask to see.
Finally, check the Rev. 2 to Rev. 3 change analysis if you are working from an older document set or a contract that still names Rev. 2. NIST lists 03.04.11 as one of the 19 requirements new in Rev. 3 and maps no Rev. 2 requirement to it. That means a Rev. 2 system security plan cannot show this control by reference to an existing requirement number. Confirm with the contracting officer which revision governs your contract, because the answer determines whether you must document 03.04.11 at all.
How DeployOpen works on this
DeployOpen prepares the systems and documentation an organization needs to show where CUI is processed and stored, and which components hold it. The organization owns its controls and its assessment outcome, and only an independent assessor issues results.
How we scope
- The written scope lists the systems, enclaves and components in which CUI is processed or stored for the 03.04.11 Information location requirement.
- The scope names the owner of each location record, the review trigger for location changes, and the people who answer for user access to CUI.
- Engagements are fixed-scope, so deliverables and timelines for location evidence are agreed in writing before work starts.
How we build
- We configure self-hosted asset inventory in GLPI so each component holding CUI carries an owner, a location and a documented data role.
- We set up Wazuh Syscollector inventory on endpoints and servers so hardware, software and services can be compared against the recorded location list.
- We structure XWiki or BookStack spaces so location decisions, approvals and changes are recorded, versioned and restricted to the people who maintain them.
How we hand over
- You receive a documented location register covering CUI locations, the components involved and the procedure for recording each change.
- Handover includes the configured inventory, sample reports and the change record format, with the assessment procedure's examine and interview objects mapped to each artifact.
- Testing is documented so you can show an assessor how location records match live inventory, with gaps logged for your own remediation decisions.
How we support
- Ongoing support is available as a retainer for keeping location records current as systems, cloud accounts and staff roles change.
- Periodic inventory reviews can be scheduled so drift between recorded and actual CUI locations is found before an assessment.
- Before an assessment, confirm with your assessor which artifacts they will request, since the independent assessor decides what evidence is sufficient.
