Vendor due diligence: when evidence needs a new review

Vendor due diligence evidence belongs to a particular question, product scope, and point in time. A saved document can remain useful while no longer answering the decision in front of you. Instead of assigning every source the same expiry date, identify what could make its conclusion unsuitable: a changed edition, a different deployment, revised terms, or a new requirement. This guide proposes a practical review process for a software buying file. It does not certify vendors or report a market-wide finding.

Evidence age is only one part of relevance

Begin with the claim you used in the decision. What did the source actually establish, and for which subject? A product description may identify a feature without establishing its availability in the edition you intend to purchase. A contract document may apply to a particular service or period. Keeping the source address alone is not enough; retain the relevant passage, its context, and your reason for treating it as useful evidence.

A recently retrieved page is not necessarily a recently updated statement. Likewise, an older document is not automatically useless. Distinguish publication date, source revision date, retrieval date, and your own review date where those dates are available. Do not invent a missing date from the appearance of the page. If a date needed for your review is unavailable in the source, mark that uncertainty and decide whether further clarification is necessary for the intended decision.

The practical question is whether the evidence still supports the requirement you are reviewing. That requires a connection between the requirement and the source, not merely a timer attached to a PDF. A uniform reminder can help organise work, but it should not silently turn into a claim that all evidence is valid until the reminder fires. Your organisation’s approval policy and any applicable obligations remain separate inputs to the review.

Define review triggers in the buying file

A trigger is a reason to revisit a conclusion, not an automatic rejection of a supplier. Moving from a limited pilot to a broader deployment may create a new question even when the product itself has not changed. A renamed edition may require clarification about contractual scope. A changed source passage may be relevant, irrelevant, or ambiguous. Record the event and its relationship to your requirement before deciding how much additional work is needed.

Keep triggers specific enough to act on. “Review security” describes a broad workstream. “Confirm whether the new deployment is covered by the document used in approval” describes a concrete question. The latter can be assigned, answered, and checked. It also prevents unrelated positive evidence from closing a question that remains unresolved. A helpful follow-up should name the requirement identifier so the answer returns to the right place in the buying file.

Use an explicit state for unresolved work

A blank spreadsheet cell can mean several things: nobody has looked, the source could not be retrieved, or the requirement is not applicable. Those states require different actions. Use clear labels and retain a short explanation. In particular, an unavailable public source is an observation about the research attempt. It should not be rewritten as a claim that the vendor cannot provide the underlying evidence through another suitable channel.

The following fictional worksheet contains ten requirement rows. Four have been reviewed against the unchanged intended scope, three need new evidence after a scope change, and three remain open because a suitable source has not yet been established. These categories are invented to explain the workflow. They describe no company, procurement team, or platform dataset. Their counts are stored once in this article and used directly by both charts.

Do not interpret the reviewed share as a supplier score. The rows can have very different importance, and one unresolved mandatory condition may control the decision. Counting tasks helps plan the work; it does not establish suitability. Keep the underlying requirement and the consequence of an unresolved answer visible alongside every status. Otherwise a tidy percentage can conceal the very question the review was supposed to resolve.

Compare source versions without rewriting history

Preserve the earlier decision record and add the new assessment. If you replace the old passage with the current one, a later reviewer may be unable to reconstruct why the original decision was reasonable at the time. Retain records only through appropriate permitted means and with the access controls their contents require. A reference to a controlled internal document can be more suitable than copying confidential material into a widely shared spreadsheet.

Read the surrounding context of a changed passage. A wording change may clarify the subject without changing the underlying capability. A short deletion may remove a limitation that mattered to your approval. Neither conclusion should be assumed from a character-level difference alone. State what you observed, what you infer from it, and what needs confirmation. When uncertainty is material, assign a concrete follow-up rather than smoothing the language into a confident answer.

The methodology explains how evidence and uncertainty are represented on this platform. Apply the same distinction to your own file: a source statement, a derived interpretation, and an internal acceptance decision are separate records. The developer documentation provides context for retrieving published information, but an API response does not automatically satisfy the evidence requirement of every purchase.

Run a bounded follow-up with a clear owner

Consider a fictional integration approved for an internal pilot. The team now wants to use it in a different product edition and connect an additional business system. The original evidence may still explain the feature, but it does not automatically cover the new edition or the expanded use. The review owner identifies those two questions and asks for evidence that names the relevant scope. No claim about a real vendor is implied by this example.

A useful request describes the intended use and the exact uncertainty. It avoids asking for every document the supplier has ever produced. The reviewer then checks whether the response actually answers the question, who issued it, and which service or edition it covers. If the answer remains conditional, the condition stays visible. Passing a document between teams is not the same as accepting it for the decision.

Set an internal due date that fits the buying process and the work required. Do not present that planning date as a legal evidence-expiry rule. If the decision cannot wait for a necessary answer, the responsible authority must explicitly address the unresolved condition under the organisation’s policy. A researcher should not erase the uncertainty merely to make the procurement dashboard look complete.

Consider how the review will be handed to a colleague who was absent from the original discussion. Include enough context to explain why the particular change mattered. A short note can name the earlier requirement, the new condition, the source examined, and the conclusion reached. The colleague should be able to follow that chain without guessing which attachment you meant. Where an answer remains restricted to a particular deployment or edition, place that restriction beside the conclusion. This makes the record usable when a later request proposes another expansion of scope.

Close the review with an outcome, not just an attachment

1. Identify the decision. Name the requirement, intended use, and previous approval.
2. Record the trigger. Describe the changed scope, source, or condition.
3. Read the evidence. Check subject, relevant passage, date, and limitations.
4. Resolve or assign. Keep unanswered questions with a responsible owner.
5. Document the outcome. State the accepted scope and remaining conditions.
6. Preserve the history. Keep the earlier basis distinguishable from the new review.

Ask someone outside the original research task to follow one completed row. Can they identify the source, understand the conclusion, and see why the review was triggered? If they need a verbal explanation, improve the record at that point. This is a practical usability check on the buying file, not a certification exercise. It helps reveal missing context while the people who know the decision are still available to clarify it.

For a broader process review, read the procurement maturity assessment guide. To begin a new search, return to the catalog with a clearly stated requirement. Evidence review is most useful when it supports a specific next decision. More documents, more reminders, and more status colours are not substitutes for a source that actually answers the question.