The supplier you stopped using still has your data

Revolut has written to its customers twice this month about their personal data being in the hands of criminals. Neither letter said that Revolut's systems had been broken into, and both were telling the truth. That is the interesting part. In September 2026 one of Europe's largest fintechs has been the subject of two data breaches, and in each case the data left through a door that Revolut had, entirely deliberately, built into the side of the building. Earlier this month I wrote about the City Relay breach and the habit of treating a cloud supplier's security as somebody else's problem. The Revolut pair adds two lessons that piece did not cover, and both of them are about doors you may have forgotten you left open.

The first door: a supplier you no longer use

On 25 September The Register reported that DriveWealth, a United States brokerage that provides execution and clearing services to investment apps, had suffered unauthorised access to its systems on 4 and 5 September following what it called a sophisticated social engineering campaign. DriveWealth is the firm that, for years, held the actual brokerage accounts behind the US share dealing feature in the Revolut app. When a Revolut customer bought a share of a US company, DriveWealth was the broker of record. The data taken included names, email addresses, telephone numbers, postal addresses, employment details, country of citizenship, age, gender and partial DriveWealth account numbers. Passwords, card details, bank account details and identity documents were not among it. Customers of the Australian platform Stake and the New Zealand platform Hatch were also affected, and in their cases the exposed data reached into tax status, cash balances and portfolio values, according to Finance Magnates. DriveWealth told its partners the incident was contained and that it had found no unauthorised trades, transfers or withdrawals. Neither DriveWealth nor Revolut has said how many people were affected.

Here is the detail that makes this worth an article rather than a paragraph. Revolut had already moved on. Between December 2023 and June 2025, depending on the market, Revolut migrated its customers away from DriveWealth and stopped sending it new customer data. For customers in the European Economic Area, only records from before December 2023 were at risk. DriveWealth still held those records because, as a regulated US broker-dealer, it is required to keep customer account records for years after the relationship ends. So the data that leaked in September 2026 was, in many cases, data that Revolut had stopped sending in 2023, describing a relationship that had ended, held by a supplier that no longer appeared on anybody's list of current suppliers.

I would wager that DriveWealth was not in Revolut's live supplier register with a review date against it. I would wager the same about the former payroll provider, the previous CRM, the old ticketing system and the marketing agency from three years ago at almost every organisation reading this. Offboarding a supplier is treated as a commercial event: the contract ends, the invoices stop, the integration is switched off, and the relationship is closed in every sense except the one that matters here. The data is still there. Sometimes it is there because nobody asked for it to be deleted. Sometimes, as with DriveWealth, it is there because the law says it must be. Either way, a supplier you stopped using is still a supplier in every respect that a criminal cares about, and it is the one you are least likely to be watching.

The second door: a request you were required to trust

The earlier September incident is different in mechanism and worth setting beside the first. In the second week of the month Revolut told what it called a limited number of customers that an unauthorised third party had used a legitimate government agency email domain to submit fraudulent requests for customer information, and that Revolut had complied. TechCrunch and Infosecurity Magazine report that the data handed over included names, dates of birth, addresses, telephone numbers, email addresses, copies of passports and driving licences, verification selfies, account details and transaction histories. Revolut has not said which agency's domain was used, whether it was compromised or spoofed, how many customers were affected or in which countries. It described the incident as a sophisticated external impersonation scam, said that its systems and customer funds were unaffected, and reported it to the relevant regulators and law enforcement.

This is not a supply chain breach in the sense of a supplier being compromised, but it belongs in the same family, because it exploits the same thing: a channel of trust that the organisation built on purpose. Every bank, telecoms company and platform has a process for answering lawful requests from the authorities, and that process has to work quickly, because sometimes a life depends on it. Criminals have understood for some years that the fastest way to a full identity file is not to hack the bank but to ask it nicely on official-looking paper. What the Revolut incident shows is that a request arriving from a real government domain, with valid technical authentication on the email, is not proof of anything except that somebody has access to that domain. Verification of the request has to go beyond verification of the envelope.

Two breaches, one pattern

Put the three cases from this month's articles side by side and the pattern is clear.

In none of the three did the data owner's own perimeter fail. In all three the data owner had, months or years before, made a perfectly sensible business decision that created a route by which its customers' data could leave, and then stopped paying attention to that route. That is what supply chain risk actually is. It is not the dramatic compromise of a software vendor with ten thousand downstream victims, though those happen. Most of the time it is the accumulated set of ordinary arrangements, current and historical, through which your data is legitimately somewhere else, and the question of whether anyone is still looking at them.

What to do about former suppliers

The City Relay article set out how to build a supplier register and review it. The DriveWealth case adds a rule I should have stated then: a supplier leaves the register when your data leaves the supplier, not when the contract ends.

Start by adding a status to every entry: active, winding down, or dormant. A dormant supplier is one you no longer transact with but which still holds your data, whether because deletion was never confirmed or because retention is required. The register entry for a dormant supplier needs three things the active entry did not. It needs the date on which the supplier's retention obligation ends and the data should be deleted, so that the entry has an expiry rather than living forever. It needs confirmation, in writing, of what exactly was retained, because "historical records" is not a data category. And it needs the contact route through which the supplier will tell you about an incident, checked to confirm that it still reaches somebody at your end, since the account manager who set it up has probably left.

Then go back through the offboardings of the last six years and fill the register in. Finance can produce a list of every supplier whose payments stopped; the question for each is simply whether it ever held personal data or credentials, and if so whether its deletion was confirmed. Most organisations find a handful of surprises. The former suppliers that turn out still to hold data get a dormant entry, a written request for a deletion certificate where retention is not required, and a review on the same cadence as an active supplier of the same tier until the entry expires.

