Configuration Management Baselines for CMMC: Aligning to CIS and DoD STIGs

CMMC Level 2 puts configuration work at the center of your CUI program. You need a baseline that names versions and settings, you need an inventory that stays current, and you need a process that enforces secure configurations and manages change. CIS Benchmarks and DoD STIGs can guide hardening choices, but you still need scope, tailoring, approvals, and evidence that match your systems.

CMMC Level 2 configuration outcomes

DoD CIO materials tie Level 2 to NIST SP 800-171 Revision 2. The CMMC Model Overview and Assessment Guide call for Configuration Management practices that pull together baselining, secure settings, change control, least functionality, software control, and inventory updates.

Two practices anchor the baseline and settings work:

• CM.L2-3.4.1, establish and maintain baseline configurations and inventories of organizational systems, including hardware, software, firmware, and documentation.
• CM.L2-3.4.2, establish and enforce security configuration settings for IT products used in organizational systems.

Related practices connect to that foundation:

• CM.L2-3.4.3 and CM.L2-3.4.4, track, review, approve or disapprove, and log changes, and analyze and report change impact.
• CM.L2-3.4.10, update the system component inventory during installs, removals, and updates.

NIST SP 800-171 Rev. 2 defines a baseline as a documented and agreed specification for a system or configuration item. The CMMC Assessment Guide expands on that with assessment considerations that include versions, patch levels, configuration parameters, network information, and connections to other systems. DoD organization-defined parameters instruct organizations to review and update baselines at least every 12 months and after significant incidents or significant changes. The same DoD parameters require documented and approved deviations from secure settings and expect the most restrictive mode that still meets mission needs.

NIST withdrew Rev. 2 and issued Rev. 3. The cited CMMC Level 2 documents still reference Rev. 2. Check your contracts and current DoD guidance before you shift references in your policy stack.

CIS Benchmarks and DoD STIG roles

CIS Benchmarks and DoD STIGs give you vetted hardening guidance. They cover host operating systems, databases, applications, and network gear. They map to secure configuration principles that CMMC calls for, and they speed up setting selection.

DoD and NIST sources do not say that a STIG or a CIS Benchmark, by itself, proves a CMMC practice. You still need to:

• Choose the right reference for each technology and version, then tailor settings for your CUI boundary and business function.
• Document risk-based deviations, obtain approvals, and protect those changes in your configuration process.

A STIG often assumes a DoD enclave and may set controls beyond the needs of a small DIB system. A CIS Benchmark may align with commercial use and leave gaps against DoD expectations. Treat both as inputs to your baseline, not as substitutes for your own implementation and evidence.

Baseline definition and asset inventory

You control the baseline. You decide scope, sources, and approval flow, then you keep it current. The Assessment Guide points to specific content. Build your baseline so an assessor can see the system, its settings, and its connections without guessing.

Include at least these elements for each system or system type:

• Identifiers and versions, hardware models, OS and application versions, and current patch level.
• Configuration parameters that implement your selected CIS or STIG settings, plus the network role and any connections to external or partner systems.

Tie baselines to an inventory that reflects the CMMC Level 2 Scoping Guide. The Scoping Guide expects an asset inventory by category and a network diagram that shows the assessment boundary. DoD parameters call for updating the inventory during installs, removals, and updates. Build that update into your change process so the inventory and the baseline move together.

Two scope anchors keep the work focused:

• The asset categories in the Scoping Guide, which set what you must baseline and harden inside the CUI boundary.
• The System Security Plan, which describes the system, the boundary, and the configuration processes that support the practices.

Map your baseline and inventory to your SSP. If you need a refresher on how the mapping works, see NIST 800-171 and CMMC Level 2 Mapping and System Security Plan for NIST 800-171.

Exception handling and change control

Secure configuration work always meets edge cases. Some settings break a needed capability. Some vendor defaults resist change. You need a small set of guardrails so deviations do not sprawl.

Build two simple paths and enforce them:

• A deviation path. You document the setting, the business need, the risk, the compensating control, the expiration or review date, and the approval. DoD parameters expect identification, documentation, and approval of deviations from secure settings.
• A change path. You track, review, approve or disapprove, and log changes as CM.L2-3.4.3 requires, and you analyze and report impact as CM.L2-3.4.4 requires.

Both paths should update the baseline and the inventory. Both should feed your vulnerability and patch processes. If a deviation creates exposure, your risk register and your POA&M process should reflect it. For program handling, see POA&M Management for CMMC.

Review cadence and ongoing maintenance

DoD organization-defined parameters set the floor for baseline review. Review and update your baselines at least once per year, and after significant incidents or significant changes. That cadence keeps your settings in step with vendor releases and threat shifts.

Make the cadence visible and auditable:

• Maintain an annual review schedule that names owners, in-scope systems, and due dates, then record completion and outcomes.
• Trigger out-of-cycle reviews for significant events, and record the event, the findings, and any baseline updates.

Map reviews to your version control. Each baseline revision should carry a date, an owner, a change summary, and a link to approvals. Use the same discipline on your inventory so a reader can match a baseline revision to a snapshot of the environment at that time.

Assessment evidence and scope readiness

A C3PAO will validate scope early, review your SSP, and then assess conformity to the practices. The CMMC Assessment Process describes that flow. You help that process by producing clear, scoped evidence that aligns to the assessment objectives in the Level 2 Assessment Guide.

Build a package for each in-scope system type that includes:

• The approved baseline document or profile, the settings source you used, and the tailored settings list with deviations and approvals.
• Implementation evidence that your fleet enforces the baseline, for example configuration management platform policies and their deployment state, and spot checks or automated reports that show active settings on assets within the boundary.

Tie the package to scope artifacts. The Scoping Guide expects an asset inventory by category and a network diagram of the boundary. Your evidence should reference the same identifiers and the same diagram so an assessor can trace from requirement to system to proof without guesswork.

Two pitfalls cause rework:

• A generic enterprise baseline that does not match the CUI boundary. Build a boundary-specific baseline or add a boundary overlay that tightens settings where needed.
• A tool report without process and approvals. A scan or a policy export helps, but the practice expects a maintained baseline, enforcement, and change control with human decision points.

Practical alignment steps

You can get value from CIS and STIGs without overreaching. Pick the right source per platform and version, then drive to an approved baseline that you can enforce and maintain.

Use this short two-step loop on each platform:

• Selection and tailoring. Choose the CIS Benchmark or the STIG that fits your version. Tailor settings to meet CM.L2-3.4.2, identify and document deviations, and obtain approvals that match your change authority model.
• Enforcement and verification. Deploy the settings through your configuration tools, then verify on a sample of in-scope assets and record the results with dates and system identifiers.

Keep the loop tied to the Scoping Guide’s asset categories. As you add or retire assets, update the inventory and associate the right baseline. That linkage satisfies CM.L2-3.4.1 and CM.L2-3.4.10 and gives you a clean audit trail.

Sources

CMMC Level 2 Assessment Guide (DoD CIO)
CMMC Model Overview Version 2 (DoD CIO)
CMMC Scoping Guide Level 2 (DoD CIO)
Organization-Defined Parameters for NIST SP 800-171 (DoD CIO)
NIST SP 800-171 Rev. 2 (NIST)
NIST SP 800-171 Rev. 2 status page (NIST)
CMMC Assessment Process v2.0 (The Cyber AB)