What 03.04.10 system component inventory requires in NIST SP 800-171 Rev. 3
A contract or assessor now expects a component inventory, and 03.04.10 is new in Rev. 3 with no Rev. 2 equivalent. Teams cannot reuse an existing CMMC practice ID for it, because NIST maps no Rev. 2 requirement to it and CMMC Level 2 assesses only the 110 Rev. 2 requirements. The requirement asks the organization to develop and document an inventory of its system components, review and update that inventory at a frequency the organization defines, and update it as part of installations, removals and system updates. Components include the endpoints, servers, network equipment, virtual machines, software and other elements that make up the system handling CUI. The review frequency is the one organization-defined parameter for this requirement. NIST does not set it, so if the contracting agency does not specify a value, the organization must choose one and be able to defend it. Confirm with the agency or contracting officer whether a value has been specified before you choose.
The risk behind the requirement is simple: a component you do not know about may hold, process or transmit CUI without the controls you have applied to the rest of the system. An unmanaged laptop, a forgotten test server or an undocumented network appliance can sit outside patching, logging and access reviews. Inventories usually fail on freshness rather than existence. Most organizations can produce a list, but the list reflects the environment from several months earlier, and the assessor compares it against the systems that are running today. Ask who owns each update trigger, such as a new device being provisioned, a server being retired or a patch changing installed software, and check whether those triggers actually feed the inventory. Run a sample check by picking several components from a network scan and confirming each appears in the inventory with current details.
Assessors test this requirement by examining the inventory and the procedures for maintaining it, and by interviewing the people who manage it. They also test the processes and mechanisms that keep the inventory current. Expect to show the review record for the chosen frequency, the change tickets that led to inventory updates, and evidence that the inventory matches discovered assets. Open-source tools can generate much of this evidence. GLPI's Assets module holds computers, software, network equipment and other items and can receive automatic entries from its agent. Wazuh's Syscollector collects hardware, installed software and open ports from endpoints. osquery can query hosts across a fleet on a schedule. Confirm which fields each tool captures for your environment, and decide which tool is the system of record so the inventory has one authoritative source.
Which components and teams fall inside the 03.04.10 inventory scope
Before an inventory can be reviewed or updated at a defined frequency, the organization has to decide what counts as a system component, which CUI environment the inventory covers, who triggers changes, and how hosted services appear. Each decision below changes how many records exist and who must keep them current.
Endpoints and servers in the CUI boundary
Laptops, workstations, virtual machines and physical servers that process, store or transmit CUI, or that provide security protection for those systems, are the core of the inventory. Record hardware, operating system, installed software and the owner of each asset. Ask whether shared admin workstations and build hosts are included, since they often touch CUI systems without appearing in the endpoint list. Confirm the boundary with the system security plan before counting.
Network devices and peripherals
Routers, firewalls, switches, wireless access points, printers, scanners and collaborative devices can all hold configuration, retain documents or provide a path into the CUI environment. Each one should appear as a component with an owner and a location. Printers and multifunction devices are the most often missed, because they store print jobs and are rarely placed in the endpoint inventory. Check each device class against the boundary diagram.
Cloud resources and virtual infrastructure
Virtual networks, storage buckets, managed databases, container clusters and cloud-hosted virtual machines are system components when they hold or process CUI. Automated discovery tools may not list resources created outside the standard build pipeline. Ask who can create cloud resources in the CUI account or subscription, and whether those creations feed the inventory automatically or through a ticket. Shadow resources are the main gap to close.
Installed software and firmware
Operating system packages, applications, browser extensions and firmware versions determine how a component is configured and whether it is patched. Recording software alongside hardware lets the inventory support flaw remediation and authorized-software decisions. Decide whether firmware on network and peripheral devices is recorded as a separate attribute. Confirm the collection frequency for software data so that the inventory reflects what is actually running.
Teams that trigger installs and removals
The inventory is only accurate if every team that installs, moves or retires a component reports the change. Typical owners include IT operations, platform engineering, the help desk, facilities for devices in physical spaces, and the teams that manage cloud accounts. Assign each team a named step in the change process and tie the inventory update to closing a ticket. Ask who has authority to remove a component from the record and who verifies that it is gone.
Third-party hosted services
Software-as-a-service tools and externally hosted platforms that process CUI are not owned by the organization, but they still affect the CUI environment. Record them with the provider, the data they hold, the contract that governs them and the responsible internal owner. Confirm with the contracting officer or customer how externally hosted components are to be described in the system security plan, because that choice determines whether they belong in the inventory or are covered only by the provider agreement.
How an assessor tests the component inventory requirement
This table compares what an assessor examines, interviews and tests for 03.04.10, with the evidence each object produces and the findings that most often cause a gap. Read it as a checklist for preparing evidence before an assessment begins. The main takeaway is that an inventory on paper is not enough: assessors also check that the process keeps it current and that the review frequency is defined.
| Assessment element | What the assessor looks for | Evidence to have ready | Common finding |
|---|---|---|---|
| Determination statements | Six statements cover developing and documenting the inventory, reviewing and updating it at the defined frequency, and updating it with installations, removals and system updates. A seventh checks that the review frequency is defined. | A written inventory with a stated review frequency and records showing each review took place | Frequency is never set, so the seventh determination cannot be met |
| Examine: policy and procedures | Configuration management policy and procedures that assign who maintains the inventory and how changes reach it | Signed policy, procedure documents with owners and version dates | Procedures describe a manual spreadsheet process that nobody follows |
| Examine: component inventory procedures | Steps for adding, removing and reviewing components and the trigger for each update | Procedure showing links to change tickets, procurement and decommissioning | No link between change management and inventory updates |
| Examine: configuration management plan | Whether the plan names the inventory as a managed artifact and sets its scope | Plan section covering inventory scope, data fields and owners | Plan omits inventory entirely or lists a different scope than the inventory covers |
| Examine: system design documentation | Whether the inventory matches the components and boundaries shown in the design | Architecture diagrams aligned with the inventory and system security plan | Diagrams show components that appear nowhere in the inventory |
| Interview: inventory owners | Whether the people maintaining the inventory know the process, the review cadence and where the record lives | Named owners and a short walkthrough of their last update | Owners describe the process differently from the written procedure |
| Interview: security personnel | Whether security staff use the inventory for scanning, patching and incident response | Evidence that vulnerability scans and alerts are scoped from the inventory | Security tools scan ranges that the inventory does not list |
| Test: inventory processes and mechanisms | Whether the inventory matches live systems when compared with discovery data, and whether tools update it automatically or on schedule | Discovery or agent output compared with the inventory, plus dated review records | Unmanaged or shadow assets appear in discovery but not in the inventory |
How to build and maintain the component inventory step by step
This sequence turns 03.04.10 from a policy statement into a working inventory with a defined review frequency, a reconciled CUI boundary and a documented first review that an assessor can trace.
Define inventory scope and attributes
Start by deciding which components belong in the inventory: servers, workstations, network devices, virtual machines, cloud resources, mobile devices, security tools and any software that touches systems in the CUI environment. Then define the attributes each record must carry, such as asset identifier, hardware or software version, owner, location, operating system, network address and the system or boundary it belongs to. The output is a written inventory standard approved by the system owner, held with the configuration management policy and procedures that the assessor will examine.
Set and document the review frequency
03.04.10 has one organization-defined parameter: the frequency at which the inventory is reviewed and updated. Your organization assigns that value, because NIST does not supply it. Choose a frequency your team can actually meet, record it in the configuration management plan or procedures, and confirm with your contracting officer or assessor whether any agreement specifies a value. The output is a documented ODP value that matches what the team does in practice, since the assessor tests whether the defined value is in place and followed.
Discover and record components
Run discovery across the full system boundary rather than relying on purchase records alone. Automated tools such as a GLPI Assets inventory, Wazuh Syscollector data or osquery queries can gather hardware and software details from endpoints and servers, and network scans or cloud API exports can catch devices that lack an agent. Reconcile automated results with procurement and virtualization records to find gaps. The output is a populated inventory where every record has the attributes defined in step one and a named owner.
Reconcile the inventory against the CUI boundary and SSP
Compare the inventory with the system security plan and the documented CUI boundary. Every component that stores, processes or transmits CUI, or provides security protection to those components, should appear in the inventory and be shown in the system design documentation. Investigate any component that appears in discovery but not in the plan, and any planned component that discovery did not find. The output is a reconciliation record listing each discrepancy and its resolution, which supports the system design evidence an assessor will review.
Wire installation, removal and update triggers
Connect the inventory to the change process so that new installations, removals and system updates create inventory changes at the time they happen. Add an inventory update step to the change request and decommissioning checklists, and require that patch and upgrade records reference the affected asset. Where your tools support it, configure alerts for unexpected new devices or software. The output is a documented trigger list and a change record that shows the inventory was updated as part of each event, which links 03.04.10 to the change control requirements in 03.04.03.
Run and record the first documented review
Carry out the first review at the frequency you defined, with people who hold component inventory responsibilities and information security responsibilities. Check for stale records, missing owners, unsupported versions and components that should be removed, then correct the inventory and log the findings. The output is a signed or dated review record that states the date, the reviewers, the scope reviewed, the changes made and the open items. Keep this record with the inventory export, because an assessor will ask to see both the process and evidence that the process ran.
Why the frequency ODP and update triggers decide whether the inventory passes
The review frequency is the one part of 03.04.10 that NIST leaves to you. The requirement has a single organization-defined parameter (ODP): the frequency at which the system component inventory is reviewed and updated. NIST does not assign that value. If the federal agency that holds your contract or agreement does not specify it, your organization must set it, and the requirement is not complete until you do. The assessor under SP 800-171A Rev. 3 first checks that a value is defined, then checks that the value is written down in a policy or procedure, and then checks that the inventory was actually reviewed on that schedule. A blank or vague entry such as "periodically" gives the assessor nothing to test against.
Pick a frequency you can prove. A defined interval that the team misses fails more clearly than a stricter interval that nobody tracks, so tie the number to a recurring task with an owner and a recorded date of completion. Ask the contracting agency in writing whether it has specified an ODP value for your contract, and record the answer in the system security plan. If it has not, document your own value, the reason for it and who approved it. Also confirm whether the review interval you choose lines up with the frequencies you set for the baseline configuration in 03.04.01 and the change records in 03.04.03, since an assessor will compare them.
The update triggers are what keep the inventory honest between reviews. The requirement expects the inventory to change whenever components are installed, removed or updated, so the trigger events are the ones your change control process already produces: a new server built from the baseline, a decommissioned endpoint, a patch that alters an operating system or firmware version. In practice, a change ticket that does not reference an inventory update is a gap an assessor can find by sampling tickets against the inventory. Each approved change should therefore carry a step that updates the inventory record, and the inventory should be reconciled against the baseline configuration so that a component present in one but absent from the other is flagged for investigation.
Which evidence shows an inventory is current and complete
An assessor testing 03.04.10 looks for proof that the inventory exists, that someone reviewed it on the frequency the organization defined, and that it matches what is actually running. The cards below cover the artifacts that tie those three points together, and how to keep each one current between assessments.
Documented inventory with defined attributes
The inventory itself is the primary artifact. Each entry should carry the attributes the organization chose, such as asset owner, hardware identifier, operating system version, location, whether the component stores or processes CUI, and the system boundary it belongs to. Check that the attribute list is written down and that entries are not missing fields the organization said it would record. Export a dated copy at each review so the assessor can see the state at a given point, not only the current state.
Review record showing the defined frequency
The ODP for 03.04.10 asks the organization to set how often the inventory is reviewed and updated, and the assessor will check that the organization met its own schedule. Keep signed or ticketed review records that name the reviewer, the date, the version of the inventory reviewed and the changes made. A missed review should be recorded with its cause and a corrective date, since a gap that is documented is easier to explain than one that is hidden.
Change tickets tied to installs and removals
The requirement expects the inventory to be updated as part of installations, removals and system updates. Change tickets are the link that proves this happened in practice. Each ticket for a new server, a decommissioned laptop or an upgraded operating system should reference the inventory entry it changed. Ask whether tickets can close without an inventory update, because that gap is where inventories drift from reality.
Discovery scan outputs
Automated discovery and agent-based collection produce independent evidence of what is running. For an open-source stack, GLPI's Assets module can hold the inventory and receive automatic pushes from the GLPI Agent, Wazuh's Syscollector reports hardware, software, network interfaces and services from each endpoint, and osquery can schedule queries across a fleet. Keep the raw scan outputs with their timestamps, since an assessor may ask how an entry was created and whether it came from a scan or manual entry.
Reconciliation between inventory and live systems
Reconciliation compares what the inventory says with what discovery finds and records every difference. Unknown devices, entries with no matching live system and attributes that disagree should each have a disposition: added, removed, corrected or accepted with a reason. Run the comparison on a schedule that matches the defined review frequency and keep the output as a dated report. Ask your implementation partner to confirm how the comparison handles systems that appear only during a short session, such as a Velociraptor hunt scheduled for offline machines.
Keeping evidence current between assessments
Evidence decays when it is produced only for an audit. Assign an owner for the inventory, tie the review schedule to a recurring calendar item, and make discovery scans automatic so that the raw data accumulates without manual effort. Confirm the retention period for scan outputs and review records with your own policy, since the retained history is what proves the program ran between assessments. Test the process by picking a random system and tracing it from its change ticket to its inventory entry to its last scan.
Open-source tools that can produce inventory evidence
GLPI is an IT asset management and service desk platform, and its Assets module is the natural home for a managed component register. It covers computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually, which suits hardware such as racks and phones, or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10.
- Record scope: Define which asset types count as system components for your boundary, then keep the register limited to those types so the export matches the scope in your system security plan.
- Automatic discovery: Deploy the GLPI Agent to endpoints so that installations and removals reach the register without waiting for a manual update.
- Manual entries: Record racks, network devices and other items the agent cannot see, with owner, location and status fields filled in.
- Change history: Use GLPI's logs and ticketing to tie each installation or removal to an approved change record.
- Review evidence: Export the register at each review date and keep the signed export as proof of the defined review frequency.
License caveat: GLPI is licensed under GPL-3.0-or-later. Confirm with your legal or procurement team how that license applies to your planned use, including any modifications or plugins you intend to deploy. Confirm that the agent and native inventory meet your attribute and frequency needs before you rely on them.
Wazuh's Syscollector module collects inventory from each monitored endpoint and sends it to the Wazuh indexer, where it appears in dashboard inventory views and reports. It gathers hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates. This makes it strong on technical attributes, though it reports what is observed on agents rather than what was approved.
- Endpoint attributes: Syscollector captures hardware, operating system, software, network and service data that you can compare against your baseline.
- Central view: Inventory data lands in the indexer, so you can filter by host group and export reports for review.
- Drift detection: Compare current inventory with a previous snapshot to see components that appeared or disappeared between review dates.
- Coverage gaps: Devices without a Wazuh agent, such as some network appliances, will not appear, so pair the output with a register or network discovery.
- Retention settings: Confirm how long inventory data is kept in your indexer so the evidence window matches your assessment period.
License caveat: Wazuh is licensed under GPL-2.0-only. Confirm the license obligations with your legal team for your deployment and any extensions you add. Confirm that Syscollector's collection frequency and attributes satisfy your defined review and update frequency before you rely on it.
osquery exposes operating system state as SQL tables, so you can ask an endpoint directly what is running or installed. Its osqueryd daemon schedules queries across a fleet of hosts. For inventory, the value lies in custom queries that report the software, processes, kernel modules and network connections you define as in scope, and in the ability to run the same query on every host at a fixed interval.
- Scheduled queries: Use osqueryd to run inventory queries on a defined schedule across the fleet, producing repeatable results.
- Custom tables: Query installed software, loaded kernel modules, open network connections and browser plugins, then compare results over time.
- File hashes: Record hashes of approved binaries so that changes to components can be detected, not only additions.
- Log output: Send results to a central log store, where timestamps and host identifiers form the audit trail.
- Query ownership: Keep the query pack under version control with an owner, so the inventory definition is itself a managed artifact.
License caveat: osquery is available under Apache-2.0 OR GPL-2.0-only, so you choose the license that fits your use. Confirm that choice with your legal team. Confirm that query coverage and scheduling meet your attribute and frequency requirements, because osquery returns only what your queries ask for.
Velociraptor is an endpoint visibility and forensic tool that collects artifacts defined in VQL. Its hunts run one or more artifacts across a group of systems, schedule collection for offline machines when they reconnect, and create a notebook per hunt for analyzing combined results. It suits point-in-time inventory checks and verification of specific components, more than continuous asset registers.
- Targeted collection: Define an artifact that gathers the component details you need, then run it as a hunt against a defined group.
- Offline handling: Machines that are offline are collected when they reconnect, which helps close gaps in a review cycle.
- Notebooks: Each hunt produces a notebook with the combined results, which can be saved as review evidence.
- Verification: Use hunts to confirm that the register matches reality for a sample of endpoints during an assessment preparation exercise.
- Scope control: Limit hunts to the systems inside your boundary so the collected data matches the documented scope.
License caveat: Velociraptor is licensed under AGPL-3.0-only. Confirm the obligations of the AGPL with your legal team, particularly if you modify the software or make it available to users over a network. Confirm that its artifacts and hunt schedule meet your defined review and update frequency before you rely on it.
What meeting 03.04.10 costs in money and effort
This table breaks the cost of keeping a system component inventory into its parts, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are supplied for this requirement, so use the right-hand column to decide what to request in a quote.
| Cost component | One-time or recurring | Who is paid | What drives it up or down |
|---|---|---|---|
| Tooling or licenses | Recurring if commercial; none for GPL or Apache-licensed tools | Software vendor, or no license fee for open-source options | Open-source tools remove license spend but still need hosting, patching and staff time. Confirm each tool's license terms with the vendor before deployment. |
| Discovery of existing components | One-time | Implementation partner or internal engineers | Number of network segments, cloud accounts, endpoints and undocumented devices. Scoping the boundary early keeps this down. |
| Integration with discovery sources | One-time, with rework after major changes | Internal platform engineers or implementation partner | Number of data sources (agents, cloud APIs, CMDB, network scans) and how much they must be reconciled. |
| Ongoing review at the defined frequency | Recurring | Internal staff or a retained service provider | The ODP frequency you set, the rate of change in your environment, and how much review is automated versus manual. |
| Evidence upkeep | Recurring | Internal compliance or security staff | How inventory exports, review records and change tickets are stored and linked. Clear, scripted evidence reduces effort at each assessment. |
| External review or assessor sampling | Recurring at each assessment cycle | Independent assessor or certification body | Sample size chosen by the assessor, the number of components in scope, and how quickly you can produce records for any sampled item. |
| Remediation of inventory gaps | One-time per gap, recurring if gaps recur | Internal staff or implementation partner | Frequency of unmanaged installations and removals. Process controls that require inventory updates during change work reduce the number of gaps. |
Who owns the inventory, who builds it and who assesses it
The organization owns requirement 03.04.10 in full. Under the requirement, it must develop and document an inventory of system components, review and update that inventory at the frequency it defines, and update it when components are installed, removed or changed through system updates. The organization also sets the review frequency, which is the single organization-defined parameter for this requirement, and an assessor will check that a value was assigned and is followed. Ownership sits with a named role, usually in IT operations or the security team, and that role answers assessor interview questions.
- Defining the inventory scope: Deciding which components count as system components within the CUI boundary, including endpoints, servers, network devices, cloud resources and virtual machines.
- Setting the review frequency: Choosing and documenting the ODP value, then recording who reviews the inventory and how changes are approved.
- Owning change triggers: Making sure installations, removals and patches feed the inventory through a documented process.
- Keeping records current: Retaining review sign-offs and change history that show the inventory was maintained over time.
- Interviews and staff roles: Assigning personnel with inventory responsibilities who can explain the process to an assessor.
Before the assessment, confirm that the named owner, the review frequency and the scope statement appear in the configuration management policy and procedures.
An implementation partner such as DeployOpen can prepare the systems and evidence that support 03.04.10. This work usually involves deploying discovery tools, connecting their data sources, reconciling results against asset records and producing the review reports the organization uses. The partner builds and documents the mechanisms, but the organization decides the scope, the review frequency and the accepted inventory. The partner does not issue an assessment result or declare the requirement met.
- Tool deployment: Installing and configuring open-source inventory platforms, such as GLPI for asset records or Wazuh Syscollector and osquery for endpoint data, inside the client's own environment.
- Discovery integration: Connecting agents, scheduled queries and network sources so that components appear in one inventory view.
- Reconciliation: Comparing automated results with the asset register, flagging unmanaged components and documenting how each gap was resolved.
- Evidence packaging: Preparing exports, review records and procedure documents that show the inventory process runs as written.
- Handover: Training the organization's staff to run reviews and update the inventory without the partner.
Ask the partner to state in writing which artifacts it will produce and which decisions remain with the organization.
An independent assessor tests whether 03.04.10 is implemented. Under the assessment procedures in SP 800-171A Rev. 3, the assessor examines documents such as the configuration management policy, inventory procedures and the configuration management plan, interviews personnel with inventory and security responsibilities, and tests the inventory processes and supporting mechanisms. The assessor's conclusion is the only independent finding. Where a federal contract requires a formal assessment, the assessing body is set by the program, not by the organization or its consultant.
- Independence limits: An assessor cannot design the controls it tests or prepare the evidence it then judges without compromising its independence.
- Examine and interview: The assessor reviews documented procedures and asks owners to walk through real reviews and changes.
- Test method: The assessor may sample inventory records against live discovery data to see whether unmanaged components appear.
- Evidence requests: Expect requests for review records, change tickets and reconciliation logs for a defined period.
- Who issues results: Only the assessor or the sponsoring authority issues the findings, scores or reports.
Confirm the assessor's engagement terms and which assessment method your contract requires before you ask a partner to prepare evidence.
Where component inventories usually fall short and how to close each gap
A 03.04.10 inventory fails in predictable places: devices and cloud resources that never reach the list, reviews that happen on no set schedule, and records that drift from what is actually running. Each card below names one gap, why an assessor will notice it, and the fix that closes it.
Shadow endpoints and unmanaged devices
Laptops, lab machines and contractor devices that connect to the CUI environment without enrolling in any discovery tool are the most common omission. An assessor who samples a network segment and finds hosts absent from the list will question the whole inventory. Close the gap by running passive network discovery against every segment that touches CUI, then comparing discovered addresses with the inventory each review cycle. Every unmatched host needs an owner or removal.
Cloud resources outside the list
Virtual machines, containers, storage buckets and managed databases are often created by project teams and never recorded alongside on-premises hardware. Because 03.04.10 covers system components generally, an inventory that omits cloud workloads describes only part of the system. Pull resource listings from each cloud account on a schedule and reconcile them against the inventory. Confirm with your provider which resource types its native APIs expose, since coverage differs.
No defined review frequency
The requirement leaves the review interval to the organization, and the frequency is an organization-defined parameter that must be assigned. Many inventories are updated when someone remembers, which an assessor cannot test. Write the interval into the configuration management policy and the inventory procedure, then keep dated review records showing each cycle was completed. Ask your assessor which evidence format they will accept for those records before the review begins.
Inventory and live systems disagree
An inventory can be complete on paper and still wrong if its fields, such as operating system version, IP address or installed role, were entered once and never refreshed. Agent-based collection that reports hardware and software on a recurring basis keeps those attributes current. Compare a random sample of live hosts against their inventory records during each review and log every mismatch with a correction date. Mismatches found in review are evidence the process works, but unexplained ones are not.
Software tracked apart from hardware
Records that list a server but not the operating system, middleware, libraries or browser extensions running on it leave the software side of 03.04.10 unmet and also weaken vulnerability tracking under 03.11. Configure collection so that each host record lists installed packages with versions, and link those packages to the host they run on. Spot-check a few high-value systems to confirm the software list matches what the host reports at the command line.
No link to change tickets
When a component is added, moved or retired, the inventory should change in the same cycle, and the change record should point to the inventory entry. Without that link, an assessor cannot tell whether a new host was approved or simply appeared. Require each change request affecting hardware or software to name the inventory asset it touches, and compare recent change tickets against inventory deltas each review. Gaps between the two are findings to resolve, not paperwork to file.
Questions teams ask about the 03.04.10 component inventory
How much effort does a 03.04.10 component inventory take?
Effort depends mainly on how many components the system contains, how many places they are recorded today, and how often they change. The requirement asks for an inventory that is developed and documented, reviewed and updated at a frequency your organization defines, and updated as components are installed, removed or updated. The one-time work is building the first list and deciding which components fall inside the CUI boundary. The recurring work is the update step with each change and the periodic review on your schedule. Ask any provider to quote the one-time discovery and reconciliation separately from the recurring review, and to state which tools are assumed to feed the inventory.
Can open-source tools build a component inventory on their own?
Open-source tools can collect much of the data, but they do not decide what belongs in the inventory or prove that it is maintained. GLPI's Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks, and its GLPI Agent can push records automatically. Wazuh's Syscollector gathers hardware, operating system, installed software, network interfaces, open ports, services, users and Windows updates from each endpoint. osquery answers SQL queries across a fleet of hosts, and Velociraptor collects artifacts across groups of systems. Together they cover endpoints well. Gaps usually sit in network devices, cloud resources, operational technology and appliances that no agent reaches, so those need manual records or other sources. Confirm coverage for each component class in your own environment before relying on any tool.
How long does building the inventory take and what does it need from staff?
No duration is set by the requirement or by any supplied figure, so the time depends on the size and age of your environment. The work usually runs in sequence: define the boundary, agree which component classes are in scope, collect the first list from discovery tools and existing records, reconcile the differences, and then set the review frequency. Internal staff need to supply an owner for each system, access to asset, procurement or configuration records, network and cloud administrators who can confirm devices, and one person accountable for the inventory. Owner availability often sets the pace more than tooling does. Ask a provider for a written schedule tied to the agreed scope, and list the roles and time your team is expected to contribute.
Is it worth bringing in a partner for the 03.04.10 inventory?
A partner is worth considering when your team lacks time, a clear boundary or experience deploying discovery across the environment, but your organization still owns the inventory and its review. DeployOpen plans, implements, customizes, integrates and documents self-hosted open-source platforms inside your own infrastructure, which can include deploying GLPI, Wazuh or osquery and connecting their output into one inventory and evidence set. DeployOpen prepares systems and evidence but does not issue assessment reports or certifications, and an independent assessor still tests the requirement. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Compare providers on which components they will include, who maintains the records after handover, and how review evidence is retained.
How does 03.04.10 differ from CMMC practices?
03.04.10 is a Rev. 3 requirement with no Rev. 2 predecessor. NIST's change analysis lists it as one of 19 requirements new in Rev. 3 and maps no Rev. 2 requirement to it. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID for this inventory duty. Under 32 CFR 170.14(c)(3), CMMC Level 2 requirements are identical to Rev. 2, which is why DoD contractors are still assessed against those 110 requirements. Do not assume an existing CMMC practice covers the inventory duty. Confirm the mapping with your assessor, and ask your contracting officer which revision governs your contract, since a September 2026 DoW class deviation names Rev. 2 explicitly. The NIST Rev. 3 text for 03.04.10 is the primary source for the requirement wording.
What will an assessor ask about the component inventory first?
An assessor usually starts by asking for the inventory and the procedure that governs it, then tests whether the list matches the environment. SP 800-171A Rev. 3 examines configuration management policy and procedures, the inventory procedures, the configuration management plan and system design documentation. It interviews personnel who manage the inventory and those with information security responsibilities, and it tests the processes and mechanisms that support the inventory. Expect questions about which components are recorded, when the inventory was last reviewed and at what frequency, how installations and removals were reflected, and how a sample of live systems matches the records. Assessment covers six determination statements plus a check that the review frequency is defined, so prepare that value and the evidence of each review in advance.
Does the inventory review frequency have to be a specific number?
The requirement does not fix an interval. The review frequency is an organization-defined parameter, and SP 800-171A checks that a value is defined. NIST does not assign parameter values, and if a federal agency does not specify one, the nonfederal organization must assign it to complete the requirement. Choose an interval your team can keep, record it in the configuration management procedures, and log each review with its date, reviewer and changes made. Check the contract or agreement first, because it may specify a frequency that your chosen value must meet. When evaluating a partner, ask how the frequency drives reminders, review tasks and evidence collection in the tooling.
How DeployOpen prepares component inventory evidence
DeployOpen starts by agreeing the inventory scope in writing before any tool is deployed. For 03.04.10, that scope should state which system components are in the boundary of the CUI environment, including endpoints, servers, network equipment, peripherals, virtual machines, cloud resources and the software installed on each. It should also name the organization-defined parameter, the frequency at which the inventory is reviewed and updated, so that the value is defined in the written record rather than left to assumption. Confirm with your assessor which components they expect in scope, since the inventory must match the system boundary in your system security plan.
Inside your own cloud accounts, data centers or air-gapped network, DeployOpen deploys and configures self-hosted tools that populate the inventory automatically. Depending on the environment, this can mean GLPI for asset records (entered manually or pushed by the GLPI Agent), Wazuh Syscollector for hardware, operating system, software, ports and services, osquery for scheduled fleet queries, and Velociraptor for collection across groups of systems, including offline machines that report when they reconnect. Each tool's collection scope, schedule and retention settings are documented, and the tool choice is confirmed against your own environment rather than assumed. Ask the implementation partner to show which tool is the system of record for each component type.
DeployOpen then documents the review process: who reviews the inventory, at the frequency you defined, how installations, removals and system updates are recorded, and how discrepancies are routed to change control under 03.04.03. The resulting evidence package typically includes the inventory export, the review records, the procedure, and configuration records showing the tools were operating. DeployOpen prepares these artifacts for your assessment, but it does not issue assessment results, scores or certifications. Those come from your assessor or the federal agency, and scope, deliverables and timelines are agreed in writing before any work starts.
