Fraudulent DSAR Detection

What You'll Learn

• Recognize common cybersecurity threats
• Respond appropriately to security incidents
• Protect sensitive information
• Follow security best practices
• Report suspicious activities

Training Steps

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

Knowledge Check Questions

This training includes a 6-question quiz to test your understanding of Security Awareness threats and defenses.

• Under GDPR, how long does an organization have to respond to a legitimate Data Subject Access Request (DSAR)?
• What should you do if a DSAR request comes from an email address that doesn't match the customer's registered email on file?
• Which of the following are red flags indicating a potentially fraudulent DSAR? (Select all that apply)
• Why is responding to a fraudulent DSAR without proper verification considered a data breach?
• According to GDPR Recital 64, what should organizations use to verify the identity of DSAR requesters?