Vendor due diligence checklist: update evidence before third-party risk rules change

A vendor due diligence checklist now needs to do more than list documents. The current US proposal for third-party risk management points towards a practical rule: scale review to the risk of the relationship, but keep enough evidence to show why the selected depth was reasonable. That is different from asking every supplier the same 120 questions, and it is also different from accepting a short vendor answer without proof.

The important development is not a new checklist category. It is the proposed emphasis on tailoring oversight to the reasonably assessed risk of each third-party relationship, with comments due on 16 November 2026. For product, compliance, credit, procurement and data teams, the implementation question is immediate: what must the supplier record contain so a lighter review is still explainable, and a deeper review is triggered when the relationship justifies it?

This article uses vendor due diligence in the procurement and third-party risk sense: the review of a supplier, vendor or service provider before and during a business relationship. It is not seller-side vendor due diligence in an acquisition, where a target company prepares diligence for potential buyers. The procurement version should answer a narrower question: can this legal entity perform the proposed activity within our risk appetite, and what evidence did we rely on?

The answer is to redesign the checklist around four layers: relationship tier, company identity, evidence packet and exception outcome. CompanyProof can support the company-fact layer when teams need resolved legal identity, claim-level evidence and API implementation details, but the customer’s own policy still decides supplier approval, residual risk and escalation.

The current search results are useful for a buyer who wants a list of topics. The leading pages cover identity, eligibility, financial condition, security assurance, privacy, compliance, contracts, ownership, sanctions, resilience and recurring review. Several also say that depth should vary by tier, and some explicitly warn against treating supplier answers as evidence.

That coverage leaves a harder enterprise question: how should a system represent a supplier review when the requested information is incomplete, unavailable, contradicted by a public source or adequate only for a low-risk relationship? A checklist can say “verify business registration”, but a workflow must decide whether a registry match, a stale filing, an unanswered ownership question or a supplier’s refusal to share a report blocks the approval or creates a managed exception.

This distinction matters because the current proposal recognises that lower-risk relationships may rely on less detailed information or public and alternative sources, while higher-risk relationships can require more oversight. It also recognises the real-world problem that a third party may not provide certain information. That is exactly where a static checklist fails: it tends to record a blank cell, not the reason the blank was accepted or escalated.

The original contribution here is an evidence-state model for the checklist. Instead of making each row a yes/no request, each row should produce one of a small set of review states: verified, accepted with limitation, contradicted, unavailable, stale or not required for this tier. That gives procurement, compliance, security and credit teams a common language when a supplier answer is not enough.

Start the checklist with the relationship, not the document request. The same company can be low-risk for office supplies and high-risk for hosted payment data. Record the activity, data access, operational dependency, customer impact, jurisdictional exposure and substitution difficulty before asking for evidence. The tier is the reason a checklist is short or long.

Then resolve the legal entity. A brand name, website, parent company or sales contact does not identify the contracting party. The row should capture legal name, jurisdiction, registration number or equivalent identifier, selected source, retrieval date and match rationale. If several entities match, the outcome is not a weak pass; it is an unresolved identity question.

Next, separate the evidence domains. Corporate existence, ownership and control, financial condition, information security, operational resilience, insurance, subcontractors, sanctions or watchlist screening, regulatory history and contract rights each answer different questions. If a supplier provides a vendor due diligence questionnaire, treat it as submitted evidence and compare it with independent sources where the tier requires that extra confidence.

Finally, add source age and refresh logic. A certificate, insurance policy, set of accounts, SOC report, registry status or ownership statement can be true and still become stale. The checklist should say when each evidence type expires for the relationship tier, which event reopens the review and who owns the follow-up. Without that, a completed checklist becomes a filing cabinet, not a control.

• Relationship tier: activity, data access, operational dependency, customer impact and replacement difficulty.
• Legal entity: registered name, jurisdiction, identifier, selected source, retrieval date and match rationale.
• Evidence packet: submitted answer, independent source where used, source date, reviewer and limitation.
• Exception state: verified, accepted with limitation, contradicted, unavailable, stale or not required.
• Reopen trigger: renewal, scope expansion, source age, incident, ownership change, financial deterioration or contract change.

