CMMC Level 2 Practice 3.4.1: Establish and maintain baseline configurations and inventories of organizational systems

CMMC Level 2 inherits NIST SP 800-171 Rev. 2 practices, and 3.4.1 is one of the fastest ways an assessment can stall: the assessor asks “show me your baseline and inventory,” and the team produces a spreadsheet with unclear scope, no ownership, and no tie to actual configuration enforcement. The requirement is straightforward, but it crosses tools and teams: IT operations, security engineering, endpoint management, cloud, and sometimes OT all touch “configuration,” while asset management and procurement influence “inventory.”

Treat 3.4.1 as two deliverables that you continuously operate: (1) baseline configurations for each system category in your CUI environment, and (2) a living system inventory that reflects reality. Your goal is not perfect documentation. Your goal is to show an assessor that you know what systems process/store/transmit CUI, you have an approved secure configuration for them, you control changes, and you can produce evidence on demand. CMMC assessments reward clarity: a clean scope boundary, a small number of standard builds, and simple, recurring reports. ¹

Regulatory text

Requirement mapping (CMMC Level 2 / NIST SP 800-171 Rev. 2 3.4.1): “Establish and maintain baseline configurations and inventories of organizational systems.” ²

Operator meaning: you must (a) define the approved configuration state for the systems you run (baseline), and (b) maintain an accurate list of those systems (inventory). “Maintain” implies ongoing operation: updates when systems change, periodic review, and evidence that the baseline is enforced or at least monitored for drift. CMMC Level 2 assessments are performed under the CMMC Program, so your implementation must be assessable and evidence-backed. ³

Plain-English interpretation

• Baseline configuration = the “known-good” settings and software state you intend systems to have (OS version, security settings, required agents, logging configuration, approved services, hardened cloud configurations, etc.).
• Inventory = a current list of organizational systems (hardware, virtual, cloud resources where they function as “systems”) that are in scope, with enough attributes to manage and protect them (owner, location, purpose, environment, CUI relevance).

If you cannot reliably answer “what systems are in our CUI boundary?” you will struggle to prove almost every other CMMC practice. 3.4.1 is the foundation for patching, vulnerability management, access control, incident response tooling coverage, and audit logging coverage. ²

Who it applies to

Entity types: defense contractors and other federal contractors that handle Controlled Unclassified Information (CUI) and need CMMC Level 2. ³

Operational context (where teams get tripped up):

• Mixed environments: on-prem AD + Microsoft 365 + IaaS/PaaS.
• Multiple device populations: corporate endpoints, engineering workstations, build servers, jump hosts.
• Shared services: MSP-managed infrastructure, SaaS where configuration is split between provider and customer, and subsidiaries with inconsistent builds.

If a system can access, store, process, or transmit CUI, it belongs in the inventory and must have a defined baseline or a documented exception path. ²

What you actually need to do (step-by-step)

1) Define scope and system categories (so you don’t baseline “everything”)

1. Confirm your CUI boundary: list networks, tenants, enclaves, and major workflows that touch CUI.
2. Group systems into manageable categories (examples): Windows endpoints, privileged admin workstations, Linux servers, Windows servers, network devices, cloud accounts/subscriptions, container hosts, key SaaS configurations.
3. Assign control owners: one owner per category (IT ops, cloud platform, network team). Put names in the procedure, not “IT.”

Deliverable: “System categorization + ownership” page in your SSP/control narrative that points to the baseline and inventory artifacts. ²

2) Build the inventory you can defend in an assessment

Minimum inventory fields that stand up well in CMMC interviews:

• Unique asset ID (or hostname/resource ID)
• Asset type/category
• Owner (person/team)
• Environment (prod/dev), location, and business function
• CUI relevance (in scope / out of scope) with a short rationale
• Management plane (Intune/SCCM, MDM, EDR console, hypervisor, cloud CMDB, etc.)
• Last seen / last check-in date from an authoritative tool

Practical tip: prefer system-of-record exports (EDR/MDM/cloud inventory) over hand-maintained spreadsheets. If you must use a spreadsheet, back it with recurring exports and reconciliation notes.

Deliverable: versioned inventory export + reconciliation log. ²

3) Define “baseline configurations” as standards you can measure

For each system category, publish a baseline that includes:

• Build standard: OS and minimum version policy; required software/agents (EDR, log forwarder, disk encryption).
• Security configuration: password/lock policies, firewall, disable unnecessary services, admin rights model.
• Logging/auditing defaults aligned to your logging controls.
• Network/security tooling requirements: DNS, time sync, certificate settings.

Write baselines as:

• A short “baseline standard” document (human-readable), plus
• A “technical implementation” in tooling (GPO/Intune policies, CIS-style settings profile, configuration scripts, IaC templates, hardened images).

Deliverable: baseline standard + configuration profiles/templates + approval record. ²

4) Put change control around baselines (otherwise “maintain” fails)

You need a simple, consistent mechanism:

• Change request (ticket) required for baseline changes.
• Risk review for material changes (security impact statement).
• Approval from baseline owner + security (or CISO delegate).
• Implementation evidence: commit history for IaC, policy change logs, or ticket closure notes.
• Emergency change path with retrospective approval.

Deliverable: change management procedure section specific to baseline changes + sample tickets. ²

5) Detect and correct configuration drift

Assessors commonly ask: “How do you know systems match your baseline?” Use one or more:

• MDM/GPO compliance reporting (endpoints/servers)
• EDR posture/compliance checks (where supported)
• Cloud policy-as-code and config rules (CSPM) with alerts
• Periodic configuration scans and remediation tickets

