What Makes a Supplier (And When a Tool Is Not Simply a Tool)

What Makes a Supplier (And When a Tool Is Not Simply a Tool)

Every organisation I’ve worked with over the years has a supplier list. It sits somewhere in a spreadsheet, gets reviewed once a year around audit time, and contains the names you’d expect: the IT support company, the payroll provider, maybe a facilities contractor. What it almost never contains is the free trial someone in marketing signed up to last Tuesday to test a new scheduling tool, or the survey platform the ops team started using because it looked quicker than emailing round a form.

That gap is where most of the risk actually lives.

The mental shortcut that catches everyone out

I’ve sat in enough supplier reviews now to know the pattern. Someone asks whether there’s a data processing agreement in place with everyone who touches personal data, and the room nods, confident the answer is yes, because everyone’s thinking of the formal contracts. Nobody’s thinking about the tool three people in the business signed up for last month using their work email, because in their head that wasn’t procurement. It was just getting a job done.

I think the confusion comes from a fairly natural mental shortcut. We picture a supplier as something delivered, often in a brown box, or an organisation we’ve formally engaged, with a contract, a point of contact, maybe a kick-off meeting. A tool doesn’t feel like that. There’s no van, no delivery note, nothing that lands on a desk, so it registers as buying software rather than entering a relationship. But that’s exactly where the thinking goes wrong, because the moment someone creates an account with a third party and puts company or customer data into it, that company has become a supplier, whether anyone intended it that way or not.

The size of the invoice has nothing to do with it. A tool that costs a few pounds a month, expensed on a card by a single employee, can create exactly the same category of risk as a six-figure contract with your core IT provider, because the question that matters isn’t how much you’re paying. It’s what’s flowing into that system, who else can see it, where it’s stored, and what happens to it if the relationship ends or the platform gets breached. From a data protection and information security standpoint, none of that changes just because there was no contract to sign or kick-off meeting to attend. If personal data is going into a platform you don’t own and can’t fully control, that platform is processing on your behalf, and it needs to be treated with the same discipline as any other processor.

Where the standards and the obligations converge

This is where the work I spend most of my time on with clients comes in: helping maintain certification to ISO 27001 and ISO 9001, and meeting obligations under UK GDPR. All three point to the same blind spot, even though they come at it from different angles. GDPR isn’t a standard in the way ISO 27001 or ISO 9001 are; it’s a legal obligation, not something you certify against. But in practice the three sit side by side in almost every client conversation I have about suppliers, because an unassessed tool creates exposure across all three at once.

Under ISO 27001, an unassessed tool is simply a risk nobody has evaluated. Not a small risk. An unknown one, which in information security terms is worse. If you can’t tell an auditor where your data actually sits, who has access to it, and how it’s secured, you can’t demonstrate control over your own information asset register, and that’s precisely the kind of gap that turns up in a certification audit as a nonconformity. I’ve seen this exact scenario play out with clients: an organisation confidently walks through its formal supplier contracts, then gets asked about a tool that’s been in daily use for a year, and the honest answer is nobody quite remembers approving it.

Under GDPR, the exposure is sharper still, because the obligation to have a processing agreement in place exists before the data starts flowing, not once someone notices the gap. Retrofitting a DPA eighteen months after a tool became embedded in daily workflow is far harder than putting one in place at the point of adoption, both practically and reputationally. And if there’s ever an incident, not having thought of it as a supplier carries no weight whatsoever with a regulator. The obligation doesn’t care whether the relationship felt formal.

Under ISO 9001, it’s a slightly different lens again, but it lands in the same place. An unapproved tool operating outside your supplier evaluation process is a gap in your management system’s control of externally provided processes, products and services, regardless of what the tool is actually used for. Quality management doesn’t distinguish between important suppliers and minor ones in the way people intuitively do. It asks whether your process for approving and monitoring externally provided elements is actually being followed, or whether it only applies to the suppliers people remember to think of as suppliers.

Then AI tools arrived, and the picture got more complicated

Everything above was already true before generative AI tools became part of daily working life. Now there’s an extra layer of complexity that most organisations haven’t caught up with yet.

A growing number of AI tools don’t just sit as a standalone platform you log into. They connect into your existing systems, often with quite broad permissions, because that’s what makes them useful. An AI assistant that can read your inbox, summarise a Slack channel, or pull context from a shared drive is genuinely helpful, and that’s exactly the problem: the usefulness depends on access, and access is where the risk sits.

Once a tool like that is connected, the honest question becomes: where is that data actually going? Is it being used to train a model somewhere outside your control? Is it being retained, and for how long? Is it being processed in a jurisdiction that doesn’t offer equivalent protection to UK data subjects? Most staff enabling these integrations aren’t asking any of these questions, because the sign-up flow makes it feel like flicking on a helpful feature, not authorising a new supplier to access your email and messaging history.

This is shadow IT’s more capable cousin. A basic unapproved tool might hold a spreadsheet of customer names. An AI tool plugged into email or Slack can potentially see everything that flows through those systems, correspondence, attachments, internal discussion, client data, in a way that’s much harder to scope or contain after the fact. The risk assessment that was already being skipped for ordinary tools becomes considerably more urgent when the tool in question has read access to the rest of your business.

Why this is really about small, well-intentioned decisions

None of this is about the big, obvious risks. Organisations tend to be reasonably good at spotting those. It’s the small, well-intentioned decisions that create the exposure: someone finds a free tool that solves an immediate problem, doesn’t experience that as onboarding a new supplier, and it quietly becomes part of how the business runs without ever passing through a risk assessment. Multiply that across a team of any size and you end up with what’s usually called shadow IT, and in my experience it’s one of the most consistent gaps across both ISO standards and GDPR obligations alike, far more common than any dramatic security failure.

A five-minute fix

The fix isn’t complicated, and it doesn’t need to slow anyone down. It needs a simple, well-understood rule: before anyone in the business creates an account with a new online tool, even a free one, and especially anything that asks to connect into email, messaging or shared drives, it gets flagged to whoever owns supplier risk. That’s a five-minute conversation, not a procurement process, and it means the decision gets made with eyes open rather than discovered eighteen months later during an audit or, worse, after an incident.

A supplier isn’t defined by the size of the contract or the formality of the relationship. It’s defined by what happens to your data once it leaves your hands. Worth asking, next time someone on the team says they’ve found a great little tool for this, what exactly it is they’ve just signed you up to, and what it can now see.

Share the Post:
what about alt text for the picture?13:22Claude responded: Helen Molyneux, founder of Cambridge Risk Solutions, ISO 22301 and ISO 27001 Lead AuditorHelen Molyneux, founder of Cambridge Risk Solutions, ISO 22301 and ISO 27001 Lead Auditor

Helen Molyneux is the founder and director of Cambridge Risk Solutions. A certified Lead Auditor for ISO 22301 and ISO 27001, she has spent nearly two decades helping organisations across the public and private sectors build genuine resilience — not just documented compliance. She writes from practice, not theory.

Work with us →