03.04.01: Baseline Configuration

To meet the 03.04.01: baseline configuration requirement, you must define, approve, and maintain a documented, secure baseline configuration for the systems that process, store, or transmit CUI, then control and evidence any deviation through formal change management. Your goal is simple: every in-scope asset has a known-good configuration, and you can prove it stays that way. ¹

Key takeaways:

• A “baseline” is a documented, approved configuration standard for each in-scope system type, not a one-time hardening project.
• You need both technical implementation (templates, settings, automation) and governance (ownership, exceptions, approvals, drift handling).
• Audit success depends on evidence: baselines, approvals, applied configurations, change records, and drift/remediation proof. ¹

Baseline configuration is the control that prevents your environment from becoming a collection of snowflakes. For a Compliance Officer, CCO, or GRC lead supporting NIST SP 800-171 Rev. 3, 03.04.01 is a requirement you can operationalize fast if you treat it as a lifecycle: define what “approved and secure” means, enforce it consistently, and prove you detect and manage drift. ¹

This requirement matters most in mixed environments: Windows endpoints with local admin creep, cloud workloads created from ad-hoc images, network devices managed by tribal knowledge, and SaaS configurations changed in production without a ticket. Baseline configuration turns that chaos into a repeatable standard that IT can implement and GRC can defend.

The practical approach: (1) establish scope for CUI systems, (2) create baselines by platform, (3) implement them via tooling you already run (MDM, GPO, IaC, configuration management, golden images), (4) manage exceptions with risk acceptance, and (5) collect recurring evidence that your baseline is applied and stays applied. ¹

Regulatory text

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

Operator meaning (what you must do): Establish and maintain a documented baseline configuration for in-scope systems (those that handle CUI), ensure the baseline is approved, and control changes so the environment remains consistent with that baseline except where deviations are authorized and tracked. Your assessment posture hinges on showing the baseline exists, is implemented, and is kept current through a controlled process. ¹

Plain-English interpretation (requirement-level)

A baseline configuration is the “known-good” set of settings for a system. For compliance, “baseline” must be:

• Documented: written down in a standard you can version.
• Approved: someone accountable signs off (security + system owner).
• Implementable: translated into technical controls (policies, templates, code).
• Maintained: updated when the system changes, and protected from unauthorized change.

If an assessor asks “what is your standard build for this class of system, and how do you prevent drift?” you should be able to answer quickly, then produce evidence.

Who it applies to (entity + operational context)

Applies to:

• Federal contractors and subcontractors operating nonfederal systems handling CUI. ¹
• Any business unit that owns or operates the boundary where CUI lives: IT, security engineering, cloud platform, endpoint management, network operations, and application owners.

Operational context (what’s in scope):

• Endpoints used to access CUI (workstations, laptops, VDI).
• Servers and workloads hosting CUI apps or data (on-prem and cloud).
• Network and security devices enforcing the CUI boundary (firewalls, VPN, routers, WAF where used).
• Identity and access components tied to CUI access (directory services, SSO configuration) where configuration affects security posture.

A common scoping trap: treating “baseline configuration” as only servers. Assessors often view endpoints and admin workstations as equally important for CUI protection because they are the access path.

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

Step 1: Define the baseline “units”

Pick baseline families that match how IT actually builds and manages systems:

• Windows 11 corporate endpoints
• Windows Server (by role if needed)
• Linux servers (by distro family)
• Network devices (by vendor/model class)
• Cloud workloads (by account/subscription and template type)
• SaaS tenant security configuration (if in your CUI boundary)

Deliverable: a short catalog naming each baseline, owner, and where it applies.

Step 2: Set minimum baseline content (what must be documented)

For each baseline, document:

• System purpose and scope (what CUI workflow it supports)
• Version (so you can show what was in effect at a given time)
• Configuration requirements (security-relevant settings and build steps)
• Dependencies (agents, logging, EDR, MDM enrollment, time sync)
• Approved deviation process (how exceptions are requested and tracked)
• Approval metadata (who approved, date, next review trigger)

Keep it operator-friendly. A baseline that nobody can build from is not a baseline; it is a PDF artifact.

Step 3: Translate baselines into enforceable technical controls

Documentation alone fails audits. Convert your baseline into something that actually sets configuration:

• Endpoints: MDM profiles, GPOs, local policy templates, CIS-style settings if you use them internally.
• Servers: configuration management (Ansible, Puppet, Chef), hardening scripts, immutable images.
• Cloud: infrastructure-as-code modules, golden AMIs/images, policy-as-code guardrails.
• Network: standardized device configs, backups, and template-based provisioning.
• SaaS: admin console settings with change control and periodic validation.

If you do this well, evidence collection becomes easier because your baselines are expressed as code or managed policies.

Step 4: Put change control around the baseline (and around deviations)

Minimum operating model:

• Baseline change request: documented reason, planned test/validation, rollback plan.
• Approval: system owner + security (or delegated authority).
• Implementation record: who changed what, when, and where.
• Verification: proof the new baseline is active and applied.

For deviations:

• Exception ticket: asset/system, setting deviated, reason, compensating controls, expiration date or review trigger.
• Risk acceptance: named approver.
• Tracking: an exception register tied back to the baseline version.

This is where most programs break: they have change control for production apps, but not for “security configuration standards.”

Step 5: Detect and manage configuration drift

You need a way to answer: “How do you know systems still match the baseline?”

• Run configuration compliance checks (MDM compliance, config management reports, cloud policy compliance views).
• Investigate drift: unauthorized change, emergency fix, or legitimate exception not recorded.
• Remediate drift or formalize an exception.

Operationalize drift as a ticket queue. If it lives only in dashboards, it will be ignored.

