Fake Government Data Requests: Lessons from Revolut and McKesson

Two widely reported security incidents this month did not begin with malware or a software flaw. In both, the attackers got what they wanted by sending a request that looked genuine and waiting for someone to act on it. For any organisation that holds customer or employee data, the lessons are practical and worth reviewing now.

What happened at Revolut

On 12 September 2026, Revolut confirmed that customer information had been handed to an unauthorised party. According to the company, someone used an email address on a genuine government agency domain to send fraudulent requests for customer records. Because the emails came from a real government domain, they passed the usual technical checks, and staff processed them as routine legal requests, as reported by Infosecurity Magazine.

Revolut's notice to affected customers, as reported by TechCrunch, listed names, dates of birth, addresses, phone numbers and copies of passports and driving licences. It said verification selfies, account statements and transaction histories may also have been shared. Revolut has described the number of affected customers as limited, has not published a figure, and says its systems and customer funds were not affected.

The method itself is not new. In November 2024, the FBI warned that compromised government email accounts were being sold and used to send fraudulent emergency data requests to companies.

What happened at McKesson

McKesson, a large US healthcare distributor, said it discovered a security incident on 25 August 2026 involving unauthorised access to third-party applications and the theft of data. In its filing with the US Securities and Exchange Commission, the company said it had not determined the incident to be material.

A criminal group called ShinyHunters has claimed responsibility. According to BleepingComputer, the group says it phoned McKesson employees, persuaded them to give up their login details, and then used those accounts to reach business applications holding customer data. McKesson has not confirmed how the attackers got in, so these details should be treated as the group's claims.

The common thread: trust, not technology

In both cases, the technical controls largely worked as designed. The Revolut emails came from a real government domain, so they looked legitimate. In the McKesson case, the attackers reportedly used real employee logins. The weak point in each was the moment a person decided whether a request could be trusted.

This fits a wider pattern. A review of August 2026 incidents published by PKWARE found that almost every major case that month began with a person rather than a technical flaw, whether a help desk agent persuaded to hand over access, an employee tricked into giving up a login, or a supplier's account being misused.

Why this matters for your organisation

Most organisations receive requests for information from outside parties, such as police, tax authorities, regulators, auditors, lawyers or business partners. These often come with short deadlines, and staff are expected to respond promptly. That mix of authority and urgency is exactly what an impersonation attempt relies on.

The same risk applies to internal help desks that reset passwords, and to online business applications, such as customer relationship, HR and reporting tools, that hold personal data outside your main systems. These areas are often reviewed less closely.

Once data has been released, the organisation is dealing with a data breach, even if no system was hacked. Data protection and cyber security laws in many countries require incidents to be reported to regulators, and sometimes to the people affected, within short deadlines. A breach caused by a faulty process is still a breach.

Six practical steps we recommend

Based on what these incidents show, we would advise leadership teams to look at the following areas. None of them depends on buying new technology; most are about ownership, process and testing.

1. Put clear ownership around data release decisions. Someone at leadership level should own the policy for how outside requests for personal data are received, verified and approved. That policy should state who can authorise a release, what checks are required before it happens, and how exceptions are recorded. Where there is no dedicated security leader, this is a gap worth closing, whether through an internal appointment or an external advisory arrangement.

2. Assess the risk in how requests are handled today. Most risk assessments focus on systems and infrastructure. We recommend extending them to cover the teams and processes that handle sensitive requests, such as legal, compliance, customer support and the IT help desk. The aim is to identify where a single person can release sensitive data, or reset access, without independent verification.

3. Review access to online business applications. Customer relationship, HR and reporting tools often hold large volumes of personal data but receive less attention than core systems. A structured review should confirm who has access and why, require stronger sign-in methods such as security keys or passkeys for staff with wide access, and make sure that large downloads and unusual activity are logged and alerted on.

4. Test people and processes, not only systems. Standard security testing checks for technical weaknesses. It rarely checks whether the help desk will reset a password for a convincing caller, or whether a well-crafted request for customer records will be fulfilled without verification. Controlled social engineering exercises, agreed in advance with leadership, show how processes perform under realistic pressure and give a clear basis for improvement.

5. Prepare an incident response plan for process failures. Many response plans are written around malware and system compromise. They should also cover the case where data has been handed over through a legitimate channel: who decides that an incident has occurred, how the recipient is identified, how affected people are informed, and how regulatory reporting deadlines are met. Rehearsing this scenario once a year is a reasonable starting point.

6. Review these controls regularly at leadership level. Verification steps tend to weaken over time as staff change and deadlines press. We recommend reporting on a small number of indicators, such as verification exceptions, help desk reset volumes and results from testing, to senior management on a regular cycle, so that gaps are noticed before an attacker finds them.

Conclusion

The Revolut and McKesson incidents show that protecting customer data depends as much on how people handle requests as on the systems that store it. Clear verification steps, limits on who can release sensitive records, and regular testing of those processes can stop an attacker who simply asks.