Your supplier was breached. What did you do before it happened?

On 14 September, customers of City Relay, a London property management company that describes itself as "London's most trusted property management company", received an email telling them that attackers had twice got into the firm's Metabase Cloud instance and taken personal data. The Register's report of the breach lists what may have been exposed: names, email addresses, postal addresses and telephone numbers; account passwords; bank account numbers, sort codes, IBANs, SWIFT references and the names and addresses on the accounts; and, because this is a company that lets and manages homes, the locations of stored keys and the codes to the lockboxes that hold them.

It is worth pausing on that last item. A property manager holds a great deal of data that would be inconvenient to lose. It holds one category of data that would let a stranger walk into someone's home. That category was readable by a reporting tool.

I want to be fair to City Relay from the outset. The vulnerability was in the supplier's product, not theirs. They say they were unaware of it, and I believe them. When they found out, they changed the access codes and the key-storage codes, told their customers what to watch for, brought in specialists and involved the authorities. That is a reasonable response. This article is not about the response. It is about the years before it, because the breach at City Relay is the same breach I have seen a dozen times this year in different clothes, and the cause is not a clever attacker. The cause is a decision, usually made in about ten minutes, to put something in the cloud and to treat its security as somebody else's problem.

What actually happened

Metabase is a business intelligence tool. You point it at a database, and it draws dashboards and answers questions. It is popular precisely because it is quick to set up: connect it, and within an hour the operations team has the charts it always wanted. Metabase Cloud is the hosted version, where the supplier runs the software and you supply the database connection.

On 3 August, Metabase learnt of a problem when a cloud customer reported an API key that nobody had created. By 6 August it had published patched versions and an account of what had gone wrong: an unauthenticated SQL injection in the password-reset endpoint, later assigned CVE-2026-72898, which let an attacker mint themselves a session and become an administrator without knowing a single credential. Metabase said that under three per cent of its cloud customers had been compromised before the fix was deployed. Framework, the laptop maker, the form builder Tally, the AI coding platform Kilo Code and the automation platform n8n were among those who told their own customers in the days that followed.

City Relay learnt of its intrusion on 8 September and wrote to customers on 14 September. The Register notes that the company has not confirmed that its attackers used the August vulnerability, and I will not assume it either. What is not in doubt is the shape of the thing: a reporting tool, hosted by a third party, connected to a database that held everything.

Dray Agha of Huntress put the central point neatly in the same article. Metabase connects to your database, so what an attacker gets from Metabase depends entirely on what you gave Metabase. Point it at a warehouse of anonymised usage metrics and the attacker gets usage metrics. Point it at the live transactional database and the attacker gets the sort codes and the lockbox codes. The tool did not decide that. Somebody at the customer did, and almost certainly without thinking of it as a decision at all.

The ten-minute decision

Here is how it happens, and I am describing a pattern rather than City Relay in particular, because I do not know the detail of their setup and I do know the detail of many others.

Somebody in the business needs reporting. They look at the options, and the hosted one is cheapest and quickest. They sign up with a company card. The tool asks for a database connection string, and the quickest way to make the dashboards work is to give it the credentials the application already uses, which can read everything. Nobody in security is asked, because the purchase is below the threshold at which anybody is asked, and because it is "just a dashboard". The tool works beautifully. Everyone is pleased. The supplier is now a full participant in your security, holding a live key to your most sensitive data, and nobody has written that fact down anywhere.

The cloud is not the villain here. Hosted software is, on the whole, run by people who patch faster and monitor better than most in-house teams. Metabase went from a customer's first report to a public fix in three days, which is a better record than many customers would manage on a self-hosted copy. The trouble is a mental model: "in the cloud" is heard as "not my problem", when the honest translation is "my problem, with the work of running it delegated to someone else". Every cloud supplier's contract says something to that effect, usually under the heading of a shared responsibility model. Very few customers read it, and fewer still act as if they had.

There is a second, quieter failure in the City Relay timeline that I think matters more than the vulnerability. Metabase published on 6 August. It told its customers to revoke sessions, review API keys and administrators, rotate database credentials and check their logs. City Relay learnt of its own intrusion on 8 September. I do not know why there was a month between those dates, and it may have been for reasons that reflect no discredit on anyone. But it is exactly the gap that a supplier register closes. If Metabase Cloud had been on a list, with a named owner, and that owner had been subscribed to the supplier's security announcements, then somebody in the business would have read that notice on the day it was published, known immediately what data the tool could see, and rotated the credentials that afternoon. The supplier did its part. The notice needed a recipient.

