Rohan Whitehead - Data Training Specialist 
When we hear the phrase data breach, many of us probably imagine someone breaking through a firewall, stealing credentials or exploiting a technical vulnerability. The recent breach involving Revolut (read more here) is a useful reminder that sensitive information can leave an organisation in a much simpler way: somebody can ask for it through a channel that appears trustworthy.
Revolut confirmed this month that sensitive customer information was disclosed after fraudulent information requests were submitted using an email address on a legitimate government agency domain. According to the company, the communication carried valid technical domain authentication and was initially treated as a genuine government request. Revolut has said its own systems and customer funds were not compromised, while subsequent reporting indicated that hundreds of customers may have had information exposed.
That distinction matters. Based on what has been publicly reported, this was not primarily a case of an attacker defeating Revolut's core technical security. It was a case of a process being presented with something that looked legitimate and ultimately releasing information to someone who was not entitled to receive it. For data professionals, this is a useful reminder that security does not stop once information is stored safely. It continues through every decision about who should receive data, why they should receive it and how we know the request is genuine.
Trust can become part of the attack surface
Most organisations need trusted channels. Banks receive requests from regulators and law-enforcement bodies, universities communicate with government departments, healthcare organisations exchange information with approved partners, and businesses routinely respond to customers and suppliers. We cannot treat every communication as inherently suspicious without making normal work impossible.
The difficulty is that attackers understand this. If an organisation trusts a particular signal, that signal becomes valuable. It might be an email address, a familiar supplier, a senior colleague's name or an apparently official document. In the Revolut case, the important signal appears to have been that communication originated from a legitimate government agency domain. That is meaningful evidence about where a message came from, but it is not necessarily evidence that the person controlling the account has the authority they claim to have.
I think this distinction is useful well beyond cybersecurity: authentic is not always the same as authorised. A message can genuinely originate from a trusted system while the request inside it is still fraudulent. Good governance requires us to keep asking the second question rather than allowing one trusted signal to answer everything.
Verification should be a process, not an instinct
It would be easy to respond to an incident like this by saying employees simply need to be more suspicious. I do not think that is particularly useful. If staff regularly process genuine government or regulatory requests, then an apparently authentic request arriving through an established channel may look completely routine. Asking individuals to recognise every sophisticated impersonation attempt places too much responsibility on personal judgement.
The stronger response is to design a process that does not require someone to make that judgement alone. For sensitive disclosures, this might mean verifying a request through an independently obtained contact route, requiring a second employee to approve release, or escalating unusually large or unusual requests. None of these controls is especially glamorous, but that is often what good data governance looks like in practice.
The important word here is proportionate. Requiring multiple approvals for every routine request would create unnecessary bureaucracy, but releasing highly sensitive information because an email address looks familiar sits at the opposite extreme. Good process design is about deciding where additional friction is worth introducing.
Good governance sometimes means slowing things down
We often design digital processes around speed. Dashboards should load faster, automated workflows should reduce manual handling and requests should move through an organisation with as little friction as possible. Most of the time, that makes sense. But efficiency and security are not always perfectly aligned.
There are some decisions where a small amount of friction is valuable. Releasing sensitive personal information is one of them. If the consequences of making the wrong decision are significant, an additional check is not necessarily an inefficient process. It may simply be a better-designed one.
This becomes more important as organisations automate more of their information handling. An automated system can check whether an incoming email comes from an approved domain or whether a request matches a predefined template. Those controls can reduce workload, but they can also create false confidence if passing an automated check becomes synonymous with being trustworthy. Automation is very good at enforcing the rules we give it; the harder question is whether those rules are sufficient for the risk involved.
Verification is only the first question
Even once a request has been confirmed as legitimate, another question remains: how much information actually needs to be disclosed? This is where data minimisation becomes important.
A legitimate request for one piece of information does not automatically justify providing every piece of information available about an individual. In practice, organisations should be able to distinguish between the authority to make a request and the scope of information that authority permits them to receive. That might mean limiting an export to particular dates or fields, separating identity information from financial information, or requiring additional approval when especially sensitive data is involved.
This is where analytics and data teams have a direct role. We often build the datasets, reporting environments and access structures through which information becomes available. Thinking about who can access something is not enough. We should also ask which fields they actually need, for what purpose and for how long.
Human judgement works best when the organisation supports it
There is sometimes a tendency after incidents involving deception or social engineering to focus on the individual who made the final decision. Someone approved something, clicked something or sent information they should not have. That can obscure a more useful question: what did the process expect that person to do?
If an employee receives an apparently legitimate request, has access to the information being requested and is expected to respond quickly, simply telling them afterwards that they should have been more cautious does not necessarily improve the system. We should instead ask whether there was a clear verification route, whether unusual requests were easy to escalate, whether sensitive disclosures required additional approval and whether employees had enough information to recognise when the normal process should stop.
Technical controls remain essential, but they sit within a wider system of people, processes and decisions. A technically secure platform can still support an insecure business process, just as a well-written policy can fail if too many people have unrestricted access.
Near misses are useful data too
There is another lesson here that I think organisations can make more use of. We naturally investigate incidents after information has been disclosed, but requests that almost succeeded can be just as valuable. If an employee spots a suspicious request before anything is released, the organisation has effectively received a free test of its controls.
Near misses can reveal which channels attackers are targeting, which requests staff find difficult to verify and where escalation processes are unclear. From an analytics perspective, these events should not simply disappear once they are resolved. Recording them allows organisations to identify patterns, improve training and redesign weak processes before a successful breach occurs.
An organisation might find, for example, that most suspicious requests target a particular team, or that verification failures are more likely when staff are under time pressure. Those patterns turn isolated incidents into something that can be measured and acted upon.
Cybersecurity is also a process problem
I do not think the lesson from the Revolut incident is that organisations should stop trusting emails from government bodies or introduce cumbersome checks around every request. The more useful conclusion is that trust should rarely depend on a single signal when sensitive information is involved.
We still need strong authentication, encryption, monitoring and all the technical controls normally associated with cybersecurity. But the final path between stored information and the person requesting it often passes through a workflow, an approval process and a human decision. Those elements deserve the same attention as the technology around them.
For data professionals, that means thinking beyond whether information is technically protected. We should ask how it can leave the organisation, what processes authorise that movement, what evidence those processes rely on and what happens when an apparently trustworthy signal has itself been compromised.
The interesting thing about this incident is precisely that the request appears to have looked credible. Good governance is relatively easy when something obviously looks wrong. The real test is whether the process still works when everything appears to look right.