Step 6: Collect recurring evidence (make it assessment-ready)

Set a routine: pull the same evidence package on a defined cadence and store it in your compliance repository. Daydream can help here by mapping the 03.04.01: baseline configuration requirement to your baselines, change workflows, and recurring evidence requests so you are not rebuilding the same audit binder every cycle. ¹

Required evidence and artifacts to retain

Use this as your audit binder checklist:

Evidence item	What “good” looks like
Baseline configuration standards 1	Versioned document or repo with dates, owners, applicability, and settings
Approval records	Sign-off workflow, meeting minutes, or ticket approvals tied to baseline versions
Build artifacts	Golden image definitions, IaC modules, MDM/GPO exports, config management playbooks
Asset-to-baseline mapping	Inventory showing which baseline applies to each in-scope system
Change tickets for baseline updates	Request, approval, implementation notes, validation results
Exception register	Deviations with business justification, compensating controls, and approvals
Drift/compliance reports	Reports showing configuration compliance and evidence of remediation actions
Baseline review history	Proof the baseline is reviewed/updated when systems or threats change

Keep evidence tied to dates. Assessors often test whether the baseline in place during the assessment period matches the evidence you provide.

Common exam/audit questions and hangups

Expect these:

1. “Show me the baseline for this endpoint/server and prove it is applied.” Hangup: you have the standard, but no proof of enforcement.
2. “How do you handle emergency changes?” Hangup: emergency fixes happen outside the baseline and never get reconciled.
3. “How do you manage exceptions?” Hangup: exceptions exist in email threads, not a register with approval and review.
4. “How do you know a new system starts compliant?” Hangup: provisioning is manual; there is no golden image or template.
5. “What about cloud/SaaS configuration?” Hangup: teams ignore tenant-level settings and only baseline compute.

Frequent implementation mistakes (and how to avoid them)

• Mistake: One baseline document for “all systems.”
  Fix: create baselines by manageable classes that map to ownership and tooling.
• Mistake: Baseline exists only as a PDF.
  Fix: express baseline as enforceable policy/code (MDM, IaC, config management) and keep the PDF as the human-readable overlay.
• Mistake: No explicit exception process.
  Fix: require an exception ticket with approver, compensating controls, and a review trigger.
• Mistake: Drift is discovered but not governed.
  Fix: treat drift findings as tracked issues with resolution paths: remediate, accept risk, or update baseline.
• Mistake: Baselines don’t match the CUI boundary.
  Fix: start from the CUI system inventory and map each asset to a baseline; don’t baseline “everything” and call it done.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so you should plan around assessment expectations rather than case law.

Risk is still concrete:

• Weak baselines create inconsistent hardening, which increases the chance of credential theft, lateral movement, and misconfiguration exposure in CUI environments.
• From a compliance standpoint, the most common failure mode is not the lack of a baseline document; it is lack of operational evidence that the baseline is implemented and maintained. ¹

Practical 30/60/90-day execution plan

Day 0–30: Establish scope + first baselines

• Confirm the CUI system boundary and identify in-scope asset classes.
• Appoint baseline owners (endpoint, server, cloud, network).
• Draft baseline documents for the top asset classes in scope.
• Choose the enforcement mechanism for each baseline (MDM/GPO, IaC, config management).
• Stand up an exception workflow and an exception register template.

Day 31–60: Implement + start producing evidence

• Roll out baseline enforcement to a pilot group, then expand to in-scope populations.
• Export current configurations and reconcile gaps against the baseline.
• Start drift reporting and create a remediation queue.
• Run the first baseline approval cycle and store approvals with versioning.
• Build an “assessment packet” for 03.04.01: baseline docs, enforcement configs, sample compliance reports, and change/exception records. ¹

Day 61–90: Operationalize maintenance

• Convert repeat manual checks into scheduled reporting.
• Tighten change control: require baseline impact review for system changes in the CUI boundary.
• Review exceptions; close, renew, or remediate.
• Add baseline checks into provisioning so new systems start compliant.
• Use Daydream (or your GRC system) to map the 03.04.01: baseline configuration requirement to owners, test steps, and recurring evidence so collection does not depend on one person. ¹

Frequently Asked Questions

Does 03.04.01 require one baseline for every single system?

No. You need baselines that cover your in-scope system types with enough specificity that you can prove consistent configuration and controlled deviation. The practical approach is baselines by platform and role, mapped to your CUI boundary. ¹

What counts as “documented” for a baseline configuration?

A versioned standard that lists required settings and how they are implemented, with an owner and an approval record. A repo with configuration-as-code plus a short readable standard is often easier to operate than a long narrative document. ¹

If we use CIS benchmarks internally, does that satisfy the requirement?

CIS can inform your baseline, but the requirement is that you establish and maintain an approved baseline for your environment and prove it is implemented. Map CIS recommendations into enforceable settings and document any intentional deviations. ¹

How do we handle systems that cannot meet the baseline due to legacy constraints?

Create a formal exception with business justification, compensating controls, and a review trigger, then track it in an exception register tied to the baseline. Avoid “permanent exceptions” with no re-evaluation path. ¹

What evidence do assessors usually reject?

Screenshots without context, undocumented standards without approvals, and “current state” exports that don’t show what the approved baseline is. Provide versioned baselines, enforcement artifacts, and change/exception records that connect the dots. ¹

How do third parties fit into baseline configuration for CUI?

If a third party manages in-scope systems or hosts workloads in your CUI boundary, you still need a defined baseline and evidence it is applied. Contractually require configuration standards, change control, and evidence delivery aligned to your baseline expectations. ¹

Footnotes

1. NIST SP 800-171 Rev. 3