Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
03.04.02OFFICIAL TITLEPENDING NIST SME REVIEW

03.04.02 — Configuration Settings

03.04 Configuration Management · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires establishing, documenting, and implementing organization-defined configuration settings that reflect the most restrictive mode consistent with operational requirements, and identifying, documenting, and approving any deviations from those settings.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Baselines say what a system is; settings say how each product is hardened. The organization chooses its settings — leaning toward the most restrictive that operations can tolerate — writes them down, applies them, and treats every deviation as a documented, approved exception rather than a quiet local choice.

Across revisions

Carried from 3.4.2 with the settings an organization-defined parameter, an explicit most-restrictive-mode orientation, and deviation handling stated.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: The practice's documented, portable baselines — written per core system and inherited by new tools through a secure-configuration checklist — are the establish-and-document half of this requirement, and its drift detection is the signal that deployed settings still match documented ones.

What this does not claim: May partially address the requirement: the practice does not itself select organization-defined settings against a most-restrictive-mode test, and its portability emphasis is not this requirement's concern. Fleet-wide enforcement and a maintained deviation register are separate work that the baseline documents enable but do not perform.

Practice-side activities
  • Document baseline settings per core system with a named owner
  • Run new tools through the secure-configuration checklist before adoption
  • Detect and investigate drift between documented and deployed configuration
Evidence this produces
  • Baseline documents with their benchmark sources
  • Secure-configuration checklist records for adopted tools
  • Drift reports with dispositions

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Start from a published benchmark — CIS, vendor security baselines, DISA STIGs where relevant — and record deltas, rather than authoring settings from scratch.
  • Enforce through management tooling (MDM, Group Policy, cloud policy engines) so the documented settings and the deployed settings are the same artifact.
  • Keep the deviation register honest: dated, owned, and reviewed; an undocumented deviation is drift wearing a costume.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The documented settings per platform with their benchmark source
  • Enforcement tooling policy exports
  • The deviation register with approvals and review dates

Suggested owners, derived from the mapped practices and artifacts: IT leader · System administrator. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

WORKSHEET · REVIEW ANNUALLY PER PLATFORMConfiguration Baseline Worksheet
The other revision

Where this came from in Rev. 2

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated