What is required for configuration baselines and change management?

Configuration management is the family that determines whether your environment matches your SSP — if the baseline drifts and the SSP doesn't reflect it, the assessor will find the divergence within hours of starting Examine.

The nine CM practices

Baseline configurations (CM.L2-3.4.1, CM.L2-3.4.2)

Industry baselines that contractors commonly use as starting points:

• CIS Benchmarks — widely used cross-platform baselines.
• DISA STIGs — the DoD-specific configuration baselines.
• Microsoft Security Baselines — for Windows endpoints and servers, Edge, Office, and Microsoft 365.
• Cloud-native security recommendations — AWS Trusted Advisor, Azure Security Center, Defender for Cloud.

Tailor the baseline to the OSA's environment, document the deviations and their justifications, and enforce via your configuration management toolchain — Group Policy, Intune, JAMF, Ansible, Puppet, Chef, SCCM, AWS Systems Manager, Azure Policy, or equivalent depending on the platform. The SSP must reference the baseline and the deviations.

Change management (CM.L2-3.4.3, .4, .5)

Per the assessment objectives:

• Changes are tracked through a defined process (ticketing, change records).
• Changes are reviewed before implementation.
• Changes are approved or disapproved by designated personnel.
• Logged with date, requester, approver, change description.
• Security impact is analyzed before implementation (CM.L2-3.4.4).
• Access restrictions are enforced — only authorized personnel can make changes (CM.L2-3.4.5).

Application control (CM.L2-3.4.8, CM.L2-3.4.9)

3.4.8 requires either allowlisting (deny-by-default) or denylisting (permit-by-default with deny exceptions). Allowlisting is the stronger position and increasingly expected. Implementation depends on the platform — Microsoft Defender Application Control, AppLocker, third-party application control products on Windows; Gatekeeper and notarization on macOS; SELinux/AppArmor and package management policies on Linux; managed-app catalogs on mobile platforms. 3.4.9 separately requires controlling and monitoring user-installed software, which usually means restricting local admin and using software inventory tools.

What the assessor will examine

• SSP description of the baseline configuration for each in-scope system class.
• Asset inventory matching the SSP.
• Configuration enforcement evidence from your configuration management toolchain (MDM compliance reports, GPO RSoP outputs, Ansible / Puppet / Chef run reports, configuration scan results, cloud-policy compliance reports).
• Change records demonstrating the change management process operating.
• Software inventory and allowlisting/denylisting evidence.
• Privileged access controls limiting who can make changes.

Common errors

• Documented baseline that the systems don't actually meet. The most common CM finding — SSP says one thing, RSoP shows another.
• No security impact analysis for changes. Tickets that go straight to implementation without documented review fail 3.4.4.
• No application allowlisting or denylisting. 3.4.8 is explicit; some level of application control is required.
• Local admin privileges that allow user-installed software. Conflicts with 3.4.9 — if users can install whatever they want, the OSA isn't controlling user-installed software.
• Hardware and software inventory drift. The CM inventory must match what's actually deployed; assessors cross-reference against network scans.