The task
A vendor review is mostly reading long documents for the three paragraphs that answer your question. Configure an agent to read the pack against your own requirement list, quote what it found and, above all, record how old each piece of evidence is. An expired report that answers the question perfectly is still a gap.
What you provide
The vendor evidence pack
Audit reports, penetration test summaries, the data processing terms, subprocessor lists and any certifications supplied.
Your requirements
The controls you require for this vendor tier, and the evidence age you accept for each.
The intended use
What data the vendor will hold and where. The same pack passes or fails depending on what you are about to send them.
Give the agent a clear brief
Use these instructions as a starting point, alongside your approved sources and permissions.
For each of your requirements, find the supporting evidence in the pack and quote it with the document, page and date. State the scope the evidence covers, because a report covering a different product does not cover this one. Report a requirement as unevidenced when nothing addresses it, and as stale when the evidence is older than you accept. Do not approve a vendor, assign a risk rating or accept a risk.
How the work comes together
Read against your list, not theirs
Work through your own requirements. A vendor pack is organized to be reassuring, and following its structure is how a review ends up answering questions nobody asked.
Check scope and date together
Record what the evidence covers and when it was produced. Scope mismatches and expiry are the two findings that a fast read misses most often.
Return the gaps
List the unevidenced, stale and out-of-scope requirements with quotations. That list is what goes back to the vendor.
Illustrative example · fictional data
Answered, but not for this product
An illustrative review of a fictional vendor pack against a requirement list, with a twelve-month evidence age limit.
| Requirement | Evidence found | Result |
|---|---|---|
| Independent audit report | Report covering a different product line | Out of scope for this service |
| Penetration test, last 12 months | Summary dated 19 months ago | Stale, refresh needed |
| Subprocessor list with locations | Data terms Annex B, current | Evidenced |
The first row is the one that a checklist review passes. The document exists, it is genuine, and it says nothing about the service you are buying.
The human review
A security reviewer decides what the gaps mean and whether the vendor proceeds. Risk ratings, acceptances and approvals stay with the accountable person in your organization.
Set it up for your team
Write requirements per vendor tier
Set out what you require and the evidence age you accept. Reviewing every vendor against the strictest list produces gaps nobody intends to act on.
Always supply the intended use
The data the vendor will hold changes the answer. A review run without it is not a review of anything in particular.
Make dates and scope mandatory outputs
Require the date and covered scope on every finding, so an out-of-scope report cannot quietly satisfy a requirement.
Check the result before scaling
Use packs you have already reviewed, including one with a scope mismatch and one with expired evidence. Count requirements wrongly marked as evidenced, which is the only error class that matters here.
Keep the data in the right place
Vendor packs are usually shared under confidentiality terms that restrict where they may be processed. A fully local deployment keeps them inside your network and avoids sending a third party’s audit report to a fourth party.
Explore deployment optionsQuestions & answers
Does it give the vendor a risk score?
No. It returns evidenced requirements and gaps with quotations and dates. Rating and accepting risk are accountable human decisions.
Can it tell whether a certificate is authentic?
No. It reads what the document says. Confirming a report with the issuing auditor is a separate step and should stay separate.
Why does it care so much about dates?
Because stale evidence is the most common finding in real reviews and the easiest to miss. Evidence with no recorded date is treated as unevidenced.