Your Former Vendor Still Has Your Customers' Data

The Register reported on September 25, 2026 that DriveWealth, a US brokerage that had provided US stock trading for Revolut, disclosed unauthorised access on September 4 and 5 following what it described as a sophisticated social engineering campaign by unknown attackers.

According to that report, the exposed information included names, email addresses, phone numbers, postal addresses, employment information, country of citizenship, age, gender, and partial DriveWealth account numbers. The company said passwords and payment information, including card and bank account details, were not compromised.

Revolut said its own systems and infrastructure were not compromised and that no Revolut passwords, passcodes, card details, or identity documents were exposed. The data came from customers' previous arrangement with DriveWealth; Revolut had moved UK, EEA, and Australian customers away from that arrangement between December 2023 and June 2025. Neither company disclosed how many people were affected. RTÉ also reported on the incident.

It was the second incident affecting Revolut customer data reported that month, following an earlier case involving fraudulent government data requests.

When a company migrates away from a vendor, the work usually focuses on the new system: moving accounts, switching integrations, and cutting over traffic. The old vendor's copy of the data often receives less attention. Contracts may require deletion at termination, but regulated firms such as brokers frequently must retain records for years, and nobody on the customer's side verifies what remains.

The result is a growing population of former vendors each holding historical customer data, secured to their standards rather than yours, and no longer on anyone's list of systems to worry about. When one of them is breached, the customer notices your name, not theirs.

DriveWealth described the entry point as social engineering. That is consistent with a broad trend of attackers targeting people with access, including help desks, support staff, and administrators, rather than software flaws. You cannot control a vendor's help desk procedures directly, but you can ask about them: how identity is verified before credential resets or access grants, and whether that verification can be defeated by a convincing caller.

• A data map per vendor. What personal data each vendor holds, in which categories, and under what retention obligation.
• Deletion or return, with evidence. At termination, require deletion of data not subject to legal retention, and written confirmation of what remains and why.
• Minimised retained sets. Where retention is mandatory, ask whether the vendor can restrict it to what the regulation requires and restrict access to it.
• Keep former vendors on the risk register until their retained data is gone, including breach notification obligations to you.
• Prepare the customer message. Decide in advance how you will communicate when a current or former vendor is breached, since the questions will come to you.

From the customer's perspective, the vendor distinction barely matters. Revolut customers saw two data incidents reported in one month, one involving the company's own handling of fraudulent requests and one at a former vendor, and both carried the Revolut name in headlines.

That is the practical reason third-party data belongs in your own risk model. Contracts can allocate liability, but they cannot allocate reputation. When deciding what data to share with a vendor in the first place, the question is not only whether they will protect it, but whether you would be comfortable explaining its exposure to your customers in their words, years after the relationship ends.

A breach at a former vendor starts with questions you can only answer from records: which customers' data did they hold, for what period, and what categories? If that mapping does not exist, scoping depends entirely on the vendor's analysis. Keeping a list of exported datasets and the customers they covered, at the time of migration, turns a week of reconstruction into an afternoon.