A third-party risk programme that is not just a questionnaire you send

Because it treats a supplier estate as uniform when it is not. The same two hundred questions go to the payroll processor holding every employee record and to the company that supplies the coffee, and the security team reviewing the returns has the same attention for both.

What follows is predictable. The questionnaire becomes a formality on both sides. Suppliers answer from a boilerplate document, buyers skim for red flags they rarely find, and the file exists so that somebody can say it exists. The organisation has spent real effort and has not reduced any risk.

The failure is one of allocation rather than rigour. There is a finite amount of scrutiny available, and spreading it evenly guarantees the supplier who matters gets a fraction of it.

Ask two questions about each one, and resist the urge to build anything more elaborate. What would happen to us if this supplier were unavailable for a week? And what of ours do they hold or can they reach?

The first question is continuity: it finds the suppliers your operations depend on, including the unglamorous ones nobody lists as critical until the day they stop. The second is confidentiality and integrity: it finds the ones holding personal data, source code, customer records or credentials, and the ones with network access or administrative rights into your estate.

Score both coarsely — high, medium, low — and take the higher of the two. Resolution beyond that is false precision. A ten-point weighted model produces numbers that look rigorous and are, underneath, the same three judgements with arithmetic laid over them.

The output is a supplier register with a tier against each entry. That register, not the questionnaire, is the programme's actual artefact, and it is the thing an auditor should be shown first.

Match the depth of the question to the tier, and accept evidence in proportion to what you are asking about.

For low-tier suppliers, the register entry is often enough: who they are, what they do for you, who owns the relationship, and a contract. Sending them a security questionnaire produces a document nobody will read and delays an onboarding for no return.

For the middle tier, ask for what already exists. A current ISO/IEC 27001 certificate with a scope statement that covers the service you are buying, or a SOC 2 report, answers more than a self-assessment does — because somebody independent tested it. Read the scope, not the logo: a certificate covering a head office and not the platform you are buying is a common and easily missed gap.

For the top tier, the questionnaire is a conversation opener rather than the assessment. Ask about the specific things that would hurt you — how they segregate your data from other customers, who inside their organisation can reach it, what their own supplier chain looks like beneath them, what happens to your data when the contract ends, and how they would tell you about an incident and in what time.

That last one is worth pressing on. A supplier who cannot commit to a notification timeline is telling you something about their detection capability, not just their contract terms.

In the contract. An assessment that ends in a file note ends. An assessment that ends in a clause persists, applies to the people who join later, and has a consequence attached.

The terms worth arguing for are the ones you would otherwise have no way to enforce: a breach notification window with a number in it, a right to audit or to receive the supplier's own audit reports, obligations about sub-processors and notice before they change, the security standard they will maintain, and what happens to your data on termination.

This is also where a third-party programme meets the obligations arriving from your own side. If you hold ISO/IEC 27001, supplier relationships are part of the management system rather than an adjacent activity. If you process personal data, the processor terms are not optional.

The common failure here is sequencing. Security is asked to assess a supplier after the commercial terms are agreed, at which point the only remaining leverage is a signature somebody senior wants this week.

By accepting that you cannot re-assess everything, and choosing what to re-assess on purpose.

Tier drives cadence: the top tier annually, the middle on certificate expiry, the rest on change. That last trigger is the one most programmes lack, and it is the one that catches real drift — a supplier taking on a new category of data, acquiring or being acquired, moving a service to a new region, or having an incident.

Certificate expiry deserves an actual calendar entry rather than an intention. An ISO certificate has a fixed three-year cycle and a SOC 2 report covers a stated window that ends; a file holding a report whose period closed eighteen months ago is evidence of nothing current, and it is remarkably common.

And watch what you already see. The supplier who missed two SLAs this quarter and changed security contact three times is giving you more signal than the questionnaire did, and none of it will arrive through the third-party risk process unless somebody has connected the two.

An auditor is not checking that you sent questionnaires. They are checking that you know who your suppliers are, that you decided which ones matter and on what basis, that the decision is reflected in what you asked and what you signed, and that something happens when a supplier changes.

Which means a complete register with tiers and reasoning beats a folder of two hundred completed questionnaires, every time. The register demonstrates a method. The folder demonstrates activity.

The question that most often lands badly is the simplest: name your most critical supplier and show the last review. If the answer requires a search, the programme is a filing system.