Why "due diligence" is the whole game

The UK's Cyber Security Breaches Survey 2025/2026, published in April, found that fifteen per cent of businesses had formally reviewed the cyber security risks posed by their immediate suppliers, and six per cent had looked beyond them to the wider supply chain. Among large businesses the figure was just under half. So the honest starting position for most organisations reading this is that the review has never been done, and the register does not exist.

I want to be careful about how I put the next part, because this is a subject that is usually sold with fear, and fear is a poor motivator for the kind of steady, slightly dull work that supply chain security actually is. So let me put it the other way round, as a description of a good morning.

Picture the morning the email arrives from a supplier saying they have had an incident. You open a register and within two minutes you know what that supplier holds, what it can reach, who owns the relationship, what the contract says they must tell you and by when, and what you checked about them last time and when. You know which credentials to rotate because they are listed. You can tell your board, your customers, your insurer and, if it comes to it, the Information Commissioner's Office, exactly what you did to satisfy yourself about this supplier before anything went wrong, with dates. That morning is still not a pleasant one. But it is a morning you are in control of, and it is available to any organisation for about an afternoon's work to set up and an hour a quarter to maintain.

The regulatory framing is worth knowing, because it converts that afternoon from good practice into something you can point to. Under UK GDPR, Article 28 requires you to use only processors who provide "sufficient guarantees" of appropriate security, and Article 5(2), the accountability principle, requires you to be able to demonstrate compliance, which in practice means evidence that you looked. The ICO's guidance on contracts and liabilities between controllers and processors makes clear that the controller must satisfy itself, before appointing a processor, that the processor offers those guarantees, and must be able to show how it did so. When the ICO decides whether and how much to fine after an incident, its published approach weighs the degree of responsibility of the organisation and the measures it had in place. A documented, dated review of the supplier, of the data shared with it and of the access granted to it is precisely the kind of measure that shifts that weighing. It does not make you immune. It makes you a controller who did the work, rather than one who could not say what the tool had access to.

For regulated firms the requirement is more specific still. DORA requires financial entities in the EU to maintain a register of information on all contractual arrangements with ICT third-party providers, and the FCA's operational resilience rules ask UK firms much the same about important business services and the third parties they depend on. NIS2, which reaches UK suppliers through their EU customers, names supply chain security explicitly among its required measures. ISO 27001:2022 carries five controls on supplier relationships, including one specifically on the use of cloud services, and the NCSC's supply chain security guidance sets out twelve principles of which the first is, in effect, to understand what needs protecting and why. The Cyber Security and Resilience Bill, at the time of writing at report stage in the Lords, will extend supply chain duties further for the sectors it covers. None of this is new, and none of it is exotic. It is all the same instruction: know your suppliers, decide what they may hold, check them, and write it down.

A practical guide to reviewing your supply chain

What follows is the programme I would put in place in any organisation, sized so that a firm of twenty people can actually do it. It is deliberately unglamorous. The whole value is in its being done regularly and recorded.

Start with a register, not a questionnaire

The first task is to find out what you have, and most organisations are surprised. Ask finance for every recurring card payment and every supplier invoice with the word "software", "cloud", "hosting", "platform" or "subscription" on it. Ask your identity provider which applications have single sign-on configured. Ask your developers what API keys, webhooks and database connections exist and where they go. Ask your operations and marketing teams which tools they use that nobody else knows about. The Metabase-shaped supplier is usually found in the third or fourth of those conversations, because it was set up by one enthusiastic person and works so well that nobody has needed to mention it.

Put every one of them in a register. A spreadsheet is fine; ours started as one. The columns that matter are these.

The single most important column is "data it holds or can reach", and the single most common error is to describe the tool rather than the data. "Analytics dashboards" is a description of the tool. "Read access to the production database, including customer bank details and property access codes" is a description of the risk.

Tier by data and access, not by spend

Procurement instinct is to scrutinise suppliers in proportion to what they cost. Security must scrutinise them in proportion to what they can reach. A hosted reporting tool at a few hundred pounds a month with a connection string to the live database is a critical supplier. The office coffee contract is not, however large the invoice.

