A vendor security review is the set of questions you ask an outside company before you engage them, plus the written record of what they sent back. Done properly it has four parts: an intake form you fill in before anyone signs anything, a fixed list of things you ask the vendor for in writing, a record of what arrived and when, and one file per vendor where all of it lives.
This article is general information about documentation and recordkeeping. It is not legal, compliance or security advice. Which obligations and frameworks apply to a given business varies by organization, industry and jurisdiction, and whether any particular vendor arrangement is suitable for your situation is a judgment for you and a qualified professional who knows it.
What a vendor security review is for
The purpose of the review is to produce a record. You are not auditing anyone, and you are not in a position to verify what a vendor tells you about their own operation. What you can do is ask consistently, write down what came back, and keep it somewhere you can find it.
That record does real work later. When a customer asks who else handles their information, the answer comes out of these files. When you are deciding whether to send a supplier a new category of records, the file tells you what you already knew and when you last asked. When somebody internally wants to add a tool, the file is what stops the same questions being asked from scratch.
It also keeps the judgment in the right place. The review collects and routes information. Whether a vendor is a fit for the work is a business decision for the people accountable for it, taken with whatever professional advice they need.
Intake before a vendor is engaged
Intake happens before a contract, a trial, or a credit card. It is a short internal form, filled in by whoever wants the vendor, and it exists so the review is scoped before anyone starts asking questions.
Six fields are enough:
- Vendor name and what it will do, in one sentence a non-specialist understands.
- The requester and the internal owner, by name. These are often the same person and sometimes should not be.
- What records the vendor would be able to see, described in your own categories rather than theirs: no business records, internal business records, customer records, financial records, or sign-in credentials.
- Whether the vendor would be able to change or remove records, or only read them.
- Whether work stops if the vendor stops, and what the fallback is today.
- Where the engagement sits, meaning which part of the business and which existing agreement it falls under, if any.
Those six answers decide how much review the vendor gets. A design contractor who never sees customer records and a payroll processor should not go through the same process, and pretending otherwise is why most review programs stall in the first month.
Write the depth rule down so it is not re-argued every time. A simple version: vendors who can see or change customer or financial records get the full written request below; vendors who cannot get an intake record only; anyone who would hold sign-in credentials gets the full request regardless of how small the engagement is.
What to ask for in writing
Ask the same things every time, and ask in writing so you have something to file. Email is fine. The point of asking consistently is not fairness to vendors, it is that you can compare one file to another a year later.
- What the vendor publishes about its own security practices. Whatever they choose to share, and the date on it. Record what it says; do not restate it as fact of your own.
- Where the records will be held, and who else is involved. Hosting locations and the vendor’s own list of the outside companies they rely on to deliver the service.
- How the vendor controls access to your records internally. Whether access is limited by role, how staff sign in, and what happens when their own people join or leave.
- What happens if something goes wrong. How they notify customers, in whatever terms their agreement uses, and who the named contact is. Record the contact name and route rather than paraphrasing the commitment.
- How your records come back out. Export formats, what they keep after the engagement ends, and whether removal is confirmed in writing.
- Who your named contact and escalation are. Two names. A shared support address is not an escalation path.
- Any documents they will provide on request. Ask what is available, file what arrives, and note what was not available rather than leaving a blank.
Keep the request to one message with numbered questions. Long questionnaires get partial answers, and a partial answer is harder to file than a short complete one.
How to record what came back
The record is the deliverable, not the review. Build the same small table for every vendor so a reader can scan it without reading the correspondence.
| Field | What you write | Common mistake |
|---|---|---|
| Date asked | The date your request went out | Leaving it out, so nobody knows how old the file is |
| Who asked | A name | Logging a department |
| What was requested | The numbered list, by reference | Rewriting the list differently each time |
| What arrived | Each item, with the date on the document | Writing “received” with no detail |
| What did not arrive | Named plainly | Leaving the gap silent |
| Where the files are stored | A path or folder name | Attachments in one person’s mailbox |
| What we decided and who decided | One line and a name | Recording the outcome with no decision-maker |
| Next review date | A date | “Annual”, with no date |
Two notes on wording. Write what the vendor stated, attributed to the vendor, rather than converting their claims into your own statements of fact. And keep your own commentary separate from their answers, in a clearly labeled section, so a later reader can tell the two apart.
The vendor security review file you keep
One folder per vendor, named for the vendor, holding everything in one place. The folder is the asset. A review that lives in a thread nobody else can open has produced nothing.
A typical folder holds the intake form, the written request and the reply, any documents the vendor provided, the record table above, the signed agreement or a pointer to where it is held, and a short notes file with dates for anything that happened since. If the engagement produced a register entry, the notes file names it.
Store the folders together, in a place more than one person can reach, with a naming convention you fix on day one. The commonest cause of a review having to be redone from scratch is not neglect, it is that the previous one cannot be found.
When a vendor will not or cannot answer
Small vendors sometimes have nothing to send, and large ones sometimes decline to answer a small customer’s questions. Neither is a verdict, and neither should leave an empty file.
Write down what you asked, what you received, and what you did not. Note any arrangement you put in place because of the gap, such as limiting what records the vendor can reach or keeping a copy of anything you send. Then record who made the call to proceed and on what basis, and raise an entry in your risk register so the gap is visible outside the folder. A gap that is written down and owned behaves completely differently from one that is simply missing.
Run the first few reviews on the vendors who touch the most sensitive records, two or three a week, and let the rest catch up over a quarter. A handful of complete files is more useful than a program designed on paper and never started. For a plain list of the records that sit alongside these folders, including the vendor register and data inventory that feed them, see the Trust Center Document Checklist page on this site.