The Login Screen Is a Supply Chain: Mapping the SaaS Tools Your UK Business Can't Survive Without

Most UK cloud teams can tell you their hyperscaler's regions, their reserved instance coverage, and roughly how many nines they're paying for. Ask them which third-party SaaS tools would stop the business dead on a Tuesday morning and the answer is usually a long pause followed by "well, obviously Microsoft 365."

That's a start. It isn't a map.

The uncomfortable truth about modern UK businesses is that the infrastructure you audit is rarely the infrastructure that fails you. You've spent three years tightening your cloud account — tagging, guardrails, cost anomaly alerts, the lot. Meanwhile payroll runs through a bureau that runs through a platform that runs on somebody else's cloud, and nobody in the building has read that contract since 2022.

This isn't a scare piece. It's a drawing exercise.

Start with the browser, not the ledger

Your finance team knows what's on the company card. Your staff know what's in their bookmarks. Those are two different lists, and the gap between them is where the risk sits.

Pull the SSO logs if you have them. Pull the expense reports if you don't. Cross-reference. You'll find the obvious names — the productivity suite, the CRM, the finance system — and then you'll find the rest. The design team's plugin that costs £40 a month and holds the only copy of the brand asset library. The scheduling tool someone's PA bought in 2023 and never cancelled. The AI note-taker that joins every meeting and quietly transcribes client calls.

None of these will show up on a cloud architecture diagram. All of them will show up in someone's Monday.

Map to processes, not departments

An org chart tells you who gets annoyed when a tool goes down. A process chart tells you what actually stops. Those aren't the same thing, and the second one is the only one that matters when you're drawing a dependency map.

List the handful of processes that genuinely can't pause: payroll, customer onboarding, statutory reporting, invoice approval, complaint handling, whatever your regulator expects you to keep doing. For each one, write down every SaaS tool in the chain, end to end. Be honest about the manual steps people do "just in case" — those are the fallbacks you already have, and they're worth knowing about.

Then ask the question that makes the room go quiet: which of these, if it disappeared at 9am on a Tuesday, would stop the process cold?

Dependencies stack, and they don't tell you

Here's where it gets genuinely awkward. SaaS vendors don't sit in isolation. Your e-signature provider runs on a hyperscaler you have no contract with. Your support desk authenticates through an identity provider that was acquired eighteen months ago and has been quietly migrating tenants ever since. Your payroll bureau uses a middleware layer whose name nobody at your organisation has ever heard.

You don't need to map the whole tree. You need to know which of your vendors have a single upstream dependency that could take them out, and whether that dependency is one you've already accepted elsewhere. If four of your critical tools all sit on the same cloud region, you don't have four vendors. You have one, with four invoices.

Read the contract like a risk document, not a receipt

Most UK teams treat SaaS contracts the way they treat insurance: signed once, filed, forgotten. That's a mistake, because the contract is where the fallback actually lives. Four clauses are worth ten minutes each.

Exit and data export. Can you get your data out, in what format, and how long does it take? "Reasonable endeavours" is not a format.

Service credits. Understand what they actually are. A partial refund, not a rescue. If the tool is down for a day and your team loses a day of onboarding, the credit covers roughly nothing.

Sub-processor notification. Under UK GDPR you should know who's processing your data and get notice when that changes. If the vendor's sub-processor list is a PDF last updated in 2024, that tells you something.

Termination for convenience. If the vendor can walk away with 30 days' notice and you can't, you're not a customer — you're a tenant.

The UK bits that actually bite

If you're regulated — financial services, health, anything that keeps the ICO on speed dial — the operational resilience rules that took full effect in 2025 apply to your third parties, not just your own systems. The 72-hour breach notification clock doesn't pause because the incident happened inside a vendor's tenant.

And be sceptical about data residency claims. "UK data" often means "primary region is in the UK, backups and support tooling aren't." If that distinction matters to your regulator, get it in writing, in the contract, with a named region.

Rehearse the one that hurts

Once the map exists, pick the vendor whose loss would hurt most and run a tabletop exercise. Not a full DR test — a conversation. Who notices first? Who calls the account manager? What's the manual workaround, and how long before it collapses under its own weight? Where's the break-glass access if the identity provider itself is the thing that's down?

An hour of that is worth more than another audit of the cloud account you already have under control.

Keep it to one page, and keep it alive

The diagram is only useful if it stays current. Give it an owner — not procurement alone, not security alone, but someone whose job is to keep asking the awkward question. Review it quarterly, or whenever a vendor gets acquired, which in 2026 feels like roughly every other week.

It will be an uncomfortable page. That's the point. Your cloud provider is almost certainly the best-audited, best-documented vendor you have. The rest of the stack is a pile of credit card receipts and goodwill — and the outage you should be rehearsing probably isn't in your cloud account at all.