CM.L2-3.4.1 System baselining: requirements and evidence

What CM.L2-3.4.1 system baselining requires before a CMMC assessment

CM.L2-3.4.1 asks you to establish and maintain baseline configurations and system inventories covering hardware, software, firmware and documentation, and to keep both current across each system's life cycle. A defense contractor preparing for a Level 2 assessment needs a known, approved starting point for every system that stores, processes or transmits CUI. The requirement is the foundation for the other configuration management requirements: the software inventories kept here feed the allow or deny list work under CM.L2-3.4.8, and the baseline is the reference point that change control and drift checks compare against. The requirement is the Level 2 form of basic requirement 3.4.1 in NIST SP 800-171 Rev. 2, and NIST SP 800-171A breaks it into six assessment objectives: establishing a baseline configuration and a system inventory, each covering hardware, software, firmware and documentation, and reviewing and updating both throughout the system development life cycle. An assessor will test each objective, so a baseline that exists only as a single snapshot will not satisfy the review and update objectives. The risk is simple to state. If you cannot name what is connected to a CUI environment, what software it runs, and how it was configured when it was approved, you cannot tell whether an unauthorized change has happened or whether a component has been missed in your security assessment. Under the CMMC Scoring Methodology, CM.L2-3.4.1 is a 5-point requirement, and it must be scored MET. It cannot be placed on a plan of action and milestones, so an unmet 3.4.1 blocks Conditional or Final Level 2 status and removes 5 points from the total of 110. Treat it as a gate, not as a backlog item to fix after the assessment.

Most contractors find this requirement hard for predictable reasons: inventories built once for an audit and never refreshed, software that was installed by users or added by a vendor and never recorded, and configuration documents that describe the environment as it was designed rather than as it runs today. Before you schedule anything, confirm three things with your own records: which asset sources you trust (directory, endpoint management, network scans, cloud consoles), whether the configuration management plan names an owner and a review cycle, and whether you can produce dated review and update records for the inventory. The CMMC Assessment Guide for Level 2 describes the expectation that systems be built from a known, approved baseline that documents software, configuration settings and placement within the network. Use that as your test: if an assessor asked for the baseline of one workstation today, could you produce it within minutes, with a record of who approved it and when it was last reviewed?

Which systems, components and records fall under baselining

Before a baseline can be written, the organization must decide which systems count as organizational systems that process, store or transmit CUI, and which components inside them need records. Each card below is a scoping decision that changes the size of the inventory and the teams that own its records.

CUI system boundary and asset scope

CM.L2-3.4.1 applies to the organizational systems in scope for CUI, so the first decision is the boundary. Map where CUI is created, processed, stored and transmitted, then list every system that touches those flows, including systems that only provide security or administrative support. Document the boundary in the system security plan so the baseline and the inventory describe the same population. Confirm the boundary with the assessor's view of the environment before inventory work starts, because a boundary that moves late forces rework across every record.

Endpoints and workstations

Laptops, desktops and thin clients that access CUI are the largest and most volatile part of most inventories. Records should capture hardware identity, operating system build, installed software, and the user or owner assigned to each device. Scope decisions to settle include whether personal devices used for email or remote access are in scope, and how devices that leave the boundary for repair or travel are tracked. Ask the team that owns endpoint management how often it can refresh the inventory from the device itself rather than from purchase records.

Servers, virtual machines and containers

Servers, hypervisors, virtual machines and container hosts carry most of the configuration settings an assessor will later examine. Decide whether each virtual machine, template and container image is its own inventory record or belongs to a parent platform record, and how short-lived workloads are captured. Records should include the image or template that built the component, its network placement and its installed software. Infrastructure teams usually own these records, but platform or application teams often create workloads, so assign a single owner for each record type.

Network devices and firmware

Routers, firewalls, switches, wireless controllers and their firmware sit on the boundary and are part of what 3.4.1 asks you to baseline. Record the make, model, firmware version and management interface for each device, along with the configuration file or template that defines it. Firmware is easy to omit because it often sits outside the operating system inventory, so check each device class separately. Network engineering usually owns these records, and the team should confirm which devices are managed by a carrier or outsourced provider.

Cloud and SaaS components

Cloud accounts, subscriptions, managed databases, serverless functions and SaaS tenants that store or process CUI belong in scope even though no one installs hardware for them. Records should capture the account or tenant, the region or data location, the configuration templates in use and the identity groups with administrative rights. Confirm which cloud and SaaS services are inside the CUI boundary, and whether each provider's own compliance documentation covers the components you rely on. Cloud platform or security teams usually own these records, with the provider responsible for its own underlying infrastructure.

