Supplier review workflow
How to Build an ICT Supplier Due Diligence Evidence Pack
Organize approved software-supplier documents into a source-backed evidence pack with provenance, scope, gaps, owners, and review dates.
Article packet
Workflows
Procurement, security, and IT owners reviewing one ICT or software supplier before approval or renewal
9 min read
01
Keep every supplier claim attached to an approved document, date, revision, and evidence scope.
02
Record data access, resilience, foundational security evidence, dependencies, and unanswered questions separately.
03
Give the packet an owner and re-review date instead of turning old questionnaire answers into permanent truth.
Inspect source and review state before reusing a supplier claim
This genuine Wenlan desktop capture comes from the app's deterministic test fixture, not a supplier review or customer workspace. It shows maintained Pages with source counts and a review queue, the product surfaces used to keep source changes and unresolved evidence visible.

- 01
Bound the supplier review
Choose one supplier, service, decision, approved source set, and responsible reviewers before adding material.
- 02
Build a cited evidence register
Keep provenance, revision, data-access scope, resilience and security evidence, dependencies, gaps, and questions attached to exact sources.
- 03
Re-review before a decision
Open the cited passage, inspect stale or conflicting evidence, and leave approval with the organization's qualified procurement, security, legal, and privacy owners.
Worked supplier evidence packet
This is a vendor-neutral review structure, not a certification or procurement decision. Replace every row with approved evidence for one supplier and service scope.
- Evidence input
- An approved policy, architecture or data-flow document, resilience plan, questionnaire, subprocessor record, or dated clarification with revision and owner.
- Review statement
- One supplied fact, reviewer interpretation, residual risk, contradiction, missing item, or open question linked to the exact passage and service scope.
- Review state
- Current, stale, contradicted, unsupported, or pending, with evidence owner, reviewer, dependency, and next review date recorded.
01
Quick answer
Build one evidence pack for one ICT or software supplier. Register only approved source documents, then record each claim's provenance, revision, data-access scope, resilience and security evidence, dependencies, gaps, owner, and review date. Mark unsupported or stale claims as unverified and keep the final approval decision with procurement, security, legal, and privacy reviewers.
Wenlan can connect supported Markdown, text, text-extractable PDFs, folders, and read-only Obsidian sources to source-backed Pages, citations, revisions, stale state, lint, and human review. It does not validate certifications, crawl vendor sites, monitor suppliers, scan vulnerabilities, score risk, or approve procurement.
02
When this problem appears
Supplier reviews often mix a current security policy, an old questionnaire, an architecture diagram, a certification claim, and an email clarification into one spreadsheet. Without source dates and scope, a confident summary can hide which statement is current, which applies only to one service, and which still lacks evidence.
03
Build one reviewable supplier evidence pack
Start with one supplier and one procurement or renewal decision. The source register and review fields remain useful even if the team does not use Wenlan.
- Define the supplier, product or service, decision, business owner, review team, date range, approved source set, and excluded confidential material.
- Register current policies, architecture and data-flow documents, resilience material, subprocessors or dependencies, completed questionnaires, and dated clarifications only when your organization has approved their use.
- For every important claim, record the exact source passage, document revision, service scope, data-access profile, evidence owner, and next review date.
- Separate supplied evidence, reviewer interpretation, residual risk, missing evidence, contradictions, and open questions. Never turn an unanswered questionnaire row into an affirmative control claim.
- Map dependencies and supplier tiers explicitly. A downstream service, subprocessor, or hosting dependency may need its own evidence and owner.
- When a document or service scope changes, resync the affected source and mark dependent claims stale until a qualified reviewer checks the new revision.
- Before approval or renewal, open the cited source and let procurement, security, legal, and privacy owners make the decision under the organization's existing controls.
A bounded supplier-evidence workflow
wenlan status
wenlan sources add ~/Reviews/approved-supplier-docs
# In a Wenlan plugin client:
/distill <supplier and review scope>
/pages <supplier evidence pack>
/lint
/curate04
What to check next
A questionnaire or evidence pack is not a security guarantee. Wenlan does not validate certifications, perform legal or privacy review, discover vendors, crawl websites, monitor live supplier changes, scan vulnerabilities, score risk, or approve or reject a supplier. Keep sensitive material inside your organization's approved access controls and use qualified human reviewers.
Make one supplier review traceable
Choose one supplier and service scope, connect approved evidence, and leave every unsupported or stale claim visible before the decision meeting.
FAQ