Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
3.4.1OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW

3.4.1Baseline configurations and inventories

3.4 Configuration Management · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal SystemsNIST SP 800-171A — Assessing Security Requirements for CUI
Independent interpretation

What this requirement is after

You must know what you have — hardware, software, firmware, documentation — and what each of those things is supposed to look like when correctly configured. The inventory answers 'what exists'; the baseline answers 'what state should it be in'; both stay current as systems are built, changed, and retired.

Across revisions

Rev. 3 splits this requirement: baseline configurations remain in Baseline Configuration (03.04.01), while the inventory half becomes a standalone requirement, System Component Inventory (03.04.10), with explicit update and accuracy expectations.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportHigh confidence

Why: One reconciled record of hardware, identities, and applications, kept current through onboarding, offboarding, and change control, is the inventory half of this requirement implemented as an operating routine rather than a document.

What this does not claim: The requirement has two halves and the practice carries one: baseline configurations — the documented, maintained known-good state of each system type — are separate work the inventory does not produce. An assessor evaluates both halves across the organization's defined system boundary, including systems the discovery sources never see.

Practice-side activities
  • Merge endpoint, identity, cloud, and procurement sources into one reconciled record
  • Investigate rows appearing in only one source and assign an owner to every asset
  • Tie inventory updates to onboarding, offboarding, and change control
Evidence this produces
  • The reconciled inventory with owner, sources, and cadence
  • Monthly unmanaged-asset and reconciliation-discrepancy reporting

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Partial implementation supportModerate confidence

Why: A walked-down, verified OT inventory — including serial-connected and safety-instrumented devices no scanner sees — advances the inventory half of this requirement for the operational estate, where paper records and vendor spreadsheets otherwise stand in for knowledge.

What this does not claim: May partially address the requirement, and only where OT assets fall within the assessed CUI boundary — much OT does not. Baseline configurations for controllers, HMIs, and historians are separate work the walk-down does not create, and the IT estate's inventory is outside this practice entirely.

Practice-side activities
  • Walk down each line and record make, model, firmware, connectivity, and criticality
  • Reconcile passive-monitoring observations against the record and investigate unknowns
Evidence this produces
  • Walk-down records with coverage tracking per line and site
  • Reconciliation results showing unknown observed assets investigated

Where this holds: Holds only where OT systems process, store, or transmit CUI or are within the assessed boundary; weakens to no relationship where the OT estate is out of scope.

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

Operational supportModerate confidence

Why: The requirement runs 'throughout the respective system development life cycles', and retirement is the life-cycle stage most organizations skip: tracking end-of-life systems and actually decommissioning them is what keeps the inventory true and the baselines maintainable.

What this does not claim: 800-171 contains no technical-debt requirement, so this is a reasoned relationship rather than a stated one. Retiring systems neither builds the inventory nor authors a baseline; the practice keeps both records honest at the end of the life cycle and contributes nothing at the beginning.

Practice-side activities
  • Carry lifecycle and support status as inventory fields
  • Decommission retired systems deliberately, updating inventory and baselines as part of the retirement
Evidence this produces
  • The end-of-life register drawn from the inventory
  • Decommissioning records showing inventory and baseline updates

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Build one reconciled inventory from the sources you already own — endpoint manager, identity provider, procurement records — and mark what appears in only one source.
  • Document a baseline per system type: a gold image, a configuration standard, or even an annotated build checklist that says what is installed and how it is set.
  • Tie both records to change control so they stay true between reviews; an inventory updated by annual campaign is a snapshot, not a baseline.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The reconciled inventory with its owner, sources, and reconciliation cadence
  • Dated baseline documentation or images per system type
  • Change records showing inventory and baseline updates flowing from changes

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

Artifacts

Templates and worksheets with a mapped relationship

The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

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