Phishing the GDPR Data Subject Rights
Companies across the globe are now working toward compliance with the EU GDPR, while phishers may be preparing to exploit their new compliance processes. Airbnb first fell prey to a GDPR-related scam, with more surely to come. Unfortunately, many GDPR security efforts have focused primarily on Article 32 while overlooking new ancillary compliance program risks.
One new point of data egress usually lands outside the purview of the security team: the data subject rights established in Articles 15 to 22. This egress can become exfiltration when an organization’s support team provides data to a phisher impersonating a legitimate data subject. Organizations may design lenient data subject rights processes with minimal identity verification in hopes of avoiding data subject complaint fines. When self-service methods aren’t possible, how can organizations honor these rights without falling victim to phishing attacks?
Involve the Security Team
Controllers overwhelmed with a high request volume or very complex requests can extend the standard one-month processing time by an additional two months, giving a maximum of three months to process requests (Article 12.3). Consult the security team when designing the response procedure, whether it is manual, self-service or some combination thereof. Include the process in your risk assessment and request a security review, especially where there is sensitive or special category data.
Limit Personal Data Sent Out of the Organization
Practice data minimization in the amount of personal information sent outside of the organization in response to rights requests. Controllers with a significant amount of information in an individual’s record can ask the data subject if they would like to specify a data type or processing activity for the request rather than providing the full record (Recital 63). If possible, limit the scope to deliver only what the data subject truly wants—and no more—rather than sending the entire record by default. Controllers do not have to send information that the data subject already has or can access (Article 13.4 and Recital 62). Ask if the individual simply needs help with account access, a password reset or finding their data.
Identify Data Subjects, Records and Organizations
Identity verification is a critical step in rights response processes, especially for controllers who have never had to confirm identities before. Controllers are allowed—and expected—to positively verify the identification of any data subject before honoring a request (Article 12.6 and Recital 64). While the identity verification process should not be excessively difficult or require highly sensitive documents to access low-risk information, implementing a well-designed process can catch phishing attacks and human error. For example:
- Require identification appropriate to the volume and sensitivity of data to be delivered. Special category data and records with large amounts of personal data should be more carefully vetted.
- Require marriage, divorce or adoption documentation or other government-issued evidence of a name change before providing records with multiple names.
- Give users a secure method for providing documentation. Don’t force data subjects to use unencrypted email to transmit photos or sensitive text. Similarly, deliver any records to the data subject or destination organization with a level of security appropriate to the risk.
- Positively identify the destination organization and point of contact before honoring portability requests. Require that organization to accept or provide secure data transmission.
- Develop equally secure identification methods for both phone and online requests.
- Ensure that all requests are managed or reviewed by someone fluent in the data subject’s language and confirm the validity of unfamiliar government documentation.
Look to the U.S. Anti-Money Laundering (AML) and Know Your Customer (KYC) regulations for current best practices. Keep up with evolving standards for identity verification and watch technology developments such as blockchain-based identity management or government schemes such as the EU Electronic identification (eID) and electronic trust services (eTS), particularly the eIDAS Regulation. A third-party identity verification service may provide additional security if you are not confident in your organization’s ability.
Get the Right Record
After you have confirmed a data subject’s identity, be certain that you have matched the individual to the correct data record. Verifying that a user is indeed named John Smith doesn’t immediately give him the right to all records you have associated with the name “John Smith.” Ask the data subject to corroborate unique information in the record without volunteering details, avoiding questions about easily researched information such as a home address. Reject the request if it’s not a clear association and be more skeptical of common names. Review deduplication algorithms and history for accuracy.
Discourage and Deny Invalid Requests
Don’t overlook the most fundamental security measure in data subject rights processing: denying invalid requests. Controllers always have the right to reject a suspicious or illegitimate request. For example, controllers:
- Do not have to honor portability requests unless the data was processed on the basis of consent or for a contract (Recital 68).
- Do not have to honor portability requests if the processing is not automated and technically feasible (Article 20.1-2).
- Aren’t obligated to design their systems to be compatible with other controllers (Recital 68).
- Can charge a fee for, or simply refuse, repetitive or abusive requests (Article 12.5).
- Can refuse any request where the data subject can’t be positively verified or clearly associated with a record containing personal data about that data subject (Recital 64).
- Can sometimes refuse a request as “impossible” or requiring “disproportionate effort” (Recital 62).
- Can refuse or partially fulfill a request that would adversely affect the rights and freedoms of other individuals (Article 15.4 and Article 20.4).
Reduce Human Error
Employee mistakes are often the highest security risk for organizations and the greatest opportunity for attackers. Reduce the potential for human error by training all employees responsible for processing data subject requests. Encourage them to contact security for guidance on suspicious requests and practice a variety of scenarios, including some simulated phishing attacks by a red team. Implement layers of review and approval with security, legal or compliance teams before releasing any personal information to a data subject or other organization.
Finding the Balance
Every security program can fall prey to new vulnerabilities or become outdated, so continually review and improve your response procedures. Evaluate your process as a valid user and as an attacker. Is the procedure so difficult that it’s impossible to complete a legitimate request? Is it so easy that you’re likely to be repeatedly targeted for successful and undetected phishing attacks?
Track incoming data subject rights requests and maintain metrics to find trends. Do you have a suspiciously high number of similar requests? Is there any pattern indicating a leaky process? How often do you reject requests as invalid and why? The default position should be to deny requests until they are proven legitimate, rather than assuming all requests should be honored automatically. Consider each request individually and update your process when a new challenge or concern arises.
Don’t let intimidating GDPR fines reduce your commitment to security and strong data protection practices. Remember, delivering personal data to a phisher or the wrong individual is a data breach!