Third-party managed and OT systems

Systems run by a managed service provider, an outsourced help desk or an operational technology owner often sit partly outside the organization's direct control. Decide whether each third party's systems are inside the boundary, and write the baseline records into the service contract or the flowdown terms so the provider must supply them. OT systems such as test equipment, machine controllers and building systems can run software that does not match standard endpoint tooling, so their owners should provide the inventory themselves. Ask each provider to confirm in writing which records it maintains and how often it updates them.

How an assessor tests the baseline and inventory

This table maps the six NIST SP 800-171A assessment objectives for CM.L2-3.4.1 to the test an assessor runs, the evidence requested and the findings that usually cause a NOT MET result. Read each row as a question the assessor will ask, then check whether your records answer it in final form.

Assessment objective	What the assessor tests	Evidence requested	Common findings
Baseline covers hardware	Whether a documented baseline lists the hardware components in scope and their configuration state	Baseline document, architecture diagrams, hardware baseline entries tied to asset records	Baseline omits network appliances, virtual hosts or specialized equipment
Baseline covers software	Whether installed operating systems, applications and versions match the approved baseline	Software baseline list, build images or golden configuration records, version history	Baseline lists product names without versions or patch levels
Baseline covers firmware	Whether firmware versions for devices are recorded and included in the baseline	Firmware entries per device class, vendor release records, update logs	Firmware missing for switches, firewalls, BIOS or embedded devices
Baseline covers documentation	Whether configuration documentation exists, is approved and describes the system as built	Configuration management plan, approved configuration documents, network placement records	Documents describe a design that was never built or were never approved
Inventory covers hardware, software, firmware and documentation	Whether a system inventory records each component and its attributes, and whether it reconciles with the baseline	Inventory export with owner, location and version fields, reconciliation records	Inventory is a spreadsheet last edited months earlier, with gaps for cloud or endpoint assets
Baseline and inventory reviewed and updated through the life cycle	Whether review and update occur at defined points, such as after changes or on a set schedule, and leave a record	Review records, change control entries, component installation and removal records, revision history	No dated reviews, or changes made without a matching inventory update

Sequence for building a baseline and inventory that passes

This sequence turns CM.L2-3.4.1 from a policy statement into a scoped, populated and signed-off baseline and inventory that an assessor can trace from the system boundary to each component. Each step closes with a named artifact so the organization knows what evidence exists before the assessment begins.

Define the system boundary and scope
Identify every organizational system that stores, processes or transmits CUI, plus the supporting systems that can affect them, such as identity, logging, backup and management tools. The security owner and the system owners agree on this list and record it in the System Security Plan. Done when each in-scope system has a named owner and the boundary diagram shows where CUI enters, moves and is stored. Assessors will test the inventory against this boundary, so anything left out of it will be hard to justify later.
Build the inventory from discovery and agents
Combine automated discovery with agent-based collection to capture hardware, operating systems, installed software, firmware versions and network placement for each in-scope asset. Reconcile the discovered list against procurement records, hypervisor and cloud account listings, and network scans to find assets that lack an owner or appear only in one source. Open-source options such as GLPI Assets, Wazuh Syscollector and Fleet can collect or display this data, but the team must confirm each tool's coverage for its own platforms. Done when the inventory has one record per asset with an owner, location and status, and the unexplained gaps are closed or documented.
Document the approved baseline per system class
Group in-scope systems into classes, such as user workstations, servers, network devices, and CUI application hosts, and write one baseline for each class. Each baseline lists the approved software and versions, the configuration settings, and where the system sits in the network, including its segment and its permitted connections. Security and system engineering staff draft the baselines, and the system owner approves them. Done when every system in the inventory maps to exactly one baseline and any deviation is listed with a reason.
Capture firmware and supporting documentation
Record firmware versions for network devices, storage, firmware-bearing endpoints and any specialized equipment, then attach the architecture diagrams, configuration exports and installation guides that describe each class. Firmware is the component most often left out of baselines, so verify it against vendor release notes or the device's own management interface rather than memory. Done when every firmware-bearing asset in the inventory has a recorded version and each baseline points to the current documents that describe it.
Set the review and update cadence
Define how often the inventory and baselines are reviewed and who performs the review, and tie updates to the change control process so every approved change either updates the baseline or is rejected. The review schedule should be written into the configuration management plan and its records kept. Confirm the cadence with the assessor's expectations and your own change volume, because no fixed interval is set by the supplied requirement text. Done when the plan names the reviewers, the trigger events for an out-of-cycle update, and the records that will prove each review happened.
Reconcile and sign off the baseline
Run one final comparison between the inventory and the live environment to confirm that recorded software, settings and placement match what is deployed. Resolve differences by correcting the record or raising a change request, then have the system owner and the security lead sign the baseline package. Store the signed package, the reconciliation results and the review plan in a location the assessor can access. Done when the sign-off record is dated, every discrepancy has a disposition, and the package is in final form, because drafts do not satisfy the assessment objectives.

