A hacker posed as a government agency and extracted customer data from Revolut for five months. The breach occurred because Revolut, like most financial institutions, must legally respond to law enforcement requests. The attacker compromised a government employee's email through malware, then used that legitimate email to submit fraudulent data requests.
This checklist helps you verify government requests before releasing customer data. It's designed for financial institutions, but the principles apply to any organization handling sensitive information and responding to legal processes.
What This Checklist Covers
You'll establish a verification protocol for government data requests, balancing legal compliance with security. The checklist addresses authentication of the requesting party, validation of request legitimacy, internal approval workflows, and documentation requirements. Each item includes what "good" looks like in practice.
Prerequisites
Before implementing this checklist, ensure you have:
- A designated legal contact to interpret law enforcement request authority
- Access to official government agency contact directories
- A secure communication channel for sensitive verification conversations
- Documentation of your organization's data access logging capabilities
- Clear escalation paths to senior legal counsel for unusual requests
Verification Checklist
1. Authenticate the requesting email domain
Check that the sender's email domain matches the official government agency domain. Don't rely on the display name. In the Revolut case, the attacker used a legitimate pec.interno.it address belonging to Italy's Ministry of the Interior.
What good looks like: You maintain a reference list of official government domains for jurisdictions where you operate. You verify the domain matches this list before proceeding. If the request comes from a new domain, you pause and verify through official channels.
2. Verify the sender's identity through an independent channel
Call the agency using a phone number from their official website or directory, not from the email signature. Ask to speak with the individual who sent the request.
What good looks like: Your team contacts the agency's main switchboard or legal department, provides the sender's name, and confirms they work there and sent the request. You document the name of the person you spoke with, the number you called, and the date of verification.
3. Validate request authority and scope
Confirm the request cites proper legal authority (court order, subpoena, emergency disclosure provision) and that the requesting party has jurisdiction over your organization.
What good looks like: Your legal team reviews the cited legal basis and confirms it applies to your entity. For cross-border requests, you verify mutual legal assistance treaties or other authorization mechanisms are in place.
4. Check for unusual request patterns
Flag requests that ask for data outside normal law enforcement parameters. The Revolut breach involved requests that continued for five months, targeting approximately 680 customers described as cryptocurrency holders.
What good looks like: You track request frequency, data types requested, and customer profiles involved. Requests targeting specific customer segments or arriving at unusual frequency trigger additional review.
5. Require proper request formatting
Legitimate law enforcement requests follow established formats and include specific reference numbers, case identifiers, and official letterhead.
What good looks like: You maintain templates of proper request formats for each jurisdiction. Requests missing standard elements get returned for completion before you process them.
6. Implement dual-approval workflows
No single person should authorize data release in response to government requests. Require both legal review and operational approval.
What good looks like: Your legal team approves the request's validity, then a senior operations manager approves the data release. Both approvals are documented in your ticketing system with timestamps and justifications.
7. Log all verification steps
Document every action you take to verify a request, including who you contacted, what you confirmed, and any discrepancies you found.
What good looks like: Your verification log includes: request received date, sender details, verification calls made, legal review notes, approval chain, data released, and release date. This log is preserved separately from routine request tracking.
8. Establish request expiration windows
Set time limits on how long you'll honor a request without re-verification. The Revolut breach persisted because the attacker maintained access to the compromised email account.
What good looks like: Requests older than 30 days require re-verification before you release additional data. Standing requests require quarterly re-authentication of the requesting party.
9. Monitor for compromised government credentials
Track whether government email addresses in your region appear in infostealer malware databases. Hudson Rock identified over 300 compromised credentials associated with the pec.interno.it domain.
What good looks like: You subscribe to threat intelligence services that monitor for compromised government credentials. When credentials from a requesting agency appear in breach databases, you implement enhanced verification for all requests from that agency.
10. Create an escalation protocol for suspicious requests
Define clear triggers that require immediate escalation to senior legal counsel and security teams.
What good looks like: Your protocol specifies that requests meeting any of these criteria get escalated: sender can't be verified through independent channels, request format is non-standard, requested data scope is unusual, verification callback reveals the sender didn't send the request.
Common Mistakes
Trusting the email address alone. The Revolut attacker used a legitimate government email because they compromised the actual account. Email address authentication is necessary but not sufficient.
Skipping verification for familiar-looking requests. The attacker's requests likely resembled legitimate ones, which is why they succeeded for five months. Verify every request, even if it looks routine.
Releasing data before completing all verification steps. Legal pressure to respond quickly can't override security verification. Build verification time into your response SLA.
Failing to detect pattern anomalies. If you're not tracking request patterns, you won't notice when a single "agency" requests data on hundreds of high-value customers over months.
Next Steps
Implement this checklist within your legal and compliance workflow. Train your team on verification procedures quarterly. Test your protocol by conducting tabletop exercises where you simulate suspicious government requests.
Review your verification logs monthly to identify process gaps. If you find requests that bypassed steps, investigate why and close the gap.
Consider whether your current incident response plan addresses impersonation scenarios. The Revolut breach involved social engineering, not a technical vulnerability. Your IR plan should cover both.
Document your verification process improvements. If a breach occurs despite your controls, documented verification procedures demonstrate reasonable security measures to regulators and cyber insurers.
