What UK Businesses Can Learn From the Revolut Data Breach
Revolut Data Breach: What UK Businesses Can Learn From a Trusted Email
The email domain was legitimate, yet the request wasn’t. Here’s what the incident shows about verification, sensitive data and incident response.
The Revolut breach shows why a legitimate sender address isn’t enough to approve a sensitive request. Businesses need independent verification, proportionate approval, limited disclosure and useful audit logs before data, money or privileged access moves.
When most people hear the words ‘data breach’, they probably picture someone forcing their way into a network via some type of exploit, be it a stolen password or malware slipping past the defences.
What makes the recent Revolut incident particularly relevant (beyond the profile of the company hit, and how familiar it is to millions of us) is that it appears to have worked differently here. According to the company, an unauthorised third party sent fraudulent information requests from a legitimate government agency email domain, resulting in the disclosure of sensitive customer data.
Revolut says its systems and customer funds were unaffected, which means this isn’t your conventional intrusion into a core infrastructure, but rather an impersonation scam that used a trusted channel to make a false request look official.
For UK SMEs and mid-market organisations, the incident serves as a useful reminder that security cannot stop at checking the sender's address, because sometimes the address is legitimate, and other times the account behind it has been compromised. Your process still needs to ask whether the request itself makes sense.
What Happened in the Revolut Data Breach
Revolut confirmed on the 12th of September that it had disclosed customer information after receiving fraudulent requests from a legitimate government agency email domain. The company described the event as a sophisticated external impersonation scam.
The notification, reviewed by TechCrunch, said exposed information could include names, dates of birth, postal and email addresses, phone numbers and identity documents such as passports or driving licences. Verification selfies, account statements and transaction histories may also have been included.
Revolut has publicly referred to a limited number of affected customers. Reuters later reported, citing a source familiar with the matter, that about 680 customers were involved. Revolut said it blocked the email address, notified the relevant government agency, law enforcement and regulators, and contacted those affected.
Initial online claims referred to the hackers demanding a ransom payment in Bitcoin, before later reporting described a public ultimatum from a group claiming responsibility, seeking the equivalent of $3 million in Monero and threatening to sell the data - although Revolut told Reuters that it had received no direct contact or demand from the group.
So, in short, there was a confirmed data breach from an online bank used by an estimated 80 million people worldwide, alongside a reported extortion attempt. But simply framing it as a Revolut hack misses the part businesses can learn the most from.
Why This Wasn’t a Traditional Hack
The attackers didn’t come in all guns blazing through Revolut’s front door (nor did they need to); they angled toward persuading someone to open it for them, and that’s what you should be on alert for.
Their request arriving from a genuine government domain carries authority. It looks more convincing than a misspelt imitation from the likes of a ‘rnicrosoft.com’ or ‘app1e.com’, passes the most obvious visual checks and may create pressure to respond quickly. If the recipient is used to handling official requests, the message (in cases like this) can pass checks with ease and slip into an established workflow.
That, really, is the uncomfortable truth. Many businesses have trained staff to look for odd domains, poor spelling and suspicious links - which still helps, but it’s no longer enough on its own. A compromised supplier account, customer mailbox or official email system can make a malicious message look completely ordinary.
The control, therefore, has to sit in both the business process and the inbox. A legitimate address can support trust, but it shouldn’t be the only evidence used to approve a sensitive disclosure.
What UK Businesses Should Learn
Verify Sensitive Requests Outside Email
Any unusual request for personal data, payment, credentials or privileged access should be checked through a second route.
Build Approval Into the Process
Define which requests need a second reviewer, who can approve them and what evidence must be recorded.
Share Only What’s Necessary
Confirm the legal basis, scope and whether every requested field is genuinely required before releasing sensitive data.
Watch for Unusual Access and Disclosure
Monitor exports, bulk downloads, mailbox activity and access to sensitive records as well as failed logins and malware alerts.
Prepare for the First 72 Hours
Know who investigates, who assesses regulatory obligations, who communicates and how decisions are recorded.
Verify Sensitive Requests Outside Email
Any unusual request for personal data, payment, credentials or privileged access should be checked through a second route. Call a known number, use an established portal or contact a recognised person through details already held by your organisation. Don’t rely on the phone number or link supplied in the message you are checking.
The National Cyber Security Centre recommends verifying important email requests through a second type of communication. That simple pause is especially valuable when the request invokes authority or urgency.
Build Approval Into the Process
Sensitive disclosures shouldn’t depend on one person making a difficult judgment under time pressure. Define which requests need a second reviewer, who can approve them and what evidence must be recorded.
This doesn’t mean turning every routine task into a committee meeting, but you should set a clear threshold - whether that’s a request for a large dataset, identity documents, financial history, or administrator access, something along those lines should trigger a stronger check than an everyday enquiry.
Share Only What’s Necessary
Data minimisation is often discussed as being something of a compliance principle, and perhaps it is. But at the same time, it’s also a practical security control. Before disclosing information, confirm the legal basis, the scope of the request and whether every requested field is necessary.
If a request asks for several categories of high-risk information at once, that should increase scrutiny, whereas a smaller, justified disclosure creates less exposure if the request later proves fraudulent.
Watch for Unusual Access and Disclosure
Monitoring should be comprehensive and cover more than failed logins and malware alerts. Businesses also need visibility into unusual exports, bulk downloads, mailbox activity and access to sensitive records.
Good logging helps an organisation answer the questions that arrive immediately (or even in the hours) after an incident: what was accessed, by whom, when, from where and what left the business. Without that evidence, containment and notification become much harder.
Prepare for the First 72 Hours
If personal data is disclosed to the wrong party, the response clock starts pretty quickly. The Information Commissioner’s Office says organisations must report certain personal data breaches within 72 hours of becoming aware of them, where feasible. If the breach is likely to create a high risk to individuals, those people must also be informed without undue delay.
Your plan should then also identify who investigates, who makes the regulatory assessment, who communicates with affected people and how decisions are recorded. Being slap bang in the middle of an incident, only to discover that nobody owns the contact list, is far from ideal and reflects poorly on all involved.
When Stolen Data Becomes an Extortion Tool
The Revolut story also illustrates why the term "ransomware" can be misleading, or not quite tell the whole story. There remains to be no public indication that Revolut’s files were encrypted, with the only reported leverage coming from the threat to sell or release stolen information.
This form of data extortion can be damaging even when systems remain available. Identity documents, contact details, and financial histories can support convincing phishing attempts, identity fraud, and further targeting - remember, operational uptime doesn’t mean the impact is small.
For any organisation facing a ransom demand, payment should never be treated as a quick technical fix. The NCSC warns that payment doesn't guarantee data will be deleted or returned, and payments can raise legal and sanctions issues. The decision needs input from incident response specialists, legal advisers, insurers where relevant, senior leadership and law enforcement.
What Affected Customers Should Do
Revolut says it contacted the people affected by this incident directly. Anyone who received a notification should follow the company’s official guidance and be particularly cautious about messages that refer to their account, transactions or identity documents.
It’s also worth noting that a criminal who already knows accurate details doesn’t need to send a clumsy scam - they can draw from and use real information to sound credible.
Obviously, if you are affected, contact Revolut through the app or its official website, review account activity, secure reused credentials, and avoid links or numbers in unsolicited messages.
The Practical Question for Your Business
Most SMEs don’t process government information requests at Revolut’s scale. They do, however, receive urgent emails from banks, suppliers, directors, customers, insurers and public bodies, so that same principle applies to all of them.
If you do nothing else today, ask one practical question: if a trusted external mailbox were compromised tomorrow, would our process catch a convincing but unusual request?
If the answer depends on one employee noticing that something feels wrong, there’s work to do. Independent verification, proportionate approval, limited disclosure, and useful audit logs give people a process they can rely on even when the message itself appears entirely genuine.
That, in itself, is actually the wider lesson from the Revolut data breach. Trust still matters, and always will, but it needs checking at the point where data, money or access is about to move.
Fifosys helps UK organisations review the technology and business processes that sit behind cyber risk. If you are unsure how a sensitive request would be verified, approved or investigated in your organisation, start a conversation with our team.
Revolut data breach FAQs
What happened in the Revolut data breach?
Revolut said customer information was disclosed after fraudulent information requests were sent from a legitimate government agency email domain. Revolut described the incident as a sophisticated external impersonation scam rather than an intrusion into its core systems.
Was Revolut hacked?
Revolut said its systems and customer funds were unaffected. The incident involved fraudulent requests arriving through a legitimate external email domain, which led to customer information being disclosed.
What data was exposed in the Revolut breach?
Reportedly exposed information could include names, dates of birth, contact details, identity documents, verification selfies, account statements and transaction histories, depending on the affected customer.
How can businesses verify sensitive email requests?
Unusual requests involving sensitive data, payments, credentials or privileged access should be verified through an independent route such as a known telephone number, trusted portal or recognised contact using details already held by the organisation.
When does a UK business need to report a personal data breach?
Certain personal data breaches must be reported to the Information Commissioner’s Office within 72 hours of the organisation becoming aware of them, where feasible. Where a breach is likely to create a high risk to individuals, affected people may also need to be informed without undue delay.
Why isn’t checking the sender’s email address enough?
A malicious request can come from a legitimate but compromised account or trusted external domain. Businesses therefore need to verify the request itself, particularly before releasing sensitive information, transferring money or granting privileged access.
Make sensitive requests harder to fake
We can help you review the technical controls, approval processes and incident response procedures behind the way your business handles sensitive information.
Talk to our team
Bring us the process, incident or security concern you’re working through and we’ll help you understand where the risk sits.
Incident response
Plan how your organisation investigates, contains, escalates and communicates when a cyber incident occurs.