The Evidence Packet Is a Map, Not a Verdict
A first-pass review of a software supplier should now contain more than a company name, a questionnaire, or a promising repository link. It should connect the supplier and product to their criticality, provenance, dependencies, and relevant C-SCRM concerns, while showing which observations are corroborated and which remain uncertain. This checkpoint brings those elements together into a reusable evidence packet and defines the judgment it can support: not “is this vendor secure?” but “what do we know about this particular use, how strongly do we know it, and what should happen next?”
The packet is a map because it preserves relationships. It shows where a finding came from, what object it describes, and how it bears on a decision. It is not a verdict because the map can be incomplete, the sources can disagree, and some of the most important questions—ownership, jurisdiction, resilience, or product performance—may require evidence outside a public repository. Treating uncertainty as a defect to hide would make the record look cleaner while making the decision less defensible.
Build one record from several kinds of evidence
NIST's due-diligence model gives the record a spine. Start with the subject: the legal supplier, the product or service, the release or version where relevant, the system in which it will be used, and the consequence of failure. Then attach findings to the five research categories: Foreign Ownership, Control, or Influence; Provenance; Resilience; Foundational Cyber Practices; and Supply Chain Tiers. The categories are connected questions, not columns that become meaningful merely because every cell contains text.
A useful packet keeps at least five layers distinct.
Scope establishes what the decision is about. The same supplier can present different risks across products, service boundaries, and uses. A component used in a low-impact internal application is not automatically equivalent to software embedded in a critical service. The packet should record the proposed use and the assumptions that make the product material. Without that context, the reviewer cannot tell whether a finding is relevant or merely interesting.
Findings state what a source actually shows. A finding might say that a repository exposes a particular development practice, that a release includes an inventory, or that a public record identifies a corporate relationship. The statement should not silently add the conclusion that the supplier is trustworthy, the product is secure, or a risk is absent. Those are interpretations that require their own reasoning.
Corroboration tests whether the observation holds. NIST recommends validating findings against multiple sources when possible. Agreement between sources does not make a claim infallible, but it can reduce the chance that a stale page, similarly named entity, or narrow detection rule controls the conclusion. Disagreement is not noise to delete. It is a property of the evidence that may increase the need for verification.
Concern levels connect findings to the organization's risk tolerance. NIST leaves the levels of concern to the organization and the criticality of the system. A finding becomes material when it crosses a defined decision boundary, not when it sounds alarming in isolation. The boundary may differ by product, data, jurisdiction, or recovery options. The packet should say which concern level applies and why, even when the conclusion is that the issue is tolerable with monitoring.