Three tiers are enough. A supplier is critical if it holds or can reach personal data of the kind that would cause real harm if lost, or if it has credentials or network access into your environment, or if its failure would stop you operating. It is important if it holds business data you would rather not lose, or if it can reach systems that are one step removed from the crown jewels. Everything else is routine. Critical suppliers get reviewed every quarter and on any trigger event. Important suppliers get reviewed annually. Routine suppliers get a line in the register and a look every couple of years.

Assess proportionately, and collect evidence rather than promises

For critical suppliers you want to see, not be told. Ask for the current ISO 27001 certificate and check the scope actually covers the service you buy; ask for the SOC 2 Type II report or a summary of it; ask for a summary of the most recent independent penetration test; ask for their vulnerability disclosure policy and, importantly, how they notify customers of security issues, and confirm that your named owner is on that list. Ask where the data is held and who the sub-processors are. Ask what happens to your data at the end of the contract. For a supplier like Metabase, whose product exists to connect to your database, ask specifically how the connection is secured, whether the product supports read-only connections and column-level restrictions, and whether you can restrict its access to a fixed set of source addresses.

For important suppliers a short questionnaire and a copy of the certificate will do. For routine suppliers, the register entry is the assessment.

Record what you asked, what you received, and what you concluded, with the date. Keep the documents. In two years, when the supplier has an incident, the question will not be "were they secure?", to which nobody can answer yes; it will be "what did you do to satisfy yourself?", to which you will want to answer with a file.

Design the integration for the breach you are assuming will happen

This is where City Relay's story turns from an unlucky one into an instructive one. The supplier's product was vulnerable for a few days. The consequences depended entirely on integration choices that had been made months or years before.

A reporting tool should never be connected to a production database with the application's own credentials. Give it its own database user, with read-only rights, over a defined set of tables and columns, and ideally against a read replica rather than the primary. If the tool needs a customer's name and postcode to draw a map of properties, it does not need the sort code, the IBAN or the lockbox code, and those columns should be excluded from the view it sees. Where a column must exist in the database but should never be readable in bulk, encrypt or tokenise it in the application, so that what a reporting tool or a compromised query sees is a token, not a code that opens a front door. Restrict the database to accept connections only from the supplier's published addresses. Turn on query logging on the database side, so that if the supplier is compromised you can see what was actually read rather than having to assume the worst and tell every customer.

The same discipline applies to every other kind of integration. An API key should have the narrowest scope the product offers, and a separate key per supplier, so that one can be revoked without breaking everything else. A single sign-on integration should be reviewed for what attributes it releases. A file transfer should send the fields the supplier needs and no more. The principle is the same in each case: assume the supplier will be breached, and arrange matters so that the breach is a nuisance rather than a catastrophe. This is not a criticism of the supplier. It is the courtesy of not making your security depend on their perfection.

Watch the sources the supplier actually uses

Every serious cloud supplier has a security announcements list, a status page, a security advisory page or all three. The moment you decide a supplier is critical, subscribe your named owner and a shared mailbox to those sources, and record in the register where they are. Then make sure that mailbox is read by somebody every working day. A notice that arrives on 6 August and is read on 8 September has done nobody any good.

If you run a managed SOC, or use one, this is a natural thing to hand over: the SOC365 team monitors supplier advisories and vulnerability feeds for our clients as a matter of course, and our CVE Explorer tracks which vulnerabilities are being exploited in the wild. But it does not require a SOC. It requires a mailbox, a subscription and a habit.

Write the review down, every time

The register tells you what you have. The review record tells you what you did. For every review, critical suppliers quarterly and the rest on their schedule, write a short dated note: who carried it out, what evidence was checked, what changed since last time, what was found, what actions were agreed and by whom, and when the next review falls. Attach or link the evidence. A page of prose or a row in a second sheet is fine. Store it somewhere that survives staff turnover and that a regulator, an auditor or an insurer could be shown without embarrassment.

Trigger a review outside the schedule whenever something changes: the supplier publishes a security advisory, the supplier is acquired, you start sending it a new category of data, a new integration is built, the contract renews, or you read about the supplier in the news. Record the triggered review in exactly the same way. It is the dated, repeated, unremarkable record that constitutes due diligence. A magnificent one-off assessment from 2023 with nothing since is worth less than four short quarterly notes.

