When the supplier is the target: where your data lives, who can reach it, and your real risk

Supplier attacks are now routine

• 2023: an attack on one managed IT provider left around 80 conveyancing firms without access to case files, email and phones. House moves stalled while firms built manual workarounds.
• 2023: a flaw in one widely used file transfer product, MOVEit, was exploited to take data from thousands of organisations, many of which had never heard of the product because their suppliers used it.
• 2024: attackers used stolen passwords to take data from customer accounts on the Snowflake data platform. The platform itself was not breached: the accounts did not require multi-factor authentication.
• 2025: access tokens from a sales chat tool connected to many companies' customer systems were stolen and used to export their data, without breaking into those systems directly.
• 2025: a cyber attack took the Legal Aid Agency's online systems out of normal use for months.

The patterns repeat: one supplier, many victims; data reached through a connected app rather than the main system; and basic controls missing at the edges.

Where is the database, really?

"Hosted in the UK" is a start, not an answer. Ask which hosting provider runs the platform, where the main database, the disaster recovery copy and the backups are held, and whether any of it is processed elsewhere: search, AI services, email delivery, analytics, support tools. Each of those is a sub-processor holding some of your data, and each should be named in the contract with notice of changes.

Who has access?

• Vendor staff: support, developers and database administrators. Who can see your data, from which countries, and is access granted only when needed, approved and logged?
• Sub-processors: hosting, AI and support providers, each with their own staff and their own security.
• Support tickets: screenshots and data sent with support requests often end up in a separate ticketing system. Where is that, and who can read it?
• Connected apps: every integration holds a key to your data. Can you see them all, limit what each can reach, and revoke them instantly?
• Your own people: most account takeovers still start with a stolen password. Is multi-factor authentication enforced for every user, including the vendor's?

How much are you at risk?

No supplier is risk-free, and a well-run platform is usually far safer than a server in the office. The question is how much of the risk you understand, and how you would cope:

• Blast radius: if one customer's account, or the vendor itself, were compromised, how much could be reached? Separate databases and firm-specific encryption keys limit the damage.
• Evidence: what do the vendor's certifications actually cover, when was the last independent penetration test, and will they share the summary?
• Honesty: will they tell you about past incidents, and commit to notifying you within hours, not weeks?
• Continuity: if the system were unavailable for two weeks, could you still meet every critical date, answer clients and know your client account balances? Firms that held their own copy of key information were best placed in every incident above.
• Insurance: what does your cyber insurer expect you to have checked about your suppliers?

What to ask, and what to see

1. Name the hosting provider, the locations of the database, disaster recovery and backups, and every sub-processor.
2. Show how vendor staff access to our data is requested, approved and logged, and where those staff are.
3. Show every connected app and token with access to our data, and revoke one.
4. What incidents have you had, and how quickly would you notify us?
5. What would we have, and how would we work, if the service was down for two weeks?