Evidence that satisfies CM.L2-3.4.1 and how to keep it current

Assessors test CM.L2-3.4.1 by reading documents and records, not by taking your word for the baseline. The cards below cover the artifacts they ask for and the habits that keep them accurate between assessments.

Configuration management plan

The plan states who owns the baseline, which system components it covers, how the inventory is built and reviewed, and how updates are approved. Assessors compare it with the other evidence to see whether the process described is the process actually run. Confirm that the plan names roles by function, lists the systems in scope, and carries a version history with an approval date. A plan that describes a tool no one uses will be questioned.

Baseline configuration documents

A baseline documents the approved hardware, operating system, software versions, firmware, and settings for each system type, along with where each system sits in the network. The baseline must be documented before it can be checked, so keep a dated copy for each approved build. Verify that every production system maps to a documented baseline and that exceptions are recorded rather than silently accepted.

System inventory exports with dates and owners

Inventory exports list hardware, software, firmware, and documentation components with an owner, location, and last-verified date for each item. Assessors often sample a few components and trace them back to a device or installation to confirm the inventory is accurate. Schedule exports from the discovery tool, store each with its date, and confirm that the owner field is filled in for every row.

Review and update logs

The requirement covers reviewing and updating the baseline and inventory throughout the development life cycle, so assessors look for dated records showing that someone checked them. A review log records the reviewer, the date, the scope, and any changes made. Keep entries even when nothing changed, since an empty review is still evidence that the review happened.

Architecture diagrams

Architecture and configuration diagrams show how components connect, where they sit, and which boundaries they cross. They give assessors context for the inventory and help them judge whether the inventory is complete. Check that diagrams match the current inventory and that each revision carries a date, because a diagram from a previous network design is a common finding.

Component install and removal records

Install and removal records show when each hardware or software component was added, changed, or retired, and who approved it. These records connect the baseline to change control and show whether the inventory keeps pace with reality. Require a record for every install and removal, and reconcile them against the inventory at each review so that decommissioned assets do not remain listed.

Producing inventory evidence with self-hosted open-source tools

GLPI is licensed under GPL-3.0-or-later and serves as the system of record for asset inventory. Its Assets module tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered by hand or pushed automatically by the GLPI Agent, which uses the native inventory built into GLPI since version 10. For 3.4.1, this gives you a central list of hardware and software that you can export, review and tie to a documented review cycle.

Hardware and network records: Keep asset type, location, owner and network details for each item in scope, including the boundary devices your system security plan describes.
Agent-driven collection: Confirm which endpoints run the GLPI Agent and how often inventory is pushed, so stale entries are visible.
Manual entries for out-of-band assets: Racks, printers and phones may need manual records. Document who updates them and when.
Review and update history: Assessors look for evidence that the inventory is reviewed and updated over time, so confirm how GLPI logs changes and where you store review sign-offs.
Gaps to confirm: Confirm how firmware versions and configuration documentation are recorded for each asset class in your environment, since the Assets module may not capture these without custom fields or linked documents.

Before relying on GLPI, check that its records reconcile with the system security plan and with the Wazuh and Fleet data from your endpoints.

What meeting CM.L2-3.4.1 costs in money and effort

This table lists the cost components of building and keeping a CM.L2-3.4.1 baseline and inventory, who is paid for each, and whether it is one-time or recurring. Use it to see where spend concentrates and which lines to ask about in a written quote. No dollar figures or durations are given because none were supplied for this requirement.

