This article is there to help you sort out what action should be taken to ensure you can meet GDPR requirement regarding Data Subject Access Right.
Don’t write code now.
Except if your service is horrifying for people and you need to build trust from the get-go.
Or you know they have a significant probability to ask because, I don’t know maybe you asked a lot of personal data (customer/user research, studies, …)
One of the high upsides of GDPR is that it kind of “label” you as people’s rights friendly if you follow the requirements.
The reason I said to not write code right now, is that you don’t know if, when and in which quantity people will fill a data subject access request.
Save your limited resources for what matters the most.
The GDPR gives you a 30 days time frame to answer a request.
And even some more if you really bump into significant difficulties — that are real and documented— don’t take that for a free extended period.
BUT if you are a data processor for another data controller, you may not have this delay available.
You may even make it a differentiator: guarantying a response within seven days to DSAR from your customers as the data controller.
Nevertheless, be prepared, because you never know when it’s going to hit and you may be at that moment in a shitstorm of unforeseen complications, need everyone on the deck, bugs, conflict with customers,…
Consider it a pre-boarding security check. You don’t board a sailboat without knowing were is the safety equipment.
Same here, don’t start your service without adequately documenting the process to fulfill a DSAR
Having done your data inventory and mapping will be of a considerable aid here;
You’ll know how many and which data point you hold, on which legal ground.
Which right apply to which data point
For example, for all operation that implies an invoice, the reason you hold the data is a legal obligation.
So this data may not be available for erasure before the end of the retention period.
Which data is sent through to another data processor?
Who is the point of contact, responsible for this processing?
You should sort which one is most urgent.
Let list each one & see what’s implied.
A standard operation process template could be
1- a point of contact – which position should it be
You may even have this responsibility written in the job description.
So when onboarding or offboarding a new employee in this position, this part of the job is covered and well understood.
Make sure the contact info of the person is up to date.
2- How your customer can fill a Data Subject Access Request?
Through a third party? Through an online form? A button in the account? By calling customer support?
What should be the authentication process?
Is logging into its account is sufficient for all the data? Or do you need further proof of identity?
In that case, how are you going to handle it?
If you’re requesting a photo of your customer’s ID and need to store the proof, it should only be a low definition black and white picture.
3- Make sure your privacy notice / GDPR/ personal data web page is up to date and clearly inform people how they can exercise their rights
4 – In case of data access or data modification, in which form the data is to be made available?
Remember, we are not in the case of data portability.
Is an online page sufficient, with the ability to edit data points? Which data points are editable?
You may not want people to be able to change tags. This is a question worth being asked.
If you’re tracking behavior and segmenting people according to question you ask, what should be available for modification, and what should not?
4-1 – In case of erasure request, have a clear list of data points that cannot be erased for legal reasons.
And maybe start a pending task/worker to erase these data when the legal retention period is over.
5- Write down and test the queries to be made
Have clear instructions written down to make API calls to data processors. With any credential needed and safely stored.
It may be interesting to have the response format in csv, so it’s easier to copy paste the data you’re providing into a spreadsheet.
The case of data portability
In my opinion — in this particular case, as a Saas business— you should have an API endpoint at ready.
But no reason to expose it, or make it public.
Just have a bare minimum, tested, and documented so any customer support can make a call and provide its data to the customer
And above all, have a review process in place to make sure the endpoint evolves along with your product
This article will not talk about other edge cases:
processing objection/limitation
and right to not be subject to only automated profiling
Now you should have a clear view of the procedure needed to make sure you won’t be caught off guard should a DSAR land on your desk.
Learn the first easy steps to get started
Grab your 7 actionable steps cheatsheet