Rehearse the supplier breach

Twenty-five per cent of UK businesses have a formal incident response plan, and most of those plans assume the incident starts inside their own walls. Add a second scenario, the one that actually happens: a supplier emails to say it has been compromised. Walk through it with the people who would be involved. Who receives the notice? Who opens the register and confirms what the supplier held? Who rotates which credentials, and are they written down anywhere the on-call person can find them? Who decides whether personal data is at risk, and starts the seventy-two-hour clock for the ICO? Who drafts the customer notice, and what will it say about what you did beforehand? An hour spent on this once a year turns the good morning I described earlier from an aspiration into a rehearsal.

Put the ten-minute decision on a form

Finally, close the gap at the front. Any new cloud service, integration or data sharing arrangement, however cheap, goes through a short intake before it is connected: what will it hold, what will it reach, which tier is it, who owns it, and has the integration been designed to the least access it needs. This is not a procurement gate designed to slow people down. It should take ten minutes, which is exactly as long as the decision it replaces, and it should be seen as the way to get a new tool approved quickly rather than the way to have it refused. The reward for filling in the form is that the tool goes in the register, the owner gets the security notices, and the business gets its dashboard with a read-only user instead of the keys to the kingdom.

What this looks like at minimum

If you are a small firm and the above reads as more than you can take on, here is the version that fits on one page and takes an afternoon. Make the list of every cloud service and integration you use, with what each one can reach. Mark the ones that can reach personal data, money or access to premises as critical. For each critical one, subscribe a real mailbox to its security notices, confirm the integration uses its own restricted credentials, and put a quarterly reminder in the calendar. Each quarter, spend an hour looking at the critical ones and write five lines about what you checked. That is the whole programme. It is not sophisticated, and it does not need to be. What it gives you is the ability, on the morning the notice arrives, to say what the supplier held, to fix it that day, and to show anyone who asks that you had been paying attention all along.

City Relay's customers were told to check their bank statements, to watch for phishing and to change any reused passwords. The company changed the lockbox codes. It is the right advice and the right action, and it will have been a hard week for everyone involved. The lesson for the rest of us is not that the cloud is dangerous or that suppliers cannot be trusted. It is that "someone else's problem" is not a security control, and that the small, regular, documented act of knowing what your suppliers can reach is the difference between a breach you explain and a breach that explains you.

Frequently asked questions

Does using a cloud supplier transfer legal responsibility for a data breach? No. Under UK GDPR the controller remains responsible for personal data it shares with a processor, and must be able to show it carried out due diligence before appointing that processor and has a contract containing the Article 28 terms. A processor can also be held liable for its own failings, as recent ICO penalties against processors show, but this sits alongside the controller's responsibility rather than replacing it.

How often should we review a supplier's security? It depends on what the supplier can reach. A supplier holding personal data, financial data or credentials into your environment should be reviewed quarterly and whenever a trigger event occurs, such as a security advisory, a new integration, an acquisition or a contract renewal. Suppliers holding ordinary business data can be reviewed annually. The frequency matters less than the record: a short dated note each time is what demonstrates due diligence.

What evidence should we ask a critical supplier for? A current ISO 27001 certificate with a scope covering the service you use, a SOC 2 Type II report or summary, a summary of the latest independent penetration test, a vulnerability disclosure policy, the sub-processor list and data locations, the breach notification commitment in the contract, and the address where security advisories are published. Record what you received and when.

We connected a reporting tool to our main database years ago. What should we do this week? Create a dedicated read-only database user for it, limited to the tables and columns the reports need, and replace the credentials it currently uses. Confirm that sensitive columns such as bank details, passwords and access codes are not in its view, and encrypt or tokenise them in the application if they must be stored. Restrict database connections to the supplier's published addresses, enable query logging, subscribe to the supplier's security notices, and add the supplier to your register with a review date.

Is a spreadsheet good enough as a supplier register? Yes, provided it is complete, owned by a named person, updated when anything changes and kept somewhere durable. Larger or regulated organisations will eventually want a governance tool, and firms under DORA need their register of information in a prescribed format, but the value comes from the content and the discipline, not the software.