A fraudulent data request is a request for personal data that arrives through a legitimate-looking channel, cites a legitimate-looking authority, and is designed to make your team hand over records to someone who has no right to them. Most of the published coverage frames this as an American problem involving forged emergency requests to large tech platforms. The UK reality is broader and quieter. The same social engineering turns up as a subject access request under UK GDPR, as a payroll query to HR, or as an email from a solicitor whose domain differs from the real one by a single character.

What makes these requests work is not technical sophistication. It is the fact that your privacy process, your service desk and your HR inbox are all built to be helpful, and all measured on turnaround time.

The four shapes a fraudulent data request takes

Recognising the pattern matters more than memorising indicators, because the wording changes constantly and the structure does not.

1. Forged emergency or urgent law enforcement requests

An email arrives claiming an immediate risk to life, asking for subscriber details, account data or location information without a warrant. The urgency is the attack. It exists to move the request around the checks that would normally apply, and it works because refusing a genuine emergency feels unthinkable. Bloomberg reported in March 2022 that Apple and Meta had each provided user data in response to forged emergency data requests sent from compromised law enforcement email accounts, and KrebsOnSecurity documented the trade in access to official police and government mailboxes on cybercrime forums during the same period. The mailbox in those cases was real. The officer was not.

2. Impersonated subject access requests

Article 15 of the UK GDPR gives individuals the right to a copy of their personal data. An attacker claiming to be a customer, a former employee or a claimant can use that right as a retrieval tool, and the reward is substantial: a full record often contains address history, contact details, transaction data, internal notes and correspondence. A fake subject access request does not need to defeat your security. It needs to defeat your identity check.

3. Internal impersonation of executives and payroll providers

A request lands with HR from a 'new payroll bureau' or from an executive travelling and unreachable by phone, asking for a staff list, P60s, National Insurance numbers or bank details. The timing is rarely accidental. A typical pattern is Friday afternoon, framed as a deadline for the auditors before month end, sent from a domain one character away from the real supplier.

4. External impersonation of solicitors, insurers, regulators and suppliers

Legal and insurance correspondence carries built-in authority, references a matter number and expects a prompt reply. A lookalike domain does most of the work here, supported by scraped detail that makes the letter read correctly. Privacy and legal teams often treat domain spoofing as a security problem. It is a disclosure problem.

Where attackers get the material to make a request look real

A convincing request is assembled, not improvised. Four sources supply almost all of it.

Infostealer infections and stealer logs

Most of these operations begin with a single infected device. Infostealer malware harvests saved credentials, autofill data and live session cookies, and those logs are packaged and resold in bulk. A log containing a valid session for an official or corporate mailbox lets the buyer send a request from a genuine, trusted, properly authenticated address, which is why technical email authentication tells you nothing in these cases. Finding your own exposed credentials and sessions early removes the attacker's most persuasive asset, and our guide to triaging leaked credentials found on the dark web covers how to work through those findings without drowning in noise.

Access to official mailboxes traded on forums and Telegram

Mailbox access, inbox dumps and credential sets are advertised in closed forums and increasingly in Telegram channels, where sales move faster and disappear faster. That is the practical argument for monitoring Telegram alongside traditional dark web sources: if access to your own domain is being sold, requests sent in your name are the next step, and you have a short window to invalidate sessions and reset credentials before it happens.

Executive and employee OSINT

Job titles, reporting lines, internal terminology, finance calendars, out-of-office patterns and writing style are all available from social media, conference listings, supplier case studies and documents leaked in earlier breaches. Continuous OSINT monitoring of your public digital footprint shows you what an attacker can assemble about your people before they use it as impersonation material.

Registered and unregistered lookalike domains

Character-swap and homoglyph variants of your domain, and of your law firm's or payroll provider's domain, are cheap and quick to register. Unregistered variants sitting idle are a pre-positioned risk. Watching for newly registered variants belongs in the privacy team's toolkit as much as in security's, because the privacy inbox is where the domain gets used.

A verification playbook to run before you release anything

Four controls carry most of the weight. They are not expensive, but they have to be mandatory rather than advisory.

1. Verify out of band, always. Call back on a number you source independently, from the organisation's own published website or a directory you look up yourself. Replying to the thread verifies nothing. Calling the number in the signature verifies nothing. If the mailbox is genuine and compromised, every in-channel check confirms the attacker.
2. Route law enforcement requests through the published single point of contact. Confirm the officer's identity and collar number through the force's own switchboard, record the force, the reference, the legal basis relied on and the specific data sought, and keep that record with the decision. Genuine officers expect this. An urgent request that collapses under a callback was never urgent.
3. Require dual authorisation for bulk disclosure. Cap what any individual can release alone. One named approver signs off anything beyond a single record, and no approver signs off their own request. This single control defeats most payroll and employee-record attempts, because attackers depend on one helpful person acting quickly.
4. Log every request, every verification step and every decision. Fraudulent requests rarely arrive once. Organisations that log attempts, including the ones they refused, start to see probing across HR, the service desk and the DSAR inbox that no single team would ever notice on its own.

The DSAR trap: identity checks that satisfy the ICO without stalling the clock

Privacy teams tend to over-focus on the statutory response deadline and under-focus on identity, and both failures carry regulatory consequences. Miss the deadline and you have breached the UK GDPR. Disclose to an impostor and you have caused a personal data breach. The deadline is the one that gets reported to the board, which is exactly why identity gets squeezed.