Cost component	One-time or recurring	Who is paid	What drives it up or down
Tooling and licenses	Recurring if commercial	Software vendor or reseller	Open-source inventory tools such as GLPI, Wazuh and Fleet can remove license spend, but hosting and support still apply. Confirm the license terms of each tool.
Hosting and infrastructure	Recurring	Cloud provider or data center team	Number of endpoints, retention period for inventory history, and whether the inventory store runs in the enclave with CUI.
Baseline build engineering	One-time, with periodic rework	Internal engineers or implementation partner	Number of distinct system images, hardware models and software stacks. Fewer, standardized builds cost less to baseline.
Initial inventory population	One-time	Internal IT staff or implementation partner	Heterogeneity of the fleet, undocumented legacy assets, and whether agents can be deployed automatically rather than entered by hand.
Inventory upkeep	Recurring	Internal operations staff	Rate of change, automated discovery through agents, and reconciliation against procurement and change records.
Documentation writing and review	One-time, then recurring updates	Internal system owners, compliance lead, or consultant	Number of components covered by the configuration management plan, and how often architecture diagrams change.
Independent review and partner fees	One-time or periodic	Consultant or implementation partner for readiness, and an assessor for formal review	Scope of the written statement of work. Ask whether the partner prepares evidence only, since assessors are independent and do not prepare it for you.
Assessor sampling effort	Recurring at each assessment	Assessor (C3PAO) and the organization's staff who produce samples	How quickly records can be pulled for sampled assets. Records that tie hardware, software, firmware and documentation together reduce assessor follow-up.

Where baselining usually fails an assessment

Most baselining failures come from records that look complete but cannot show approval, currency or coverage. The gaps below connect because an assessor tests the baseline, the inventory and the software list together, and a weakness in one usually surfaces when the others are checked.

Inventories missing firmware and documentation

Many inventories list servers, endpoints and installed applications but leave out firmware versions for network devices, storage controllers, BIOS and industrial controllers, and omit the documentation that describes each system. CM.L2-3.4.1 covers hardware, software, firmware and documentation together, so an inventory with one component type missing does not satisfy the objective. Before the assessment, sample ten devices from different asset classes and confirm each record shows firmware version and a link to its configuration documentation.

Baselines that were never approved

A baseline built by an administrator and saved to a shared folder is not an approved baseline. Assessors look for evidence that the baseline was reviewed by the people accountable for the system, with a recorded approval, a date and a version. Check that each baseline names an owner, shows an approval record, and was reviewed on the schedule the configuration management plan states. Where no approval exists, the gap is a missing review step, not a documentation detail, and it should be closed before the assessment rather than explained afterwards.

Software lists disconnected from the baseline

Organizations often keep a software inventory in one tool, a baseline document in another and an allowed-software list in a third, and the three drift apart. The CMMC Assessment Guide notes that CM.L2-3.4.8 relies on the software inventories kept under CM.L2-3.4.1, so a stale inventory weakens later requirements too. Reconcile the software inventory against the baseline for a sample of systems and record every product that appears in one place but not the other, along with the decision made about it.

Cloud and virtual assets outside scope

Virtual machines, containers, managed databases and cloud services often appear in a provisioning pipeline but not in the system inventory that the assessment uses. An assessor who finds a running instance absent from the inventory will question the completeness of every other record. Ask the cloud and platform team for a list of accounts, subscriptions and clusters that handle CUI, then compare it against the inventory boundary in the system security plan. Confirm that ephemeral assets are captured through automated discovery, not manual entry.

Draft records presented as final

Assessors accept evidence only in final form, and a requirement is MET only when all applicable objectives are satisfied with final evidence. A baseline marked draft, an inventory exported from a working copy or a configuration plan with unresolved comments can each fail an objective even when the underlying work is sound. Before the assessment, review each record for version status, open comments and tracked changes, then finalize, sign and date it. Keep prior approved versions so the history of changes is traceable.

Who owns baselining, what partners outsource, and where the assessor stops

Your organization owns CM.L2-3.4.1. That means the baseline configurations and system inventory are your decisions, approved by people with authority over the system, and kept current as the environment changes. No outside party can accept responsibility for your baseline on your behalf. Assessors will ask who approved each baseline and when it was last reviewed, so the answers need to come from your own staff.

Approving baselines: Named owners sign off on the configuration of each system type, including software, configuration settings and network placement.
Owning the inventory: Someone in your organization decides what counts as a system component and what must be recorded for hardware, software, firmware and documentation.
Keeping review records: Scheduled and event-driven reviews of baselines and inventories are logged, with dates and reviewers.
Maintaining the CMP: The configuration management plan and the system security plan reflect the baseline as it actually exists.
Running the environment: Your administrators build systems from the approved baseline and record deviations.

Before any assessment, confirm that every baseline and inventory record has an accountable owner and a documented review date.

How much effort and outside help does CM.L2-3.4.1 need?