This is a hypothetical example. A US lender wants to onboard “Harbour Metrics”, a fictional analytics supplier, for a product that will process customer transaction data. The sales material names Harbour Metrics, but the contract names Harbour Metrics LLC in Delaware. The review begins by selecting the contracting entity, recording the jurisdiction and identifier, and preserving the original supplier-provided name before replacing it with the matched legal entity.

Tiering makes the checklist deeper. Because the supplier will receive sensitive operational data and support a customer-facing process, the relationship is not treated like a low-risk commodity purchase. The checklist asks for legal authority, ownership and control evidence, financial condition, cybersecurity controls, resilience testing, incident notification commitments, subcontractor exposure, insurance, data-location information and contract rights to request updates.

The supplier returns a completed vendor due diligence questionnaire, an insurance certificate and a security report, but declines to provide audited financial statements because it is privately held. The workflow should not convert that refusal into either a pass or a fail. It should mark financial statements as unavailable from the supplier, record any public or alternative source used, state whether the substitute evidence is enough for this tier and send any residual risk to the approving owner.

Now add the evidence states. Legal identity is verified against the selected source. Ownership is accepted with limitation because the supplier gives a signed control statement but no registry ownership data is available. Financial condition is accepted with limitation if the credit policy allows an alternative source for a supplier of this size; otherwise it is escalated. Cybersecurity is verified only for the system and period covered by the report. Subcontractor exposure remains unsupported until the supplier names material processors and their locations. None of these states is the whole supplier decision, but together they make the decision inspectable.

A supplier due diligence workflow should be predictable when evidence does not line up. The following decision table is intentionally operational. It is not legal advice, and it does not replace sector-specific requirements. It gives teams a way to keep retrieval, verification and approval separate.

The key point is that missing evidence is not the same as contradictory evidence. An unavailable source may justify a retry or a fallback source. A contradiction may require the team to stop relying on the claim until the discrepancy is resolved. A stale record may be acceptable for a low-risk renewal but unacceptable for a critical supplier that holds customer data.

This approach also helps with know your supplier programmes outside regulated banking. Procurement, finance, compliance and security can share the same evidence states even when each team applies a different policy threshold. The checklist becomes a common record of what was known, what was missing and who accepted the limitation.

• Verified: keep the source, retrieval date, source date where available, reviewer and next trigger.
• Accepted with limitation: state the missing detail, compensating evidence, relationship tier and approver.
• Contradicted: stop relying on the affected claim and route it to the owner who can correct the record or reject the supplier.
• Unavailable: retry, use an approved fallback or request supplier evidence; do not imply a clean result.
• Stale: reopen the affected row when source age exceeds policy or when the relationship scope expands.

The implementation work is not mainly a new questionnaire. It is a data model. Each checklist row needs a claim, an evidence source, a retrieval time, a source date where available, a verification outcome, a policy threshold and a review owner. If those fields are missing, the system can show that a questionnaire was completed but cannot explain whether the decision remains supportable.

For a KYB, credit or procurement product, keep the legal entity durable across modules. Do not overwrite a subsidiary with its parent because the parent has richer data. Do not merge a supplier’s trading name with a registry record without preserving the match rule. If ownership, filed financials or cybersecurity evidence is unavailable, show that state explicitly and let the risk policy decide what to do next.

For a vendor due diligence questionnaire, make the answer auditable. Store the submitted value, the field it is meant to support, the independent source used where applicable, the observed value, any correction and the final decision state. When the supplier later changes ownership, data access, subcontractors or contract scope, reopen the specific rows that depended on those facts rather than rerunning the entire process blindly.

For smaller institutions and lower-risk relationships, the current proposal’s practical lesson is not to build a heavy workflow for every supplier. It is to document why the lighter workflow fits the assessed risk. A short checklist can be defensible if it identifies the relationship, captures the evidence actually used and records the reason deeper diligence was not required.

• Define tiers before evidence requests are sent.
• Separate legal-entity resolution from ownership, control, financial and security checks.
• Use evidence states rather than a single approved/failed label.
• Preserve supplier-submitted answers alongside independent observations.
• Set field-specific source-age limits and event triggers, not one annual reminder for everything.