Fraudulent DSAR Detection
Spot fake data access requests used for social engineering.
What You'll Learn
- Identify red flags in DSAR submissions that indicate social engineering or identity impersonation
- Apply proportionate identity verification procedures that detect fraud without burdening legitimate requesters
- Use GDPR Article 12(6) grounds correctly when refusing manifestly unfounded or excessive requests
- Document verification steps and refusal reasoning to withstand supervisory authority scrutiny
- Escalate suspicious DSARs through the appropriate internal channels while preserving the 30-day response timeline
Training Steps
-
Introduction
You are Alice Chen, a Customer Support Specialist at PrivacyFirst Technologies. Your company provides cloud-based data management solutions to enterprise clients. As part of your role, you handle Data Subject Access Requests (DSARs) - requests from individuals exercising their rights under GDPR to access, correct, or delete their personal data. Today, you'll learn how attackers exploit GDPR regulations to steal personal data through fraudulent DSARs.
-
The Urgent Request
Alice starts her morning by checking the DSAR inbox. Among the usual requests, one email immediately catches her attention due to its aggressive tone and urgent subject line. The email claims to be from 'Marcus Thompson,' demanding all personal data within 24 hours and threatening legal action.
-
Red Flag - False Timeline
Alice immediately notices something wrong with this request. The sender claims PrivacyFirst must respond within 24 hours, threatening legal action. But Alice remembers from her GDPR training that the actual response timeline is different.
-
Red Flag - Personal Email
Alice notices another suspicious element - the request came from a personal Gmail address rather than a corporate or previously registered email. This is unusual for someone claiming to be an existing customer.
-
Red Flag - Aggressive Tone
The email's threatening language and legal threats are designed to intimidate and pressure Alice into acting quickly without following proper verification procedures. This emotional manipulation is a classic social engineering tactic.
-
Verification Protocol
Despite the aggressive tone, Alice knows she must follow proper verification procedures. Sending personal data to an unverified requester would itself constitute a data breach under GDPR. Her first step is to check if Marcus Thompson exists in the customer database and verify the email address on file.
-
Customer Record Search
Alice accesses the customer database to look up Marcus Thompson. If he's a real customer, his record will show the registered email address, allowing her to verify whether the DSAR came from the actual account holder.
-
Critical Discovery
The customer lookup reveals crucial information: Marcus Thompson IS a real customer, but his registered email address is m.thompson@techcorp.com - completely different from the Gmail address that sent the DSAR. This confirms Alice's suspicions - someone is attempting to impersonate a real customer to steal their data.
-
Initiating Proper Verification
Following company protocol, Alice will now send a verification request to the REAL Marcus Thompson using his registered email address m.thompson@techcorp.com - not the address provided in the suspicious request. This ensures only the actual customer can verify their identity.
-
Fraudster Fails Verification
The verification request to m.thompson@techcorp.com receives a confused response from the REAL Marcus Thompson, confirming he never made any DSAR request. Meanwhile, the attacker sends increasingly aggressive follow-up emails to the DSAR inbox, demanding to know why the data hasn't been sent.