NIST SP 1326 makes due diligence an assessment record—not a supplier approval

Define the assessment object before collecting evidence

SP 1326 begins with an investigative purpose: research pertinent information about a supplier or product so an informed decision can be made. That framing means the object cannot remain a vague vendor name. The assessment record should identify the legal entity, parent and material affiliates, product or service, version or offering, intended use, acquisition or installed-system context, assessment date, accountable decision, and the organizational risk tolerance being applied.

The guide is scoped to ICT suppliers even though NIST notes that supplier due diligence can be applied more broadly. Supply-chain teams should therefore avoid relabeling it as a complete diligence method for labor practices, financial viability, physical logistics, sanctions, environmental impact, quality, or every other procurement concern. Adjacent assessments can be linked, but each needs its own authority, method, evidence, owner, and decision boundary.

Keep the five components visible as separate findings

NIST names foreign ownership, control or influence; provenance; resilience; foundational cyber practices; and supply-chain tiers as the five due-diligence components. Those dimensions are related but not interchangeable. An ownership finding does not establish where code was developed, a provenance finding does not prove recovery capability, and a security-practice statement does not expose all sub-tier dependencies.

A useful evidence model records each claim, source, observation date, assessed object, method, confidence, contradiction, and unresolved question. It should distinguish supplier-provided material, public filings, product documentation, authoritative government records, technical artifacts, licensed data, analyst inference, and direct observation. Compressing those records into one traffic light can hide which component drove concern and which component simply lacks evidence.

Separate research findings from the acquisition decision

NIST describes due diligence as input to informed decisions on new acquisitions or existing systems. The research record is not the decision itself. Approval may also depend on mission criticality, alternatives, contractual protections, architecture, compensating controls, implementation design, operating ownership, monitoring, legal requirements, cost, and an authorized risk decision. A low-concern finding in one component cannot approve the whole relationship.

The reverse matters too. An incomplete or concerning finding should trigger a defined response rather than an unexplained rejection. Teams should record whether they requested more evidence, changed contract terms, limited scope, selected another product, added controls, accepted risk, or scheduled reassessment. That preserves accountable judgment and gives affected suppliers a traceable question instead of a black-box score.

Maintain the assessment after onboarding

The NIST abstract explicitly includes existing systems as well as new acquisitions. Due diligence is therefore not finished when a purchase order is signed. Ownership, development locations, product components, hosting, critical sub-tier relationships, support arrangements, vulnerabilities, incidents, and resilience evidence can change. The record needs review triggers, source monitoring, version history, reassessment ownership, and a link to installed assets and active contracts.

Supply Chain Signal treats the final NIST page as primary evidence for publication status, scope, purpose, relation to SP 800-161 Rev. 1, and the five named components. The source does not establish the risk, suitability, approval, or rejection of any supplier or product, and it does not replace an organization's procurement authority or risk policy. Buyers should adapt the guidance to their mission, evidence access, and current obligations.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Supply Chain Signal will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.