The Revolut Breach and the Need for Joined-Up Governance

By Phil Muncaster • 20 October 2026 • 6 min read

When is a breach not a breach? When it’s a highly targeted raid aimed at extracting information on specific customers over a period of several months. Revolut is facing mounting negative publicity as the drip-drip of facts continues to emerge from a recently confirmed incident. For a company aiming for a $200bn stock market IPO, it couldn’t have come at a worse time.

Hundreds of high-net worth customers were reportedly targeted. But perhaps more interesting is the questions it raises over the role cybersecurity and privacy should play when designing information disclosure processes. When governance gaps emerge, serious mistakes can happen.

Months in the Making

The full details of what happened are still emerging. However, what we know at the time of writing is that the group responsible, “iamnotavillain”, first researched high net-worth individuals with significant crypto holdings, through blockchain analysis. Then they managed to compromise a secure government communications system. Italy’s PEC (Posta Elettronica Certificata) platform is used by public authorities and private businesses to send legally binding and trackable electronic communications.

Reports suggest that the attackers compromised Italian Ministry of the Interior email accounts running on PEC using infostealer logs. Posing as law enforcement, the group allegedly requested Know Your Customer (KYC) information on the individuals from the bank over a period of months. A trove of info was apparently shared, including names, addresses, dates of birth, identity documents (e.g. passports and driving-licence information), verification selfies, IBAN/account information and transaction histories.

“Upon detection, we immediately blocked the address and alerted the relevant government agency as well as enforcement agencies, data protection, and financial regulators,” said Revolut in a statement. “Revolut systems and customer funds are unaffected. We have contacted the limited number of impacted individuals directly to inform them and provide support.”

Around 680 individuals are thought to have been impacted. They should be on high alert. They may be the target of so-called “wrench attacks” where individuals’ homes are raided for hardware crypto wallets. Around $30m was lost in the first half of 2026 to such attacks, with France the worst affected country. Why? Experts believe it was down to a 2024 data breach in which a local tax official stole and sold information on high-net-worth crypto holders, including their names and addresses.

Another route for the group could be to use their knowledge of the victims’ crypto flows and their personal details to socially engineer their way into accounts. They have reportedly demanded a $3m ransom from Revolut, although it’s highly unlikely the bank would pay given the value of the information it has already handed over.

When Compliance Gets in the Way of Security

Aside from how the threat actors managed to maintain persistent access to the PEC infrastructure for so long, the case highlights several potential shortcomings that led to the breach:

Bank staff were socially engineered multiple times over a period of months, suggesting security wasn’t properly baked into information-disclosure workflows
Verification and authorisation thresholds may not have been high enough, even though the bank was responding to a legitimate-looking message via a “secure” comms platform
Data minimisation best practice seems to have dissolved on contact with legal compliance/disclosure processes, given how much unredacted info was shared

BioCatch director of global advisory EMEA, Jonathan Frost, tells IO (formerly ISMS.online) that Revolut isn’t alone in being targeted by legitimate-looking compliance requests. “Revolut joins Apple, Meta, and Discord in failing to recognise the forged requests,” he says. “Revolut’s failure comes years after previous incidents exposed this threat, which makes us question why it hadn’t reinforced its controls in anticipation of it.”

Jason Brown, director of customer advisory, counter fraud lead at iCounter says the problem is that compliance workflows often aren’t designed to check if the person making the request is entitled to do so. Social engineering risk therefore has to be addressed at the workflow level.

“Sensitive disclosure processes should independently verify requester identity and authority, use a separate channel for confirmation, and escalate requests when expected documentation or contextual indicators are missing,” he tells IO

“The goal is not to make compliance slower. It is to prevent compliance itself from becoming the attack surface.”

Secure.com head of engineering, Waseem Ahmed, tells IO that data minimisation could have significantly reduced the impact of the attack. “When a regulator mandates that you collect biometric verification material, it should follow that the same material carries the tightest possible release threshold,” he adds. “Frequently it does not, because different people wrote the collection rule and the disclosure rule.”

Black Hills Information Security owner, John Strand, tells IO that security and compliance processes need “structured pushback” built into them so that requests can be questioned.

“There should be a defined way for somebody to stop, question a request, and perform additional verification against the context of what is actually being requested,” he argues.

Towards Joined-Up Governance

Experts IO spoke to agree that at the heart of the incident lies major governance gaps, which shouldn’t exist if security, privacy and compliance are designed in concert.

“Security owned a channel that authenticated correctly. Compliance owned an obligation to respond. Privacy owned a lawful basis. Each function did its job, but the gap sat between them, because nobody was looking at the requests as a whole,” argues iCounter’s Brown. “Verification is the floor. Seeing the campaign is the ceiling. That takes risk, compliance, legal and security on the same page, agreed before the next request lands. In the moment, any pause will feel like friction on a lawful ask.”

Secure.com’s Ahmed says the problem is primarily structural.

“Four things fix it. Threat model the workflow rather than the systems, and do it with compliance, privacy, legal, and security in the same room. Name a single accountable owner for the disclosure decision, someone answerable for the composite outcome and not just their own step,” he concludes.

“Red team the process, not just the infrastructure, by sending a realistic fraudulent request through the real channel and seeing how far it gets. And separate authentication from authorisation explicitly in the design.”

When all of these key functions are in the “same room”, there are fewer gaps of the sort that Revolut’s extortionists exploited so ruthlessly. But it’s not a one and done effort. Without a continuous approach, new gaps could emerge over time. Relentless vigilance is the best way for organisations to avoid becoming another cautionary tale.