Most organisations that hold legally protected data have a rule for releasing it to the authorities. Fewer can show that the rule is a control: a step with an owner, a check that runs before anything leaves, and evidence that it ran.
The Revolut incident of September 2026 is a case study in that difference. A fraudulent request arrived from a genuine government email domain, and identity documents went out in reply. There was no intrusion; Revolut has said its systems and customer funds were untouched. The data was handed over.
We chose this case for the same reason we chose Uber's driver deactivations. It shows the gap between having a rule and being able to demonstrate it, and that gap is where most compliance failures live. GDPR has applied since 2018 and DORA since January 2025. Between them they had already named the risk, the control, the training and the evidence. What was missing was the obligation in a form the person at the desk could act on, which is the problem RuleMesh exists to solve.
This is not an assessment of Revolut. We do not know its internal process, and the regulators will decide whether anyone fell short. What follows takes the public facts, reads the obligations that apply to a financial entity in this position, and shows the RuleMesh requirements behind them: what "done" looks like for each, who owns it, and the evidence an examiner would ask to see.
What happened
On 12 September 2026 TechCrunch reported, and Revolut confirmed, that an unauthorised third party had used a legitimate government agency email domain to submit fraudulent requests for information, and that Revolut had disclosed customer data in response. The data was identity and contact details and copies of passports and driving licences; Revolut's notice to customers says it may also have included verification selfies, account statements and transaction histories. Revolut called it a sophisticated impersonation scam, said a limited number of customers were affected, blocked the address, alerted the agency, law enforcement and its regulators, and emailed the customers concerned. It has not named the agency or the country, given a number, or said whether the mailbox was compromised or the domain spoofed, and neither will we.
Nor has anyone said which Revolut entity handled the request. That matters: Revolut's EU bank is a Lithuanian credit institution inside DORA, the EU's operational-resilience regulation for financial entities, while its UK arm answers to a different regime. The obligations below are read against a financial entity in this position.
Why this was a verification problem
Every security team knows that the sender shown on an email proves nothing about who wrote it. The regulations know it too, in their own vocabulary.
GDPR starts from a definition. Article 4(9) takes public authorities out of the ordinary meaning of "recipient" only when they receive data "in the framework of a particular inquiry in accordance with Union or Member State law". An impostor with a government address is a plain third party, and giving it personal data is processing without a lawful basis under Article 6. The controller has to know which of the two it is dealing with before the reply goes out. That is a legal determination, and the person at the desk was being asked to make it with a sender address as the only evidence.
DORA is blunter. Article 9(3)(d) requires financial entities to protect data from "poor administration, processing-related risks and human error". Article 9(4)(d) asks for "strong authentication mechanisms, based on relevant standards", and no standard treats a From: header as one. Article 13(6) makes security-awareness training compulsory, "commensurate to the remit of their functions". People who answer authority requests are a role with a specific threat model. Their module should cover impersonation of the state, not just phishing.
A convincing email from a real domain will beat untrained judgment most days. That is exactly why both regulations put the burden on the system rather than on whoever was on shift.
The obligations, written as requirements
This is where we bring in our own data. The RuleMesh graph holds GDPR and DORA as engineering requirements, each traced to its article and carrying a responsible role, a checklist and the evidence an auditor would expect. We pulled the ones on this incident's path. Statute is quoted with its article number; the requirement text is RuleMesh's reading of it.
One thing we noticed doing that. The requirement that fits best was written for a different scenario. Article 48 governs court orders and administrative decisions from outside the EU, which bind only through an international agreement such as a mutual legal assistance treaty. The requirement RuleMesh derives from it is an intake register with a legal assessment before any disclosure. Nothing in that workflow cares whether the requester is in Ohio or in the next town. It is the right control filed under a narrower heading, and the same discipline is what was missing here, whatever the agency's country.
1. Verify the requester before anything leaves
GDPR ARTICLE 48 · REQUIREMENT 654f9bb81947 · INTERNATIONAL TRANSFER GOVERNANCE MODULE
A formal intake and assessment process for legal orders that demand personal data, with workflow tracking that verifies a valid legal instrument exists before anything is disclosed.
- Done means: every order logged with its outcome, a legal assessment recorded per order, the DPO and counsel notified when the basis is missing, a refusal path.
- Evidence includes: the intake register, per-order assessment records, notification records, the decision documented for each order.
2. Process only on instructions
GDPR ARTICLE 32(4) · REQUIREMENT ea6bb42bca65 · ACCESS CONTROL & SECURITY MEASURES MODULE
Role-based access and technical enforcement so that staff process personal data only on the controller's documented instructions. Releasing passport scans on the strength of an email is outside those instructions, unless the instruction itself said to verify first.
- Done means: access rights provisioned from documented instructions and job roles, access logs that detect unauthorised processing, exceptions documented and auditable.
- Evidence includes: RBAC configuration, provisioning and deprovisioning logs, periodic access reviews, contract clauses that reference processing instructions.
3. Minimal by default, even for a genuine order
GDPR ARTICLE 25(2) · REQUIREMENT 33b38eb7a73b · CONTROLLER GOVERNANCE & ACCOUNTABILITY MODULE
Data protection by default across every processing system: collection limited to what a purpose needs, access restricted to the roles that need it, retention enforced automatically. A release path that can emit identity documents, selfies and statements in one action, to an outside address, on one person's say-so, is not minimal by default. A genuine order yields only the categories it names.
- Done means: a documented mapping of data fields to purposes, unnecessary fields off by default, personal data not accessible to an indefinite number of people.
- Evidence includes: form and API schemas showing only the necessary fields, access matrices, configuration change logs, minimisation review records.
4. Protect data from human error
DORA ARTICLE 9(3)(D) · REQUIREMENT 59c5e28cba9b
The clause quoted above, held as a requirement with an owner: protect data from risks arising from data management, including poor administration, processing-related risks and human error. Responsible role: data management lead.
- Done means: data administration processes reviewed for the risk of human error, automated safeguards in place against data-management errors.
- Evidence includes: data management procedure documentation, automated validation and error-check logs, staff training records on data handling.
What this changes for a team
Nothing above is new law. The gap was between the obligation and the person who needed it as a task, and that is the gap RuleMesh exists for. The obligation is already a requirement with an owner, a checklist and an evidence list, readable by a compliance officer in a browser, by an engineer in the tools the team already works in, and by an AI agent over MCP. An agent assessing your environment with RuleMesh data can find the evidence signals that already exist, an access matrix, a training record, a case-management configuration, and submit their names and metadata back. It never sends the content, and it never marks anything verified. A person does that.
We should be plain about the boundary. RuleMesh does not read the email, run the security operations centre, or make the verification call. It makes sure the requirement to do those things exists, has a named owner, and has evidence behind it when someone asks. The GDPR, DORA and AI Act requirements quoted here are live in the product. DORA and the AI Act are licensed, so free-tier accounts cannot access them; see the pricing page for access details.
Lessons from the case
- Trust is a control, and controls need evidence. "We verify requests" is a sentence. A register with an assessment against each request is proof.
- Minimisation limits the damage when verification fails. A path that can release everything at once is wrong by design, and stays wrong when the requester is genuine.
The useful exercise is a short one. Who in your organisation answers when the government asks for legally protected data, what do they check first, and where is that written down?