Can our team build the CM.L2-3.4.1 baseline and inventory in-house?

Yes, most teams with an IT or platform group can build the baseline and inventory themselves, provided someone owns the work and the records are kept current. The requirement asks for baseline configurations and inventories of hardware, software, firmware and documentation, so the first job is deciding which systems fall inside the CUI boundary. Your team owns the baseline, and any outside help prepares systems and evidence. Only a C3PAO or the assessor issues a result, so the in-house question is about capacity and discipline, not authority.

What drives the effort needed for CM.L2-3.4.1?

The main drivers are the number of systems in scope, how many different hardware and software sources exist, and how much documentation is already written down. Effort rises when inventories are split across spreadsheets, procurement records and endpoint tools that do not agree. Architecture and network documentation also takes time, because the assessment objectives look for baseline configurations that show software, settings and placement. Specialized assets such as operational technology or test equipment add discovery work. Ask any partner to price these drivers separately in a written, fixed scope.

When should we bring in an outside partner for the baseline?

Bring in a partner when the environment is large, mixed or poorly documented, or when your team cannot dedicate staff to discovery and reconciliation. A partner can help consolidate inventory sources, deploy open-source collection tools inside your own infrastructure and document the baseline for review. Under the CMMC model, the partner prepares systems and evidence but does not decide compliance. Keep the baseline owned internally so that staff can maintain it after the engagement ends.

How does the MET-only rule change our planning for CM.L2-3.4.1?

CM.L2-3.4.1 is worth 5 points, and under the CMMC Scoring Methodology it cannot be placed on a POA&M because it is worth more than 1 point. If it is NOT MET, it reduces the score from the maximum of 110, and the system cannot reach Conditional or Final Level 2 status without it being MET. This means the baseline must be complete and evidenced before the assessment, not planned as a remediation item. Build the baseline early in your schedule because other configuration requirements depend on it.

How often must the system inventory and baseline be reviewed?

The requirement calls for reviewing and updating both the baseline and the inventory throughout the system development life cycle, so the schedule must be set in your own configuration management plan. Assessors look for review and update records, not a specific interval named in the requirement. Define a cadence that matches how often your systems change, and tie reviews to change records and component installation or removal records. Confirm the expected review frequency with your assessor before the assessment.

What should we confirm with a Level 2 assessor about CM.L2-3.4.1?

Confirm which assessment objects the assessor will accept as evidence, including the configuration management plan, inventory records, architecture documentation and change records. Ask how the assessor expects draft versus final documents to be handled, since evidence must be in final form for a requirement to be MET. Also confirm how cloud-hosted and managed components are inventoried, and which parts of the boundary are in scope. Get these answers in writing before you finalize the baseline, because an assessor's view on scope shapes the whole effort.

Which open-source tools can help build and keep the inventory current?

GLPI can hold hardware, software and network asset records and receive data from its agent, Wazuh Syscollector collects hardware, operating system, installed software, services and users from endpoints into dashboard reports, and Fleet can answer yes or no policy questions about devices. Each tool produces inventory data, but none replaces the baseline document or the review records. Confirm with your assessor which combination of tool output and written records they will accept. Verify each tool's coverage in your own environment before relying on it.

How DeployOpen scopes and prepares baseline evidence

DeployOpen plans, builds and documents the baseline configurations and inventories that CM.L2-3.4.1 asks for, inside your own infrastructure. Your organization owns the baseline and the assessment outcome, and an independent assessor reviews the evidence.

How we scope

Written scope lists which systems, hardware, software, firmware and documentation fall inside the baseline.
We confirm where your configuration management plan and inventory records already exist and what needs to be created.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.

How we build

We deploy inventory tooling such as GLPI, Wazuh Syscollector, Fleet or Kyverno reports in your environment to collect component data.
We document approved baseline configurations, including software versions, settings and network placement, for each system class.
We test that inventory records match the live environment and that review and update procedures run as written.

How we hand over

Handover includes baseline documents, inventory exports, review records and the configuration management plan in editable form.
We map each deliverable to the 3.4.1 assessment objectives so your team can show assessors where each one is met.
Your staff receive a walkthrough of how to update the baseline and inventory after changes and at scheduled reviews.

How we support

Retainers can cover scheduled inventory reviews, baseline updates and tooling upgrades after the initial handover.
We keep records in final form so drafts never stand in for evidence an assessor will examine.
Confirm with your assessor and sponsor which evidence formats and review cadence they accept before the engagement begins.