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

03.17.03Supply Chain Requirements and Processes

03.17 Supply Chain Risk Management · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Establish processes for identifying and addressing weaknesses or deficiencies in supply chain elements and processes, and enforce organization-defined security requirements to protect against supply chain risks and limit the harm from supply-chain-related events.

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 SystemsNIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Independent interpretation

What this requirement is after

The operating half of supply chain risk management: a running process that finds the weak points — a single-source component, a vendor with a poor patch history, an update channel with no integrity checking — and defined security requirements actually enforced on suppliers, not merely written into a plan. Enforcement is the word that matters; requirements without consequences are requests.

Across revisions

New in Rev. 3 as part of the new Supply Chain Risk Management family; no Rev. 2 counterpart requirement existed.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportModerate confidence

Why: The practice's core — knowing what suppliers and components bring in, and holding suppliers to security expectations — is this requirement's substance: a running process for finding supply chain weaknesses and defined security requirements applied to the suppliers that matter.

What this does not claim: Supports implementation of the requirement rather than completing it: enforcement presumes agreements that carry the requirements, and in OT the sole-source vendor frequently holds the leverage, so 'enforce' degrades to 'document and compensate' more often than the requirement's language admits. The process must also cover suppliers of the broader CUI system, not only those that reach the plant.

Practice-side activities
  • Tier suppliers by consequence and review the critical tier on a cadence
  • Track supplier weaknesses like vulnerabilities: recorded, rated, assigned, closed or formally accepted
  • Verify component integrity on receipt for the systems that matter most
Evidence this produces
  • Supplier tiering and review records
  • A tracked supplier-weakness log with dispositions
  • Receipt-verification records for critical components

Where this holds: Strongest for plant-bound suppliers and components; supplier processes for enterprise IT and cloud services need owners outside this practice.

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
  • Tier suppliers by consequence: the vendor whose remote access reaches production and the vendor who supplies office furniture do not warrant the same process.
  • Define the security requirements suppliers carry — secure development attestation, vulnerability notification, component provenance — and check them at onboarding and on a cadence, not once.
  • Treat supplier weaknesses like vulnerabilities: recorded, risk-rated, assigned, and tracked to closure or accepted with a signature.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The supplier-review process with records of weaknesses found and addressed
  • The defined supplier security requirements and where each is imposed — contract, agreement, or terms
  • Escalation or enforcement records for a supplier that fell short

Suggested owners, derived from the mapped practices and artifacts: Procurement + OT · Procurement lead. 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 came from in Rev. 2

No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →

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