The Security Questions to Ask a Supplier

The moment you hand a supplier your customer data or a login to your systems, your security boundary extends into a company you do not control. Their weak password rules become your incident, and your customers will not be interested in whose fault it was.

The work has four parts. Establish what the supplier actually gets. Ask a small number of specific questions. Read the answers for evidence rather than for reassurance. Then control the access you grant, regardless of how good the answers were.

None of this requires a long spreadsheet of questions. For most small businesses, a page of questions answered in writing, plus a careful read of the contract, gets you most of the way there.

It does require doing it before you sign, because your position is strongest before the signature and weakest on the day you want to raise a concern about a system your whole team now depends on.

Before asking anybody anything, write down what this supplier will hold and what they will be able to reach. Those are two different things and both of them matter.

Data first. Which categories, whose, how much, and for how long. A tool holding your marketing list is a very different proposition from one holding customer payment details, medical information or employee records.

Then access. Will they have a login into your systems, and at what level. Will they connect an integration carrying a token that can read your mail or your files. Will their support engineers be able to see live customer data while helping you. A supplier with a route into your environment is frequently a larger exposure than one simply holding a copy of some data.

Then dependency. If they vanished tomorrow, or were unavailable for a week, what stops in your business. Tier your effort against those three answers. The stationery supplier and the payroll provider do not need the same conversation, and pretending they do is how diligence becomes a form filling exercise nobody reads.

Where is our data held, in which country, and does that change if you grow or switch providers. Ask it plainly, because data location drives your own legal obligations and the answer is often more complicated than the sales team knows.

Who inside your company can read our data, how do they get that access, and how is it removed when they leave. This one separates the suppliers who have thought about it from the ones who have not, faster than anything else you can ask.

Do you use subcontractors or other services that touch our data, and who are they. How would you tell us about a security incident, who makes that decision, and within what period. How do we get our data out, in what format, and what happens to your copies when we leave.

And the question people forget: when did you last restore from your own backups, and how long did it take. A supplier who answers that with a date and a duration is telling you something real about how they run. A supplier who answers it with a paragraph about their commitment to availability is telling you something as well.

Bank grade security and military grade encryption are marketing phrases with no definition behind them. What they tell you is that the answer was written by somebody in marketing rather than by somebody who runs the system.

All data is encrypted sounds complete and usually means the disks in the data centre are encrypted, which protects you if someone steals a physical drive and against very little else. The useful follow up is whether data is encrypted in transit, who holds the keys, and whether their own staff can read the contents.

We are hosted on a major cloud provider says something about the provider's building and nothing about the supplier's software. Their access control, their code, their staff and their processes are entirely their own, and those are what will fail.

We take security very seriously appears in almost every breach notification ever written. And we have never had a breach may only mean that nobody has ever looked, so the better question is how they would know, which turns out to be a question about logging and monitoring rather than about their history.

A certification badge on a website is a claim rather than evidence. Ask for the underlying report, then read three things in it: the scope statement, the period it covers, and the exceptions listed at the back.

Scope is where most of the value quietly disappears. A report can legitimately cover a company's own corporate IT and not the product you are buying, or cover one data centre and not the region your data will sit in. If the system you are purchasing is not named in the scope, the certificate says nothing whatsoever about it.

Period matters too. Some reports describe controls as they existed at a single moment, others describe how those controls operated across a stretch of months. The second is worth considerably more. The exceptions are the genuinely interesting section, because they are what the assessor found and could not sign off, and almost nobody reads that far.

For a small supplier none of this may exist, and that is not automatically a reason to walk away. A short honest description of what they actually do, given by somebody technical who can answer follow up questions without checking, is worth more than a badge nobody has examined. Judge the answers rather than the logos.

Most of what you agreed about security sits in a schedule at the back that nobody opened. Find it before you sign, rather than during an incident with a lawyer on the phone.

Look for a notification obligation with a stated trigger and a stated period, because without one you will hear about their incident when your customers do. Look for audit rights even if you never intend to use them. Look for a subcontractor clause requiring notice before they add a new one, since their supply chain becomes yours by inheritance.

Look at what happens at the end. Data returned in a usable format, their copies deleted, written confirmation, and a period for all of it. Termination terms get written while everybody is friendly and get used when nobody is. Then read the liability cap with your eyes open. It is commonly limited to the fees you have paid, which will not come near the cost of a breach involving your customers, and a small buyer is unlikely to move it. Knowing that changes how much you are willing to hand over in the first place, which is the only real remedy available to you.

Even a supplier with perfect answers should receive the least access that lets them do the job. This half of the risk belongs to you, and it does not depend on trusting anybody's questionnaire.

Named accounts for their staff instead of a shared login, so that your logs mean something afterwards. Multi factor on their access, enforced by you rather than requested of them. Permissions scoped to the work and nothing beyond it. Access that expires on a date rather than access that lasts until somebody remembers to remove it.

Where they need to reach your systems, prefer access requested and granted for a period over standing access that sits there between engagements. Log what they do and have somebody look occasionally. If they connect an integration to your mail or file platform, review what it was actually granted, because those consents are broad by default and permanent by nature.

Then plan for their failure rather than only for their good behaviour. Keep your own copy of the data where the platform allows it. Write down what your business does if they are unavailable for a week. That plan is worth more than any answer they could have given you about their own resilience.

Diligence at signing is a snapshot of one day. Companies get acquired, move platforms, change subcontractors, and lose the person who wrote the answers you were pleased with.

Keep a simple register: the supplier, what they hold, what they can reach, who owns the relationship inside your business, when it renews, and the date of the last review. Bring it out at renewal, which is the one moment your position is strong again.

Watch for the changes that matter in between. An acquisition. A move to a different hosting region. A public incident, theirs or a subcontractor's. A new integration somebody in your team connected during a busy week without asking, which is how most supplier risk actually arrives in a small business.

Be realistic about your influence. A large platform will not answer your questionnaire and will not negotiate its terms with you. What you can do is read their public documentation, look at the history on their status page, keep your own copy of your data, and design so that their bad week does not automatically become yours.