Deliverable: compliance report screenshots/exports + drift remediation tickets + exception register. ²

6) Operational cadence and recurring evidence capture

Set a repeatable cadence that your team can sustain:

• Inventory reconciliation (adds/removes, ownership changes)
• Baseline review (updates driven by patch cycles, new threats, new business apps)
• Sampling verification (spot-check systems for compliance)

If you use Daydream to manage CMMC readiness, map 3.4.1 directly to (1) a control narrative, (2) baseline artifacts per system class, and (3) recurring evidence tasks with owners and due dates. That mapping reduces “we have it somewhere” scramble time during assessment interviews. ¹

Required evidence and artifacts to retain

Use this as your evidence checklist for 3.4.1:

Baseline configuration evidence

• Baseline standards per system category (dated, versioned)
• Secure build technical artifacts: GPO/Intune profiles, scripts, golden image specs, IaC modules
• Baseline approval records (change tickets, CAB minutes, email approval captured to ticket)
• Exceptions register (what deviates, why, compensating controls, expiration/review date)

Inventory evidence

• Authoritative exports from MDM/EDR/CMDB/cloud platform inventories
• Inventory data dictionary (what fields mean, who updates)
• Reconciliation notes (how you handle duplicates, stale devices, decommissioned assets)
• Decommission records (tickets showing removal from service and inventory)

Operating evidence

• Drift/compliance reports
• Remediation tickets and closure evidence
• Periodic review meeting notes or attestation by system owners

Keep evidence in a single assessment-friendly repository with consistent naming. Assessors reward “show me” speed. ⁴

Common exam/audit questions and hangups

Expect these and pre-answer them in your control narrative:

• “What is your authoritative inventory source?” (Pick one per asset class.)
• “How do you know this inventory is complete?” (Explain discovery + reconciliation.)
• “Show your baseline for Windows endpoints and prove it’s enforced.” (Bring policy + compliance report.)
• “What is your process to update baselines?” (Show change ticket trail.)
• “How do you handle assets owned by third parties (MSP, cloud provider, SaaS)?” (Document shared responsibility and what you configure vs what they manage.) ¹

Frequent implementation mistakes and how to avoid them

1. Spreadsheet-only inventories with no authoritative feed. Fix: back spreadsheets with exports from EDR/MDM/cloud, and document reconciliation.
2. One giant baseline document for every system. Fix: create category baselines; keep each baseline short and enforceable.
3. Baselines defined but not implemented in tooling. Fix: tie every baseline section to a real control mechanism (policy profile, template, script).
4. No exception process. Fix: keep an exception register with owner, justification, compensating control, and review date.
5. Scope confusion (CUI vs corporate). Fix: tag inventory items “CUI in-scope” and document boundary logic in the SSP. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this specific practice. Practically, 3.4.1 failures increase the chance of broader CMMC assessment findings because assessors cannot validate other practices without a trustworthy inventory and baseline story. Under the CMMC Program, you should assume assessability is part of the requirement outcome. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and create assessable artifacts)

• Confirm CUI boundary and define system categories with named owners.
• Generate initial inventory exports from authoritative systems (EDR/MDM/cloud) and reconcile duplicates.
• Draft baseline standards for the highest-risk categories (endpoints, admin workstations, servers) and get approval records started.
• Stand up an exceptions register template and require tickets for deviations.

Days 31–60 (implement enforcement and drift detection)

• Convert baseline standards into technical controls (MDM profiles, GPOs, hardened images, IaC).
• Turn on compliance reporting for baseline settings; define what “noncompliant” triggers (ticket, quarantine, or remediation SLA).
• Add inventory updates into joiner/mover/leaver and procurement workflows (new assets must be tagged, owned, and categorized).

Days 61–90 (operate it like a control, not a project)

• Run a full inventory reconciliation cycle and document results.
• Perform a baseline review and record changes through tickets.
• Prepare an assessor-ready evidence packet: baselines, exports, drift reports, sample remediation tickets, exception register.
• If you use Daydream, configure recurring evidence tasks for inventory exports, drift reports, and baseline review approvals to remove manual chasing. ¹

Frequently Asked Questions

Does 3.4.1 require a specific tool (CMDB, Intune, SCCM)?

No tool is mandated in the requirement text. Assessors care that your inventory and baseline are accurate, maintained, and supported by evidence you can reproduce. ²

Are cloud resources “organizational systems” that must be inventoried and baselined?

If the cloud resources store, process, or transmit CUI, treat them as in-scope systems and baseline the relevant configurations (identity, logging, network controls, encryption). Use your cloud provider inventory exports and policy rules as evidence. ²

How detailed does a baseline configuration need to be?

Detailed enough that you can test compliance and detect drift. If a baseline statement cannot be measured (by policy, report, or scan), it will be hard to defend in an assessment. ²

What’s the cleanest way to prove the inventory is current?

Use automated exports from authoritative tools (EDR/MDM/cloud) and keep dated snapshots. Add a reconciliation note that explains removals (decommissions) and additions (new deployments). ²

How should we handle third-party managed systems (MSP-managed servers or SaaS)?

Inventory them with clear ownership and document which configuration elements you control versus the third party. For baselines, define the settings you require (for example, logging, MFA, admin model) and keep evidence of configuration and oversight. ¹

What do assessors usually flag under 3.4.1?

Missing scope clarity, inventory that does not match reality, baselines without approvals, and no proof of enforcement or drift remediation. Prepare sample reports and tickets that show the control operates over time. ¹

Footnotes

1. DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. 32 CFR Part 170; Source: DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; Source: DoD CMMC Program Guidance