On Monday, City Relay, a property management firm that looks after thousands of London homes on behalf of their owners, wrote to its landlords. Someone had got into the company's cloud analytics platform, twice, and taken data out of it. The Register's report lists what may have gone: names, email addresses, postal addresses and telephone numbers; bank account numbers, sort codes, IBANs and SWIFT references, with the account names and addresses to go with them; account passwords; and, in the phrase that will stay with the story, "property access details" and the codes for the lockboxes where keys are kept.
City Relay says it discovered the intrusion on 8 September and told customers on 14 September. It says it has changed every affected access and key-safe code, that the old ones no longer work, and that it has "no evidence of any unauthorised property access arising from the incident". It attributes the whole thing to "a vulnerability in the platform that we were unaware of".
I believe every word of that last sentence, and I think it is the most important sentence in the story, because of course they were unaware of it. Nobody at a property management company is going to know about an undisclosed SQL injection in a business intelligence product. The question a board should be asking is not "why didn't we know about the bug" but "what had we decided, in advance, about what that tool could reach if it were ever compromised". That is a supply chain question, and I am seeing the same shape of incident often enough now, in our SOC and in the calls that come in afterwards, that it is worth setting out properly. This piece is in two halves: what actually happened, and what a small or mid-sized organisation can do about it with an afternoon and a spreadsheet, so that when a supplier fails, and one will, you are holding a record of reasonable decisions rather than a blank page.
The tool in the middle
The platform in question is Metabase Cloud. Metabase is a business intelligence product: you point it at a database, it lets non-technical staff build dashboards and ask questions of the data in plain English or SQL, and it is very good at that. The cloud edition means Metabase hosts the application and you give it credentials to reach your database. A great many companies use it, including plenty who would not describe themselves as technology firms, because it is the quickest way to answer "how many bookings did we take last month" without asking a developer.
On 3 August a Metabase customer noticed API keys being created on their instance outside working hours and reported it. Metabase's own account of what followed is unusually candid and worth reading in full. The flaw, now CVE-2026-72898, sat in the password reset endpoint, /api/session/reset_password. The endpoint accepted parameters it was never meant to; one of them, an undocumented user-id, was merged into the request without being stripped, and a quirk of the SQL library the product is built on allowed a specially shaped value to be treated as literal SQL rather than as data. The result was an unauthenticated SQL injection against Metabase's own application database. From there an attacker could create sessions and API keys for themselves and then walk in through the front door as an administrator. Metabase says every installation from version 0.58 onwards was vulnerable, that it shipped patched builds on 6 August, and that "under 3% of our cloud customers were compromised as a result of the vulnerability before patching".
Under three per cent sounds small until you remember what an administrator of a business intelligence tool can do. Metabase holds the credentials to whatever databases it has been connected to, because that is its job. An administrator can run any query against them, export the results, and read the connection settings. So the vulnerability was in Metabase, but the data that walked out belonged to Metabase's customers, and how much walked out depended entirely on what each customer had connected.
That is why this is the third time in six weeks the same product has produced the same story. Framework, the laptop maker, lost the names, email addresses, telephone numbers, postal addresses and login IP addresses of every customer it had, plus VAT and EIN numbers for business buyers; the attacker was in on 3 August, Metabase told Framework on 6 August, and Framework went public on 10 August. Tally, the form builder, lost email addresses and hashed passwords. n8n, the workflow automation company, found 136 records had been touched, and in the course of the investigation discovered a historical bug that had left a small number of its own customers' passwords in plain text. Each of these companies had connected an analytics tool to a database that contained more than analytics.
Framework's statement contains the sentence that all of them could have written: "we are reviewing and improving our methodology for data storage in external database vendors." The reviewing is happening now because it did not happen before. That is not a criticism of Framework in particular; it is the industry's default.
Somebody else's problem
Here is the pattern as I see it from the SOC side. A business function, usually operations or finance, wants to see its numbers. Someone finds a tool that does it beautifully. The tool is cloud-hosted, so there is nothing to install and nothing for IT to maintain, which is precisely the selling point. It asks for database credentials during set-up, and whoever is doing the set-up gives it the credentials they have, which are almost always the production credentials with read access to everything, because creating a restricted reporting user takes a developer half an hour and the person setting up the dashboard is not a developer. The supplier has an ISO 27001 certificate and a SOC 2 report, both of which are real, and both of which describe how the supplier runs the supplier's own systems, not what will happen to your data when the supplier's software has a bug. Everyone involved has, without ever saying it aloud, decided that security is somebody else's problem. The supplier assumes the customer will connect it sensibly. The customer assumes the supplier will not have a vulnerability. The security team, if there is one, does not know the tool exists.
"It's in the cloud" has become a phrase people use in place of a decision. It sounds like an answer to the security question, and it is not one. Cloud hosting moves some responsibilities to the supplier: the physical estate, the operating system, the patching of the application itself. It does not move the responsibility for what data you gave it, what credentials you gave it, or how much of your business a compromise of that one product can reach. Those remain yours, and in law they remain yours very explicitly, which we will come to.
Dray Agha of Huntress made the point in The Register with a precision I would not improve on: "A company linking Metabase to a general analytics database will only expose harmless user metrics. A company that connects it directly to their core transactional database risks exposing highly sensitive financial records and credentials." He added that financial details "should also be encrypted or tokenized when held in a database. Keeping this information readable creates a massive risk if a connected reporting tool is ever compromised."
Read City Relay's list of exposed data against that and you can reconstruct the architecture without ever seeing it. Bank details, in full, readable. Passwords, in a form the attacker considered worth taking. Lockbox codes, which are, functionally, plaintext credentials to physical front doors, sitting in a table a dashboard tool could query. Nobody set out to build that. It accreted, one sensible decision at a time, each one made by someone for whom security was a different department.
There is a further question in the timeline that I would want answered if I sat on City Relay's board. Metabase says it patched its cloud customers on 6 August, and it evidently knew which of them had been compromised, because Framework heard from Metabase that same day. City Relay says it learned of its intrusion on 8 September, more than a month later, and has not said whether the August flaw was the one used against it. Either Metabase's notification did not reach the right person, or it reached someone who did not recognise it as an incident, or the intrusion was something else entirely. All three are supply chain failures of a kind, and the second one, the security email that lands in the inbox of the person who set up the dashboard eighteen months ago and has since changed roles, is the most common of all.
Where the regulator stands
Under UK GDPR, City Relay is the controller of its landlords' data and Metabase is its processor. The law is clear about the direction of responsibility. Article 28 says a controller may only use processors that provide "sufficient guarantees" of appropriate technical and organisational measures. The ICO's own guidance spells out what that means in practice: controllers "should ensure a processor's compliance on an ongoing basis, in order for them to satisfy the accountability principle and demonstrate due diligence", and "a controller is primarily responsible for its own compliance and ensuring the compliance of its processors".
Then comes the sentence that ought to be pinned above every procurement desk. A controller is liable for damage to individuals when its processing infringes the law, but "a controller will not be liable for damage resulting from a breach of the UK GDPR if it can prove it was not in any way responsible for the event giving rise to the damage". Prove. Not assert, not assume. A controller that cannot show what it asked its supplier, what it was told, what access it granted and why, has nothing to prove with. A controller that can show all of that is in a very different conversation with the regulator, with its insurer, and with its customers.
The ICO has spent the last eighteen months making the point from both ends. In March 2025 it issued its first ever fine against a processor, £3.07 million against Advanced Computer Software Group for the 2022 ransomware attack that took out NHS 111 and affected 79,404 people. The failings were ordinary: gaps in multi-factor authentication, insufficient vulnerability scanning, patches not applied. The fine had started at over £6 million and was halved because Advanced engaged with the NCSC, the NCA and the NHS, notified quickly, and cooperated. In October it fined Capita £14 million for the 2023 breach that touched 6.6 million people, and among the findings was that a security alert took 58 hours to get an effective response against an internal target of one hour. Both cases say the same thing. The regulator will look at the control you had, the alert you received, and the time you took. It gives credit for evidence of care before the incident and for good conduct during it. It does not give credit for having been surprised.
There is more coming. The Cyber Security and Resilience Bill is now in the House of Lords. It brings managed service providers into direct regulation, gives regulators a mechanism to designate critical suppliers to regulated firms, and sets a 24-hour initial incident notification with a fuller report at 72 hours. A property management company is not in scope of that Bill. Its bank, its insurer, its larger corporate landlords and the councils it deals with increasingly will be, and the supplier questionnaires that flow downhill from regulated firms will land on companies like City Relay whether or not the Act names them. The direction of travel is that being able to describe your supply chain, and evidence that you have looked at it, stops being good practice and becomes a condition of doing business.
The NCSC already publishes a five-stage approach to assessing supply chain cyber security, written for medium and large organisations with procurement and risk functions. It is good. Most of the companies I am describing do not have a procurement function; they have a founder, an operations lead and an accountant. What follows is the same thinking, cut to fit.
A supplier review you can actually run
The purpose of what follows is not to make you an expert in third-party risk. It is to leave you, at the end of an afternoon, with a document that says: these are the suppliers who can reach our data, this is what each can reach, these are the questions we asked, this is what they said, this is what we decided and why, and this is when we will look again. That document is your due diligence. It is what you hand to the ICO, to your insurer, and to your own board on the day a supplier tells you it has had an incident, and it is what turns "we were unaware" into "we had assessed this, here is our reasoning, and here is what we did the moment we were told".
Find out what you actually use
You cannot assess what you do not know you have, and nobody knows what they have. Ask the finance system for every recurring card payment and direct debit to a software company, however small, because the £29-a-month tool that someone expensed is exactly the one nobody assessed. Ask whoever runs your identity provider for the list of applications that have been granted access through single sign-on, and separately for every OAuth consent staff have given to third-party apps in Google Workspace or Microsoft 365, because "sign in with Google" is a supplier relationship whether or not anyone signed a contract. Ask your developers what services hold database credentials or API keys, and look in the secrets store if you have one and in the environment files if you do not. Ask each department head what tools their team could not do without for a week. Compare the lists. The gaps between them are where the untracked suppliers live.
The output is a list. It will be longer than you expected. That is fine; most of what is on it will turn out to matter very little.
Sort by blast radius, not by invoice
The instinct is to rank suppliers by how much you pay them. Resist it. The ranking that matters is what each supplier could reach if it were fully compromised tomorrow, with an attacker holding every credential and permission you have given it. Three questions decide the tier. What categories of data can it see: contact details, financial details, credentials, anything that opens a door or moves money? Is its access read-only or can it change things? And does it hold standing access, a stored password or key that works at three in the morning, or does it only see what a person sends it during working hours?
A reporting tool with read access to a production database is tier one, regardless of what it cost. So is anything that holds bank details, anything with write access to your identity provider, and anything that can send email as you. Your payroll provider is tier one. Your video conferencing tool, which sees meeting titles and not much else, is tier three. The point of tiering is that you spend your attention where a compromise would hurt, and give the rest a light touch with a clear conscience.
Ask a small number of questions that have answers
The industry has trained suppliers to expect a three-hundred-question spreadsheet, and trained itself to file the responses without reading them. Do not do that. For a tier one supplier, ask perhaps a dozen questions to which a real answer is short and checkable, and record the answers verbatim.
Where is our data held, and which sub-processors can reach it? How do you tell us about security vulnerabilities in your product, and how quickly after you know? Where is your security advisory page, and can we subscribe to it? Within how many hours will you tell us if you discover our data has been accessed, and is that in the contract or just a policy? Do you support single sign-on and enforce multi-factor authentication for our users, and can we restrict access to our IP addresses? When we connect a data source, what is the minimum permission you need, and do you document it? Are our credentials encrypted at rest, and who at your company can read them? Do you have external penetration tests, and will you share the summary and the remediation dates? What happens to our data when we leave? Which certifications do you hold, and what is their scope?
That last question is the one most people skip. An ISO 27001 certificate has a scope statement, and it is worth reading, because "the information security management system supporting the delivery of the hosted platform" is not the same as "the security of our software". A SOC 2 Type II report describes controls over a period, and its exceptions section is more useful than its cover letter. Neither would have told anyone about CVE-2026-72898. Certification tells you a supplier has a process. It tells you nothing about whether your particular connection to that supplier is safe, because that part is yours.
Design the connection as if the supplier will be breached
This is the section that would have changed City Relay's story, and it is entirely within the customer's control. Assume the tool will be compromised. Now decide what you are prepared for a compromised tool to be able to read.
For a reporting or analytics product, give it its own database user with read access only to the tables and columns a dashboard needs, and build that from a view or a replica rather than from the live transactional database. A bookings dashboard needs dates, property identifiers and amounts; it does not need the bank account the amount was paid into, the password the customer logs in with, or the code that opens the key safe. If the product needs a customer identifier, give it an opaque one. If finance needs to reconcile against bank details, that is a job for the finance system with its own controls, not for the dashboard tool.
Some of what was in City Relay's database should not have been readable by anyone, in any tool. Passwords are stored as salted hashes with a modern algorithm, or the system is wrong. Bank details are encrypted or tokenised so that a query returns something that cannot be used without a key the reporting tool does not have. Lockbox codes are credentials and get the same treatment. None of this is exotic; it is the ordinary discipline of not putting the keys in the same drawer as the map.
Then constrain the path in. Turn on single sign-on so that the supplier's own login is not the only thing standing between the internet and your data. Restrict access to your office and VPN addresses if the product allows it. Rotate the credentials you gave the supplier on a schedule and immediately if anyone who knew them leaves. Write down, in the register, exactly what the tool can reach and why, so that when a vendor advisory arrives, the first question, "what could this get to", is answered in thirty seconds rather than a fortnight.
Put the important things in the contract
Standard terms from a SaaS vendor are written by the vendor's lawyers for the vendor's benefit. You will not be able to renegotiate them for a £29-a-month tool and you should not try. For tier one suppliers, though, four things belong in writing. The processor terms UK GDPR requires under Article 28, which a serious supplier will have as a standard data processing agreement; read it rather than accepting it. A notification commitment measured in hours from the supplier becoming aware, not from the supplier finishing its investigation, and short enough that you can meet your own 72-hour clock to the ICO. A right to receive security testing summaries and, for the largest relationships, a right to audit or to appoint someone to do it for you. And an exit clause that says what is deleted, when, and how they will confirm it.
If the supplier will not agree to any of these, that is an answer too, and it goes in the register.
Watch the things that would have warned you
Metabase learned of its own zero-day because a customer noticed API keys being created out of hours and asked why. That is the whole of supply chain monitoring in one sentence: know what normal looks like for each connection and notice when it changes. For a tier one supplier, that means someone subscribed to its security advisories and status page, with a rule that routes those messages to a monitored address rather than to the inbox of whoever signed up two years ago. It means the database user you created for the tool has its query log reviewed, or better, alerted on, so that a full export of the customers table at 03:00 generates a phone call. It means the supplier's admin audit log, if it offers one, is checked for new users, new API keys and changed data source settings. And it means the supplier's own breach disclosures are read the day they appear, with the question "does this reach us" answered and recorded even when the answer is no.
If you have a SOC, in-house or managed, tell them which suppliers hold your credentials and ask them to watch for the supplier's product in the same way they watch your own estate. If you do not, the vendor's status page and the database log are still within reach.
Write it down, every time
The register is the deliverable, so be specific about what it contains. One row per supplier: the product, what it is for, the owner inside your business, the tier and the reasoning for it, the data categories it can reach and the access it holds, the questions asked and the answers as given, the date the review was done and by whom, the decision taken, any conditions attached to that decision, and the date of the next review. Keep the supplier's answers as they sent them, attached, not paraphrased. Keep the reasoning, particularly where you accepted a risk, because "we knew the tool could see column X, and we accepted that because Y, and we mitigated it by Z" is exactly the sentence an insurer or a regulator wants to read, even when Z turned out not to be enough.
The cadence does not need to be heroic. Tier one suppliers get a proper look quarterly; that is ten minutes each if the register is maintained. Tier two annually. Everything gets looked at on a trigger: the supplier publishes an advisory, the supplier has a breach, you change what the tool is connected to, or the person who owned the relationship leaves. Each of those reviews is a dated line in the register, even when the conclusion is "no change". A register with twelve dated entries over three years is evidence of an organisation that pays attention. A register created the week after the breach is evidence of something else, and everyone reading it will know which.
Rehearse the email you will eventually receive
At some point a supplier will write to you and say it has had an incident. The email will be careful, lawyerly and vague, and it will arrive at an inconvenient time. Decide now who receives it, who decides whether it is reportable, who talks to the supplier, who talks to customers and who talks to the ICO, and rehearse it once a year for half an hour with your most important supplier as the scenario. Framework's disclosure came four days after Metabase told it; that is a company that had thought about the order of operations. Given the choice between the two positions in that timeline, you want to be the one who already knows what the tool could reach and what the next call is.
The point
City Relay will be fine, probably. It changed the codes, it wrote to its landlords, and there is no suggestion in the reporting that anyone has walked into a flat. The financial details are a longer problem and one its customers will carry on its behalf. But the interesting part of the story is not the breach. It is that a company whose business is looking after other people's front doors had put the codes to those doors somewhere a reporting tool could read them, and that nobody had asked, before August, what would happen if the reporting tool were the way in.
You will not prevent every vulnerability in every supplier. Metabase is a well-run product with a candid engineering team, and it still shipped an unauthenticated SQL injection in a password reset endpoint. What you can do is decide in advance how much of your business any one supplier can reach, put that decision in writing, look at it again on a schedule, and be able to show your workings. That is what due diligence means. It is not a defence against the breach; it is a defence against the second question, the one that comes after "what happened", which is "what had you done about it". Most organisations cannot answer that question today. An afternoon and a spreadsheet is a good start on being able to.