Fix the contracts going forward so that this is easier next time. The data processing terms should state what happens to the data at termination, in what form it is returned or destroyed, and by when, with a certificate of deletion as the closing document of the relationship. Where the supplier has a legal obligation to retain some of it, the contract should name the categories, the period and the legal basis, and the security and breach notification clauses should expressly survive termination for as long as the retention does. That last clause is the one almost nobody has, and it is the one that decides whether a former supplier is obliged to tell you when its retained copy of your customer list is stolen.

Finally, and this is the part that would have made the most difference to Revolut's customers, minimise what you send in the first place. A broker of record has to know who its account holder is and needs enough to satisfy its own regulator. It does not follow that every field your onboarding form collects needs to be forwarded. Employment details, citizenship, gender and age were all in the DriveWealth data; whether each was required by the broker or merely convenient to send is a question that can only be answered field by field, at integration time, and it is rarely asked. Every field you do not send is a field that cannot be retained for six years and cannot be stolen from a supplier you have forgotten about.

What to do about requests from authority

For the second door, the fix is procedural rather than contractual, and it applies to any organisation that receives requests for personal data from bodies it is inclined to trust: the police, a regulator, a government department, a court, a large customer's legal team.

Write down which requests you will answer and on what legal basis, and refuse anything that does not fit. Verify every request out of band, using contact details you already hold or can obtain independently, never the details in the request itself; a telephone call to the agency's published switchboard takes five minutes and defeats the entire category of attack. Treat a request for identity documents, selfies or full transaction histories as the highest-risk disclosure you make, requiring approval from two named people, one of whom is outside the team that handles routine requests. Keep a log of every disclosure, and have somebody look at the log weekly for volume, for repeat requesters, and for requests that arrived outside working hours or asked for unusually complete files. Emergency requests deserve a faster path, not a weaker one: a genuine emergency can be verified by a phone call as quickly as it can be answered by email.

None of this requires technology you do not already have. It requires the organisation to decide, in advance, that a convincing envelope is not a sufficient reason to hand over a customer's passport.

The customer's view

There is one more lesson, and it is about the letter. Revolut's message to customers about DriveWealth said, accurately, that Revolut's own systems had not been compromised and that funds and investments were safe. I understand why a communications team writes that sentence. It is also the sentence the customer cares about least. The customer did not choose DriveWealth, has probably never heard of it, and cannot do anything about its security. The customer chose Revolut, and it is Revolut's name on the email telling them their address and employer are now in a criminal's hands. When a supplier or former supplier is breached, "it was not us" is true and unhelpful in equal measure. The letter that lands well says what was taken, what you have already done about it, what the customer should watch for, and what you are changing so that it does not recur. The data taken from DriveWealth is precisely what a phishing crew needs to write a convincing message, so the most useful thing Revolut could tell its customers is what a genuine Revolut message will and will not ask them to do, and the same applies to anyone whose supplier has just lost their customer list. We wrote recently about how a modern phishing page uses exactly this kind of data to look legitimate.

The good morning, again

The point of all this is not that suppliers are dangerous or that fintechs are careless. Revolut runs a serious security operation, and DriveWealth's obligation to retain records is there to protect investors. The point is that the map of where your data is has a history as well as a present, and that the organisations which get through a supplier breach without lasting damage are the ones who could draw that map before the breach happened. The morning DriveWealth's notice arrived, the firms in the best position were the ones who could open a register, find a dormant entry, read exactly what had been retained and why, and write to their customers the same day with specifics. That is a morning available to any organisation willing to spend an afternoon on its old suppliers and an hour on its disclosure process. It is a considerably better morning than the alternative, and unlike most things in this field it costs almost nothing.

Frequently asked questions

A supplier we stopped using has been breached. Are we responsible? If the supplier was processing personal data on your behalf, you remain the controller of that data for as long as the supplier holds it, whether or not the contract is still active. You will normally need to assess the risk to the individuals, notify the ICO within seventy-two hours of becoming aware if the breach is likely to result in a risk to them, and tell the individuals without undue delay if that risk is high. Having a record of what the supplier retained, why, and what you did to secure it is what demonstrates that you handled the relationship properly.

Can we make a supplier delete our data when the contract ends? Usually, and the data processing terms should require it, with a certificate of deletion as the closing step. The exception is where the supplier has its own legal obligation to retain records, as regulated brokers, payment firms and some professional services providers do. In that case you cannot compel deletion, but you can require the supplier to state what it retains and for how long, to keep it secured, and to notify you of any breach for the whole retention period.

How should we verify a data request that appears to come from the police or a government department? Independently of the request itself. Use contact details you already hold or can find from the agency's published sources, not those in the email or letter, and confirm the request with a named person. Check that the request cites a legal basis you recognise, that it is proportionate, and that the person making it is entitled to make it. Require two approvers for any disclosure of identity documents or full financial histories, and log every disclosure so that patterns can be seen.

What should our customer notification say when the breach was at a supplier? What was taken, in plain categories; what you have already done; what the customer should watch for, with specific examples of the phishing the stolen data makes possible; how a genuine message from you can be recognised; and what you are changing. Saying that your own systems were not affected is fine as a fact, but it should not be the lead, because the customer's relationship is with you and not with your supplier.

How far back should we go when reviewing former suppliers? Six years covers the retention periods most UK and US regulatory regimes impose and the limitation period for most contractual claims, so it is a sensible boundary. Within that window, list every supplier that held personal data or credentials, confirm whether deletion was completed and evidenced, and give the rest a dormant entry in your supplier register with an expiry date.