Under Article 15 and the Data Protection Act 2018, you have one month to respond, extendable by up to two further months where the request is complex or numerous. ICO guidance is that you may use reasonable means to confirm the identity of the requester. Reasonable is the operative word. Matching details you already hold, confirming through an authenticated account, or asking for one proportionate document is reasonable. Demanding a passport, a utility bill and a selfie for a request about a single marketing preference is not, and collecting excess identity data to protect yourself creates a fresh compliance problem of its own.

Where you genuinely need identification before you can respond, the ICO's position is that the response period runs from the point you receive the information you need, so ask promptly and ask once. Padding out the process with repeated requests for documents looks like obstruction, and the clock does not forgive it. Separately, a request that is manifestly unfounded or excessive can be refused or charged for, but that test is about abuse of the right itself, not about your suspicion that the requester is someone else. Suspected impersonation is an identity question, handled with verification and, where appropriate, refusal and escalation.

One point worth stating plainly to any team that handles disclosure: releasing personal data to someone impersonating the data subject is a personal data breach, with the 72-hour assessment and reporting obligation attached. Section 170 of the Data Protection Act 2018 also makes knowingly or recklessly obtaining or disclosing personal data without the controller's consent a criminal offence, which is the legal description of what the requester has just done to you. The full wording of section 170 is worth circulating to anyone who thinks of this as a procedural matter.

Monitoring that catches the setup before the request arrives

Verification stops the request at the door. Monitoring removes the attacker's materials before they get that far.

• Credential and stealer log monitoring so a compromised mailbox on your domain is identified, reset and session-invalidated before it is used to send requests in your name.
• Dark web and Telegram monitoring for mentions of your brand, named staff, or access being advertised for sale, which is often the earliest signal that an impersonation campaign is being prepared.
• DNS surveillance for newly registered lookalike domains, paired with a practical takedown route: capture the evidence, record the registrar and hosting provider, and submit an abuse report while the domain is still inactive. Our work on mapping and monitoring your external attack surface covers how domain and subdomain discovery fits alongside the rest of your public-facing estate.
• VIP and people monitoring so exposed executive and employee detail is reduced before it becomes the raw material for a convincing internal request.

Turning the playbook into something the business actually runs

Policy documents do not stop disclosure. Front-line decisions do. Give the people who receive these requests a one-page decision flow: who can approve what, which checks are mandatory, and the explicit instruction that stopping and escalating is always an acceptable answer. Remove the pressure to be helpful and you remove the attack.

Supplier assurance deserves more attention than it usually gets, because your processors receive requests on your behalf. If a bureau, BPO or SaaS provider releases your customers' records to an impostor, the exposure and the reporting obligation are yours. Ask how they verify requests, who in their organisation can authorise disclosure, and what they log, rather than filing the ISO 27001 certificate and moving on. The supplier lessons from the Harrods data breach make the same point from the incident side.

Operationally, get suspected fraudulent requests out of email. Route them into Slack, Teams, Jira or your SIEM so they are triaged, timestamped and visible, rather than debated in a forwarded thread that nobody owns. Set the escalation lines in advance: internal security and the DPO first, the ICO within 72 hours of becoming aware where a breach has occurred (its breach reporting guidance sets out the process), and Action Fraud for the fraud attempt itself.

Then change what you report upwards. Completed DSAR counts and average turnaround tell the board nothing about this risk. Attempt volumes, refused requests, near misses and lookalike domains taken down tell them whether the control is working. If you want help establishing that external visibility, speak to the DarkInvader team about what your organisation currently exposes.

Fraudulent data requests succeed because they exploit obligation rather than vulnerability. Verify out of band, cap what one person can release, log every attempt, and watch the dark web and Telegram channels where mailbox access and brand mentions are traded, and the request arrives with nothing credible behind it.

Frequently Asked Questions

What is a fraudulent data request?

It is a request for personal data made by someone pretending to be entitled to it: a police officer, the data subject, an executive, a solicitor or a supplier. The channel often looks entirely legitimate, because attackers frequently send from genuine mailboxes they have compromised or from lookalike domains. The aim is disclosure by consent rather than intrusion by force.

How should we verify an emergency data request from the police?

Contact the force through its own published single point of contact, using a number you look up independently, and confirm the officer's identity, reference and the legal basis for the request. Never reply to the thread or ring the number in the signature, because the mailbox may be real and compromised. Record the verification steps alongside whatever you disclose.

Can we refuse a subject access request if we doubt the requester's identity?

You should not disclose personal data to someone whose identity you cannot reasonably confirm, and ICO guidance supports using reasonable means to verify who is asking. Ask for proportionate evidence, not an exhaustive document set. If verification fails and the indicators point to impersonation, decline the disclosure, document the reasoning and escalate it internally.

Does the one-month DSAR deadline pause while we verify who the requester is?

Where you genuinely need identity information before you can respond, the ICO's guidance is that the one-month period runs from when you receive that information. Ask promptly and in one go, because repeated or disproportionate demands look like delay tactics. Complex or numerous requests can be extended by up to two further months, provided you tell the requester within the first month.

If we disclose data to a fraudulent requester, is it a reportable breach?

Disclosing personal data to an impostor is an unauthorised disclosure, so you need to assess it as a personal data breach and report it to the ICO within 72 hours of becoming aware where there is a risk to individuals' rights and freedoms. Affected individuals may also need to be informed where the risk is high. Report the fraud itself to Action Fraud, and preserve the email headers, domains and call records as evidence.