Vendor Security Due Diligence

Every vendor has a page describing their commitment to security. Distinguishing that from an actual programme takes a small number of specific questions.

The evidence that means something

An audit report, not a logo. Reports are available under agreement from vendors who have them, and the scope and exceptions sections are the informative parts.

A penetration test summary, recent, from an independent firm.

A published sub-processor list with a notification mechanism.

A documented incident response process with a stated notification commitment in hours or days.

A security contact who responds.

A vulnerability disclosure policy, which indicates they expect and handle reports.

The questions that reveal the most

"Can we see the report, not the certificate?" The response tells you whether one exists.

"What is your notification commitment after discovering a breach affecting us?" A number in the contract is different from a promise to act promptly.

"What happens to our data on termination, and how is deletion verified?" Frequently unanswered and it belongs in the contract.

"Who are your sub-processors and how are we notified of changes?"

"Has this product had a security incident, and what happened?" An honest answer describing an incident and a response is a better sign than a claim of none.

"Can support staff access our data, under what controls, and is it logged?" The answer is usually yes and the controls vary enormously.

Scaling the diligence

Match the depth to the tier, as described in the risk assessment note. A full questionnaire for a low-tier tool wastes everyone's time and gets fabricated answers.

For small vendors, accept that a formal audit report may not exist and ask different questions: who handles security, what happens when a vulnerability is reported, where is the data, who has access.

A small vendor with clear honest answers is frequently a better risk than a large one with a polished page and no substance behind it.

Contract terms that matter more than the questionnaire

Breach notification, with a timeframe.

Data processing terms meeting your jurisdiction's requirements.

Sub-processor notification and objection rights.

Deletion on termination, with verification.

Data export in a usable format, which is the exit provision and usually the weakest.

Audit rights, even if never exercised.

Liability bearing some relationship to the harm a breach would cause, which is where most standard terms are unacceptable and where negotiation is worth the effort for high-tier applications.

Ongoing rather than one-time

Re-assess annually for high-tier applications.

Monitor for breaches at your vendors, which requires knowing who they are — another use for the register.

Re-assess on acquisition, which changes ownership, jurisdiction and frequently security posture.

Record the assessment date in the register and report on how many are overdue. An assessment programme with no overdue metric is not running.

The realistic position

You cannot verify most of what a vendor tells you.

Diligence reduces the chance of an obvious problem and documents that you asked. It does not make a vendor secure.

Which is the argument for the controls you hold yourself: minimising what data goes in, federating authentication, limiting integration scopes, and keeping the ability to export and leave.

Monitoring your vendors after signing

Assessment is a point in time. The estate changes underneath it and there are cheap ways to notice.

Subscribe to vendor security and status notifications where they exist.

Watch for acquisition news on your highest-tier vendors, which changes the assessment.

Set a review date in the register and report on overdue ones.

Note breaches publicly reported at any vendor in your register, and reopen the assessment.

Ask at renewal whether anything material has changed — certifications, sub-processors, hosting, ownership.

Nothing here is sophisticated, and the alternative is learning that a vendor was acquired by reading it in a contract two years later.

The exit provision

The weakest clause in most SaaS contracts and the one that matters most when a vendor fails or is acquired.

Export in a usable format, specified. "Available on request" is not a commitment.

A timeframe for providing it.

A period of continued access after termination during which export is possible.

No charge, or a stated one, since exit fees are a real practice.

Deletion after export, verified.

Test the export during the trial, not at termination. A format that technically satisfies the clause and cannot be loaded anywhere is a common outcome and it is only discoverable by trying.