03.04.02: Configuration Settings

To meet the 03.04.02: configuration settings requirement, you must define approved secure configuration settings for in-scope systems that process, store, or transmit CUI, implement them consistently, control and document any deviations, and keep evidence that settings remain enforced over time. Treat it as a repeatable configuration baseline plus change control and monitoring. ¹

Key takeaways:

• Define and approve secure configuration baselines per system/role, then deploy them through managed configuration tooling.
• Control drift with monitoring, exception handling, and configuration change governance tied to tickets and approvals.
• Keep assessor-ready evidence: baselines, change records, scans, and screenshots/exports that prove settings are enforced. ¹

03.04.02 is the control that makes your “secure build” real in day-to-day operations. Policies that say “systems are securely configured” do not pass an assessment by themselves; assessors look for a defined baseline, proof it was applied, and proof it stays applied. In practice, teams fail this requirement for two reasons: they cannot clearly state what the approved configuration settings are for each environment, or they cannot produce evidence that settings are consistently enforced and controlled when changes occur.

This page is written for a CCO, GRC lead, or compliance owner supporting engineering and IT. Your goal is to translate 03.04.02 into a small set of operational mechanics: (1) configuration standards/baselines, (2) technical enforcement (GPO/MDM/IaC/etc.), (3) change control and exceptions, and (4) continuous verification with durable evidence. The result is not “perfect hardening.” The result is demonstrable governance over configuration settings for CUI-scoped systems and a record that survives turnover, tool changes, and assessor sampling. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.04.02 (Configuration Settings).” ¹

Operator interpretation: You need an approved set of configuration settings for in-scope assets (systems and components that handle CUI) and you must implement, manage, and verify those settings. The assessment focus is typically: “Show me your baseline,” “Show me it’s enforced,” and “Show me how you prevent or detect drift and handle exceptions.” ¹

Plain-English interpretation (what 03.04.02 expects)

03.04.02 expects you to:

• Decide what “secure configuration” means for each relevant platform (Windows endpoints, Linux servers, network devices, cloud services, containers, SaaS admin consoles).
• Write it down in a baseline that is specific enough to test (not “strong passwords,” but the actual settings you require).
• Roll it out consistently using managed configuration methods.
• Control change so settings do not shift informally.
• Prove it with evidence you can hand to an assessor without heroics. ¹

Who it applies to

Entity scope

Applies to federal contractors and other organizations operating nonfederal systems handling CUI where NIST SP 800-171 Rev. 3 is the required framework. ¹

Operational scope (what assets get pulled in)

Include any technology that can affect the confidentiality of CUI, such as:

• Endpoints used to access CUI (managed laptops/desktops, VDI).
• Servers and infrastructure hosting CUI workloads (on-prem and cloud IaaS).
• Identity and access systems that enforce settings (directory services, MDM).
• Network/security devices enforcing system behavior (firewalls, VPN, DNS security).
• Administrative planes for cloud and SaaS where configuration settings materially affect CUI handling. ¹

A practical scoping rule: if the component is part of the CUI boundary, or can administer/alter systems in the boundary, it needs an applicable baseline and evidence.

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

Step 1: Name the “configuration authority” and the lifecycle

Assign clear ownership:

• Control owner (GRC/Compliance): defines evidence expectations, sampling readiness, and review cadence.
• Technical owners (IT/Sec/Cloud/Network): author baselines, implement controls, and remediate drift.
• Change manager / CAB (formal or lightweight): ensures changes are reviewed, approved, and recorded.

Deliverable: a short RACI in your configuration management standard that maps who approves baselines and exceptions.

Step 2: Inventory in-scope platforms and pick baseline formats

Create a list of in-scope platform categories, then choose how you will express baselines:

• Windows: GPO/Intune settings export plus a written standard.
• Linux: CIS-style settings list plus Ansible/Salt/Puppet code or validated configuration files.
• Cloud: policy-as-code or configuration rules plus account/project/org guardrails.
• Network: “golden config” templates plus device configuration backup records.

Deliverable: a “Baseline Register” (table) that maps each platform to the baseline document, enforcement method, and evidence source.

Step 3: Define the configuration baseline (testable, not aspirational)

Write baselines in a way that supports sampling. A baseline should include:

• Scope (which systems, environments, roles).
• Required settings (explicit, measurable).
• Rationale (brief).
• How to validate (command, query, console path, or control report).
• Exception path (what qualifies, who approves, expiry/compensating control).

Example baseline items (keep them measurable):

• “Local admin group membership is restricted to approved support groups.”
• “Audit logging is enabled for authentication and privilege changes.”
• “Remote management requires MFA and uses approved protocols.” Tie each item to how you’ll prove it.

Deliverable: versioned baseline documents with approval.

Step 4: Implement enforcement through managed mechanisms

Assessors expect scalable enforcement, not manual one-offs. Implement through:

• Endpoint management (MDM) and directory policy.
• Configuration management (Ansible/Puppet) for servers.
• Infrastructure-as-code with code review for cloud resources.
• Central guardrails for cloud org/account settings.
• Standard images (golden images) plus build pipelines that lock settings.

Deliverable: implementation records that show baselines were deployed (policy assignments, code repos, pipeline logs, MDM profiles).

Step 5: Establish configuration change control and exception handling

Define minimum governance:

• Changes to baseline settings require a ticket with risk/impact and approval.
• Emergency changes allowed, but must be documented and reviewed after.
• Exceptions must have: business justification, compensating controls, owner, and an expiry or review trigger.

Deliverable: an “Exception Register” and change tickets linked to baseline versions.

Step 6: Monitor for drift and remediate

