How our Team Posed as Users and Uncovered Errors in Handling Data Subject Requests
From time to time, clients/users/customers contact a company with requests related to personal data. They may ask to delete their data or get detailed information about how their data is being used. A company can describe all procedures for responding to such requests and prepare appropriate policies, but still make unfortunate mistakes in the most visible places.
Project overview
The Request
A company approached us wanting to verify: are they responding correctly to user requests?
Our Solution
We didn’t take the usual path of reviewing response policies. We decided to conduct “field research” and assess how everything works in practice, not just on paper. We sent three requests from personal email addresses, posing as ordinary users. Naturally, no legal terminology in the requests — after all, we had just “heard something” about GDPR 🙂
Important: our team deliberately did not conduct training for the client’s employees before starting the test, in order to assess the current state of processes. The consultants didn’t even inform employees of the department we were testing about this audit. Only the company’s privacy team was aware that we would send several requests — this was the client’s wish.
Lead Project Consultant
Daria Zagranichnova,
CIPP/E, GDPR DPP, Data Privacy Consultant
Experiment Results
After sending the requests and a long wait, we got the following results:
We requested information about processing within the application: we never received a response.
After requesting data deletion, we immediately received an automatic reply stating that we would get a response within 3 hours (or later if support needed more time). However, the response never came.
What gets a plus: the user has the ability to quickly contact the company with a request and receive an instant automatic confirmation that the request has been received.
What gets a minus:
- multiple communication channels (privacy department email and support service);
- absence of "Privacy" topic in the support request;
- no response from support, although this particular case could have been handled by a bot: if the company receives a data deletion request, the bot could send instructions on how to delete their account. Moreover, a clear mechanism needs to be developed for how exactly the user will receive confirmation that their data has been deleted.
With the request for access to information, that is, to obtain a copy of data, everything also turned out to be not so simple. The team did indeed respond to this request, even meeting the response deadline of 14 days, but made an error in the actual data.
The request required providing the actual data, but the team sent a description of how the company works with it, and suggested studying the remaining details independently in the Privacy Policy.
Experiment Results
1) Substitution of concepts: "Information" instead of "Copy".
GDPR distinguishes between two user rights: simply finding out how data is processed, and obtaining a copy of that data. In the response, we received a general description of processes (what data the company collects, why, on what basis), which essentially duplicates the privacy policy. But the request was specifically for a copy (Art. 15(3) GDPR). This means that employees should have extracted the data from the system and sent a specific file with the user’s data (for example, ID, email, country, transaction history, activity logs, etc.), not just text with a general description of processes.
2) Absence of mandatory details.
Even in the text portion of the response, important specifics were missing. Employees didn’t specify the exact list of recipients of our data (to whom it is transferred) and specific retention periods. Simply providing a link to the privacy policy is insufficient in this case—the response must be individualized.
3) No explanation.
Since employees didn’t attach a copy of the data, they should have explained to the data subject (that is, us) why they didn’t do so. The response contained no explanation about the refusal to provide a copy.
What should have been done?
Instead of a general description, employees should have extracted information from the database relating to this user (including technical logs, browsing history, and profile data), and provided the ability to download this file in one of the common file formats. If there’s too much data, the law allows first asking the user: “What specific data or for what period do you need?”, but simply ignoring the copy requirement is not allowed.
Issues in the Process We Found
During the experiment, we identified critical violations in the request handling process:
Ignoring requests.
Out of three submitted requests, the company responded to only one. Requests for information about processing and for data deletion were missed.
Incorrect response.
The only response that was received (to the request for a copy of data) turned out to be wrong. Instead of providing a copy of data, the company limited itself to only information about its processing.
Overall process failure.
The experiment showed that the process doesn’t work properly and employees make mistakes even when handling simple requests.
What Would Have Happened If These Were Real Data Subject Access Requests?
If these were requests from real users, the most impatient data subjects could have already filed complaints with the supervisory authority. And this, in turn, can lead to:
Fines
Although in practice the amount of sanctions is often smaller, in theory the fine for violating this GDPR provision can reach 10 million euros.
Additional audits
The supervisory authority may request information outside the scope of the complaint and identify other violations.
Team time waste
In communication with the supervisory authority and attempts to fix the situation, the team spends more of its time than it would have spent on a correct response to the data subject. Moreover, in such a case, there’s a risk that the company won’t be able to resolve the situation with the supervisory authority independently and will have to spend part of its budget on engaging external consultants.
Well, and if the team misses requests from the supervisory authority just as it did from data subjects, then in some jurisdictions, for example, in Cyprus, this can result in criminal liability for the business head.
How We Proposed to Fix the Issues in the Current Response Process of the Organisation?
Setting Up the "Backstage" of the Process
- Training the first line: support staff must be able to recognize trigger words (for example, “GDPR”, “delete my data”, “access request”) and know to whom to forward such requests.
- Logging: it’s necessary to maintain a register of all incoming requests with recording of the date of receipt, deadline, and actions taken. This will allow controlling deadlines and analyzing errors.
Handling Deletion Requests (Right to Erasure)
- Deletion from all systems: data must be erased not only from the “live system”, but also from back-ups.
- Notification chain: if the company transferred data to partners or contractors, it is obliged to inform them about the user’s requirement to delete this data.
- Handling exceptions: if data cannot be deleted (for example, the law requires keeping financial records for 5 years), this must be directly and reasonably communicated to the user, not just kept silent. The company’s silence can play a nasty trick on it.
Communication and Deadlines
To reduce legal risks and the burden on the team, we proposed implementing clear communication standards:
- Response templates: use pre-prepared legally vetted texts (scripts) for different types of requests to eliminate employee improvisation. Templates are convenient and predictable.
- “First touch” rule: it’s considered good practice to immediately confirm receipt of the request in writing and indicate the date by which a response will be provided.
- Request clarification: if a user demands their data and there’s a lot of data, you can ask the user to clarify what exactly they need. After all, the user may not even realize HOW MUCH data they’ll be provided (although they might really only need payment data for the last month, for example). Important nuance: such a request does not stop the statutory 30-day response period.
Is Your Team Ready for Such a Secret Audit?
Sign up for a free consultation with our consultant to assess the current process of responding to data subject requests and understand how to improve them.
