In September 2026, Revolut said it had identified "a sophisticated external impersonation scam where an unauthorised third party utilised a legitimate government agency domain email to submit fraudulent requests for information." It said it had contacted "the limited number of impacted individuals" and that "Revolut systems and customer funds are unaffected." According to the notifications sent to affected customers, as reported in the press, the information that may have been shared included identity and contact details, copies of identity documents, verification selfies, account statements and transaction histories. Revolut has not named the government agency concerned.
The incident is notable precisely because, on Revolut's own account, its systems were not the point of failure. The data appears to have left through a disclosure process that exists to answer legitimate authorities.
That distinction matters. Organisations build formidable controls around authentication, privileged access, malware, encryption and network intrusion, while treating requests from police, regulators, courts and other public authorities principally as legal-administration workflows. But a lawful disclosure channel is still a data-exfiltration channel if the requester is not who they claim to be.
The control question therefore cannot stop at "does the request look official?" It has to become: have we independently established who is requesting the data, what legal authority supports the request, whether that authority applies to us, whether the requested data is necessary and proportionate, and whether the disclosure channel itself is secure? That is a security question and a data-protection question at the same time.
A legitimate government domain is not a legitimate legal demand
Organisations commonly check whether a request originates from an official government domain, passes ordinary email-authentication controls, carries agency branding, names a real official, cites a plausible investigation or reference number, and uses the language normally associated with official demands.
Those are useful indicators. They are not proof of authority. A genuine government domain can be compromised. An authorised mailbox can be abused. A legitimate employee account can be taken over. A convincing document can contain a false or altered legal demand.
Verification therefore has to happen out of band. The contact details contained in a request should never be the only means of verifying it. For higher-risk disclosures, obtain the authority's contact details independently, from an established directory, an existing verified relationship or an official portal, and confirm the request through that channel. Where the requesting authority provides a dedicated law-enforcement portal, that should ordinarily be preferred over unrestricted email.
The legal obligation is not simply "cooperate with law enforcement"
Under the GDPR, disclosure of personal data "by transmission, dissemination or otherwise making available" is processing (Article 4(2)). An organisation responding to a government or law-enforcement request therefore needs a lawful basis under Article 6 and must comply with the Article 5 principles, including lawfulness, purpose limitation, data minimisation, integrity and confidentiality, and accountability.
A binding statutory demand, warrant or production order may support disclosure under Article 6(1)(c), where it is necessary for compliance with a legal obligation to which the controller is subject. Article 6(3) adds a condition that matters for international requests: that obligation must be laid down by Union law or the law of a Member State to which the controller is subject.
Not every request from a public authority is legally compulsory, and the United Kingdom illustrates why the distinction has operational weight. The ICO's guidance on sharing personal data with law enforcement authorities treats every disclosure as needing an Article 6 basis. Where a court order or another legal obligation compels disclosure, that basis is likely to be legal obligation. Where disclosure is voluntary, it must be necessary and proportionate, and only the minimum necessary information should be shared. The ICO has flagged that this guidance is under review following the Data (Use and Access) Act 2025.
That Act matters here. Since 5 February 2026 the UK GDPR has carried a "recognised legitimate interests" basis (Article 6(1)(ea) and Annex 1). Its conditions include processing necessary for detecting, investigating or preventing crime, or apprehending or prosecuting offenders, and disclosure in response to a request that states the requester needs the data for a public task with a proper legal basis. It is not available to public authorities performing their tasks, individuals keep the right to object, and the processing must still be necessary.
Look closely at what that last condition turns on: what the request states. A fraudulent request can state exactly the right things. A lawful basis that can be satisfied by the content of a request raises, rather than lowers, the importance of establishing who actually sent it.
The crime and taxation exemption in paragraph 2 of Schedule 2 to the Data Protection Act 2018 does not create a power to hand information to the police either. It disapplies listed UK GDPR provisions, chiefly transparency and individual rights, together with the duty to tell data subjects about a breach, to the extent that applying them would be likely to prejudice the prevention, investigation or detection of crime, the apprehension or prosecution of offenders, or the assessment or collection of tax. The ICO describes it as not a blanket exemption, to be considered case by case, and a lawful basis is still required.
An exemption from an obligation is not an authority to disclose.
Verify four different things, not one
A mature requisition process independently establishes four things before information is released.
- Requester identity. Is the individual actually an authorised representative of the authority they claim to represent?
- Institutional authenticity. Did the named authority actually issue this request?
- Legal authority. What statutory power, warrant, court order, production order or other basis entitles or requires the authority to obtain the information?
- Scope. Does that authority justify this particular information, about these particular people, for this period and purpose?
These questions should never collapse into a single "request verified" checkbox. A requester can be genuine while exceeding their authority. A document can be genuine while requesting excessive data. An agency can have investigative authority without holding a compulsory production power in the particular circumstances. And a legally valid order may still need interpretation before the organisation knows exactly what falls within scope.
Necessity and minimisation still apply
The ICO's guidance contrasts a disclosure limited to the period the police specified with handing over years of records and a full personnel file that the investigation did not need. That should translate into a practical rule: a valid requisition is not permission to export everything associated with an account.
A request for transactions between two dates does not automatically justify the full account history. A request for an address does not automatically justify copies of identity documents. A request concerning one account holder does not automatically justify information about unrelated third parties. Map the legal demand against the available data before extraction, and where scope is unclear or apparently excessive, seek clarification rather than resolving the ambiguity in favour of disclosure.
International requests add another legal layer
For organisations subject to the EU GDPR, Article 48 addresses judgments of third-country courts and tribunals, and decisions of third-country administrative authorities, requiring a controller or processor "to transfer or disclose personal data". They "may only be recognised or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting third country and the Union or a Member State, without prejudice to other grounds for transfer pursuant to this Chapter."
The EDPB's Guidelines 02/2024 on Article 48 GDPR (version 2.0, adopted on 4 June 2025 after public consultation) state that a request from a foreign authority does not in itself constitute a legal basis for the processing or a ground for the transfer. A two-step test applies: a legal basis for the processing, and compliance with Chapter V for the transfer. Article 48 is not itself a ground for transfer.
Operationally, the workflow needs a jurisdiction check before disclosure. An organisation should know where the requesting authority is located, which corporate entity controls the requested records, where those records are held, what law governs that entity, whether the foreign demand has any direct legal effect, whether a mutual legal assistance treaty or another recognised cooperation mechanism should be used instead, and what Chapter V ground supports any resulting transfer. A group operating across several jurisdictions cannot safely run every police request through one generic "government request" workflow.
Security law reaches the disclosure process
Article 32 GDPR requires security appropriate to the risk. In assessing that level, account must be taken of the risks of "unauthorised disclosure of, or access to" personal data (Article 32(2)), and the measures to adopt as appropriate include "a process for regularly testing, assessing and evaluating the effectiveness" of those measures (Article 32(1)(d)). A requisition workflow belongs inside the security-control environment, not beside it.
For financial entities, DORA reinforces the point. Article 9(2) requires them to design, procure and implement ICT security policies, procedures, protocols and tools aimed at the resilience, continuity and availability of ICT systems and at maintaining high standards of availability, authenticity, integrity and confidentiality of data. Article 9(1) requires them to minimise the impact of ICT risk through appropriate security tools, policies and procedures.
The lesson is broader than banking. A procedure that lets highly sensitive data leave an organisation because one apparently official email arrived in a shared mailbox deserves the same scrutiny as any other privileged access path.
What a defensible requisition workflow looks like
A strong process does not need to obstruct legitimate investigations. It needs to make unlawful disclosure difficult without making lawful disclosure unreasonably slow. At minimum:
- A controlled intake channel. Government and law-enforcement requests enter through designated channels, not individual employee inboxes.
- Independent requester verification. The official is verified through previously established contact details, an official directory, a verified portal or another channel that does not depend on details supplied in the request.
- Authority validation. The statutory power, order, warrant, court authority or voluntary-disclosure basis relied on is identified and recorded.
- Jurisdiction and entity matching. The authority has jurisdiction over the relevant corporate entity, and any cross-border transfer requirement has been considered.
- Necessity and proportionality review. The requested information is necessary for the stated purpose, and the request cannot be met with less.
- Data-scope mapping. The legal request is translated into an exact dataset before extraction: dates, accounts, categories of information and the individuals concerned are explicit.
- Dual control for sensitive disclosures. High-risk disclosures need legal or compliance review and a second authorised approver.
- Secure transmission. Sensitive records are not attached to ordinary email simply because the request arrived by email. Use an independently authenticated secure channel.
- Immutable logging. The request, the verification performed, the legal basis, the scope analysis, the approvals, the data disclosed, the transfer method and the time of disclosure are all recorded.
- Post-disclosure reconciliation. Especially for emergency or unusual requests, confirm through an independent channel that the requesting authority received and recognises the disclosure.
That last control is the one most often missing. A request should have a lifecycle, not just an approval event.
Emergency requests need stronger authentication, not weaker
Emergencies create the hardest trade-off. Law-enforcement agencies may legitimately need information quickly where life, physical safety, child protection, terrorism or other urgent risks are involved. That urgency cannot mean abandoning requester verification. Urgency is itself one of the most familiar social-engineering techniques.
An emergency process should therefore be faster and more structured: 24-hour verified agency contact routes, pre-agreed escalation paths, senior approvers, and narrowly defined categories of information that may be released rapidly. The objective is to reduce the time verification takes, never to remove it.
If a fraudulent requisition succeeds, run the breach process
A personal data breach is "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data" (Article 4(12) GDPR). When an impersonation defeats a disclosure control and records reach an unauthorised requester, the incident should enter the organisation's breach-response process as a suspected personal data breach.
That means containment, establishing what was disclosed and to whom, assessing the risk to the individuals affected, preserving evidence, and deciding on notification. Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. Article 34 requires communication to the individuals where the breach is likely to result in a high risk, subject to its stated exceptions.
Revolut says that on detection it blocked the address and alerted "the relevant government agency as well as enforcement agencies, data protection, and financial regulators." For identity documents, selfies, addresses and transaction histories, the secondary harm deserves particular attention: that material can enable further impersonation, fraud, targeting and coercion. The incident does not necessarily end when the fraudulent channel is closed.
The control lesson
The weak model is: official request received, legal team reviews, data supplied.
The stronger model is: request received, requester independently authenticated, authority validated, jurisdiction established, necessity tested, scope minimised, disclosure approved, recipient independently authenticated, transfer secured, evidence retained.
Lawful-access processes exist because governments sometimes have a legitimate and compelling need for information. That makes them necessary. It also makes them an attractive attack surface. The apparent legitimacy of a request must never substitute for verification of the authority behind it. A law-enforcement request is not merely correspondence: it is an instruction capable of moving protected data outside the organisation, and it should be governed like any other privileged, consequential action.
Requisition governance as a control chain
Read through the Compliance Intelligence Chain, a disclosure process has the same structure as any other regulated control. Organisation context comes first: which entity holds the records, where it is established and in which role it acts. Applicability turns on that context, the jurisdiction and the date. The obligations are a lawful basis, minimisation, security appropriate to the risk and, for a transfer, a Chapter V ground. The controls are the verification, authority, scope, approval and transmission steps above. Evidence is the record of each decision. Gap analysis and prioritised remediation begin the moment a control is found wanting. And monitoring keeps the process honest over time: testing that the controls still operate, reconciling disclosures after the fact, and watching the law itself, as the ICO's own review of its guidance after the 2025 Act shows. Every stage traces back to its source: GDPR Articles 5, 6, 32 and 48, the UK's recognised legitimate interests and Schedule 2 exemption and, for a financial entity, DORA Article 9.
Designed that way, a requisition stops being an inbox task and becomes a governed process that can be traced back to the law that requires it.
How Priventia helps
Priventia connects regulatory obligations to the controls that carry them, the monitoring that tests them, and the evidence that shows they operated. The Controls Library links each control to the specific legal obligation it supports, and Monitoring schedules the testing that shows whether a control executed, with findings and remediation tracked against it. For a law-enforcement requisition process, that means the verification, authority, scope and approval steps can be owned, tested and traced to the provisions that require them.