Configuration settings decay. Prove you detect and correct drift:

• Run scheduled configuration compliance checks (MDM compliance, server config checks, cloud config rules).
• Track findings to closure with tickets.
• Produce periodic compliance reports by platform.

Deliverable: drift reports, scan outputs, remediation tickets, and closure evidence.

Step 7: Make it assessment-ready (sampling pack)

Build a repeatable assessor packet:

• Baseline Register.
• Baseline docs (current and prior versions).
• For each sampled system: proof of applied configuration (export/screenshot/log output) and proof of monitoring (latest compliance report line item).

This prevents last-minute screenshot hunts.

Required evidence and artifacts to retain

Keep evidence that covers design, implementation, and operation:

Governance artifacts

• Configuration Management / Secure Configuration Standard.
• Baseline approval records (sign-off or ticket approvals).
• RACI for baseline ownership and change approval.

Technical artifacts (by platform)

• Baseline exports (GPO/MDM profile exports, config templates, golden images identifiers).
• IaC repositories and merge approvals for baseline-related code.
• Cloud org/account policy settings exports and configuration rule sets.
• Network device “golden config” templates and configuration backup snapshots.

Operational artifacts

• Change tickets for baseline changes, with approvals and test notes.
• Exception Register with expiry/review outcomes.
• Drift/compliance monitoring reports and remediation tickets tied to specific settings.
• Evidence maps that show where each baseline control is proven (a control-to-evidence matrix).

Daydream tip: store these in one control record with a recurring evidence request schedule, so each month/quarter you collect “fresh” proof rather than scrambling during an assessment.

Common exam/audit questions and hangups

Assessors commonly probe:

• “Show me your approved configuration baseline for this system type.” (They expect specificity.)
• “How do you enforce it?” (Manual checklists usually draw follow-ups.)
• “How do you know it stays configured?” (They want drift detection.)
• “How do you handle exceptions?” (They want governance, not tribal knowledge.)
• “Pick one endpoint/server and prove these settings are in place.” (They will sample.)

Hangups that slow teams down:

• Baselines exist but are not versioned or approved.
• Evidence exists but is not tied to the baseline (no mapping from requirement to proof).
• Monitoring reports exist but don’t show coverage of the CUI boundary.

Frequent implementation mistakes (and how to avoid them)

1. Writing baselines as vague principles.
   Fix: require test steps for each setting. If you cannot test it, rewrite it.

2. Relying on golden images without drift control.
   Fix: add ongoing compliance checks and remediation tickets tied to findings.

3. Exceptions granted in email/Slack.
   Fix: route exceptions through a register with explicit expiry/review and compensating controls.

4. No linkage between change control and baseline versions.
   Fix: every baseline change increments a version and references a change ticket.

5. Treating cloud as “different.”
   Fix: define cloud configuration settings at the org/account and workload levels, then export settings for evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should plan from an assessment-readiness angle rather than a case-law angle.

Operational risk is straightforward: inconsistent configuration settings create predictable openings (misconfigurations, excessive privileges, weak logging) that undermine CUI protection obligations. The compliance risk is equally concrete: if you cannot show a baseline, enforcement method, and drift/exception governance, 03.04.02 will be scored as not met during an assessment. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Confirm CUI boundary and list in-scope platforms.
• Publish a Configuration Settings Standard with ownership and approval flow.
• Create the Baseline Register and draft baselines for the highest-risk platforms (endpoints, identity, core servers, cloud org settings).
• Stand up an Exception Register and require it for any current deviations.

Days 31–60 (implement and connect evidence)

• Implement enforcement for drafted baselines (MDM/GPO, config management, IaC guardrails).
• Link baseline changes to ticketing and approvals.
• Define “assessor packet” evidence templates per platform (what to export, where stored, naming conventions).
• Pilot a drift check report and ticket workflow for remediation.

Days 61–90 (operationalize and harden)

• Expand baselines to remaining platforms in scope (network, databases, container platforms, admin consoles).
• Run drift monitoring on a recurring schedule and track closure for findings.
• Perform an internal sample test: pick a few systems and produce end-to-end evidence in one hour.
• Move recurring evidence collection into Daydream (or your GRC system) with owners, due dates, and a consistent evidence format, so you can show ongoing operation without manual coordination.

Frequently Asked Questions

What counts as a “configuration setting” for 03.04.02?

Any system or service option that changes security behavior, such as authentication settings, logging configuration, encryption settings, admin controls, remote access configuration, and cloud account guardrails. If a setting affects the confidentiality of CUI or administrative control over CUI systems, treat it as in scope. ¹

Do I need one baseline for every system?

You need baselines that cover each platform and role consistently (for example, “Windows endpoint baseline” and “Linux server baseline”). You can allow documented variants, but each variant needs defined settings, approval, and evidence.

Are screenshots acceptable evidence?

Screenshots can work for a sample, but they are weak at scale and hard to repeat. Prefer exports, policy configuration reports, and tool-generated compliance outputs, and keep screenshots as supplemental proof.

How should we handle exceptions for legacy systems?

Put them in an Exception Register with a business reason, compensating controls, and a review trigger. Track a remediation plan even if the timeline is uncertain; assessors look for governance and active management.

What if our third party manages part of the environment (for example, MSP or cloud-managed service)?

You still own compliance. Require the third party to provide baseline definitions, change records, and compliance reports that map to your baseline register, then store that evidence with your control artifacts.

How do we prove “settings remain enforced” over time?

Show recurring reports or checks that measure compliance against the baseline and show remediation when drift occurs. Pair the report with tickets that document corrective action and closure.

Footnotes

1. NIST SP 800-171 Rev. 3