Introduction
The management of requests from individuals exercising their data protection rights is a procedure by which individuals can exercise the rights granted to them under the General Data Protection Regulation (GDPR).
These rights include:
- The right of access
- the right of rectification
- The right to be forgotten
- The right to data portability
- The right to object
- The right not to be subject to an automated decision.
Data subjects may submit a request to exercise these rights to the data controller, which is required to respond to their request within one month. The request to exercise rights is therefore an important tool for guaranteeing the protection of individuals' privacy and personal data. This requires organisations to structure themselves in order to collect and process these requests effectively.
After implementing this process many times in organisations, we realised that it was much more complex to implement than it seemed. In fact, if you don't put in place good governance and the right tools, you run the risk of very quickly getting bogged down in problems of incorrectly processed requests, back-and-forth emails and lots of hidden costs, and even litigation.
On top of that, it's repetitive work that brings little or no value to the organisation, apart from perhaps a gain in confidence with the people concerned that shouldn't be underestimated! That's why it's so important to deal with the issue properly and minimise its hidden costs.
Effective management of a request requires a clear process to be put in place. Here is a diagram summarising the DSR management process in four steps:
1. Collection 📩
This first step involves collecting all requests to exercise rights from the data subjects.
Means of collection
This can be done via various channels such as email, an online form, chat, post or even verbally by telephone.
It is important to identify each request clearly and to ensure that the person who made the request is actually the person concerned. It is important to avoid all risks of identity theft, requests made in error, etc.
Which method should I choose?
| Means | Advantages | Disadvantages |
|---|---|---|
| Collection e-mail address (eg. [email protected]) | - Easy to set up - Effective if volume of requests is low - Identity of requestor is validated by e-mail address - Simplicity |
- More complex division of tasks Qualification of requests often insufficient - Hidden costs - Requires contacting the person concerned - A lot of spamming which will create noise - Proof is transferred by e-mail, It is therefore up to the client to ensure the security (and accommodation, if the volume is large) of the data. |
| Collection form combined with a privacy portal (Dastra) | -Less hidden costs - Clear process - Possible automations - Automated qualification - Automated validation of identity - Elimination of spamming - Secure transfer of proofs - Automatic archiving |
- A little more complex to set up (requires integration) |
| Telephone | - More direct - Effective for handling requests for access to basic live data |
- Risk of identity theft (must be combined with other means of verification) - Qualification of DSR request more complex to manage - Requires special tools to monitor user requests - Spamming - Impossible to transfer data that is too large or complex |
| Postal mail | - Reliable - Works without the applicant's e-mail address - More reassuring - Allows data to be sent physically (disks, USB stick).) |
- Many hidden costs - Requires tools to ensure traceability and archiving of requests - Does not allow the transmission of complex data |
You can of course diversify the means of collection within the same organisation. For example, provide an e-mail address for employees to collect data and a form on your website for your prospects and customers to collect data. The important thing is to centralise requests in a single system.
What information should I request?
For each request to exercise a right, it is important to ensure that you have the right information so that you can respond correctly in accordance with the rules imposed by the regulations.
The type of request: This information is essential if the request is to be properly classified. It is important to know whether the request is for deletion, opposition, access, information or portability.
Surname and first name: This information is needed to identify the person making the request and to ensure that it corresponds to the person whose data is recorded in the system. Depending on the type of request, this information may not be necessary. For example, in the case of the right to object to receiving canvassing by e-mail.
The e-mail address: The e-mail address is personal data that enables us to communicate with the person making the request and to provide them with the information requested. It is important to ensure that the e-mail address provided is valid. This e-mail address will be the preferred means of communicating with the person. It is also possible to do this by post in certain cases... But this may increase your costs.
Customer number or internal identifier: This information may be requested to help you quickly identify the person concerned if they are already a customer of your company or if they have an identifier within your organisation (membership number, for example). However, you should not rely solely on this information to identify the person. In particular, if you collect the information in a non-authenticated environment, this information will only be declarative.
The category of person concerned: This is the type of person making the request, perhaps a customer, a prospect, an employee, etc. The need for this field will of course depend on the scope of your department. This information is useful for identifying the scope of the data concerned by the request.
Additional information: It all depends on the context, but it can be useful to leave a free field where the user can give details of their request. Perhaps the customer's request concerns a particular service. Maybe they only need access to a specific part of their information and not all of it.
In some cases, if the request requires a large volume of data to be collected (e.g. from an archive), it may be considered complex. This can extend response times to 3 months.
To sum up, it is essential to collect personal data lawfully, transparently and in compliance with the principles of the GDPR. The data collected must be used only for the specified purpose, and data subjects must also be informed of their data protection rights. Indeed, the management of requests constitutes data processing as such.
2. Checking the identity and eligibility of the request 🔍
Before you plunge headlong into executing the request, it is important to check the identity of the individual who has made the request.
Here are a few reasons for this identity verification:
To protect the individual's personal data: The GDPR requires businesses and organisations to protect individuals' personal data. If an unauthorised third party gains access to an individual's personal data, this can have adverse consequences for their privacy, reputation and rights. Verifying identity ensures that the request actually comes from the person concerned, thereby avoiding any risk of unauthorised access to personal data.
Identity verification ensures that the person making the request is who they claim to be. This reduces the risk of fraud, identity theft and other criminal activities.
Comply with legal obligations: The GDPR requires companies and organisations to respond to individuals' requests to exercise their rights as quickly as possible, with a maximum deadline of one month. However, this deadline may be extended if verification of the individual's identity is necessary. If the individual's identity is not verified, companies and organisations run the risk of not complying with their legal obligations in terms of data protection imposed by the GDPR.
They are different ways to verify an individual's identity, for instance:
- Send an email with a validation link
- Send a code by sms
- Ask for proof of identity
- Check that the e-mail address exists in the company's database
This verification and the means used will depend very much on the request and the data in question. Simply objecting to being canvassed by e-mail is not as sensitive as requesting access to a medical file.
The means used must therefore be adapted to the sensitivity of the data requested, using a risk-based approach to the rights and freedoms of individuals.
3. Processing the request ⚙️
Once the request has been collected and qualified, it is time to process it. This is the most important and complex stage of the process. It may be necessary to ask the applicant for additional information to clarify the request.
The request must be processed as quickly as possible and in compliance with the legal requirements for the protection of personal data.
Map the data
To process a request efficiently, if your information system is complex and you have many tools, databases or physical data, it is strongly recommended that you carry out a personal data mapping exercise. This will enable you to easily find out where personal data is located in the system, who is responsible for the asset (data carrier) in question and how to carry out the request. Tools like Dastra make it easy for you to keep your data map, with a set of predefined templates for the most commonly used software!
The record of processing activities (ROPA) becomes very useful here for understanding how data is processed within your organisation and not overlooking data and uses.
Empower your teams
Put in place good governance for the management of your requests. For example, organise your data collection by division, with one person in charge of incoming requests. These managers will then be responsible for allocating tasks to the various parties involved in the request (for example, database managers (DBA), Chief Data Officer, developers, business line operational staff, etc.). One way of delegating tasks to operational staff is to carry out a RACI matrix at a meeting or workshop attended by all project stakeholders.
Effective governance is the key to success in dealing effectively with requests.
Gather evidence
During this execution phase, you will need to collect and centralise a body of evidence in response to the request.
In the case of access requests, the data format should be as clear as possible, giving preference to open and easily accessible formats: Excel, CSV, text document, images, etc.
In the case of deletion requests, in certain cases you may send screenshots or supporting documents proving that the data has been properly deleted from the service account.
For portability requests, slightly more advanced technical formats such as JSON or XML may be preferred, particularly if the data is to be transferred to another organisation that will need to consume the data.
In essence, this evidence contains personal data. It is essential that the storage of this evidence should be as secure as possible.
4. Communication with the data subject📨
Responses must be provided as soon as possible and in a form that is clear and understandable to the data subject. It is also important to respond to the request accurately and completely, providing all the information requested by the data subject. The preferred channel for this type of request is the e-mail box.
Don't forget that the communication must include not only the response to the request but also details of the processing of the data concerned. In fact, for each request for access to data, you must provide the essential information on the data processing (purposes, categories of data processed, recipients, retention periods, rights, transfers, etc.). This information is generally included in your privacy policy or in the information provided when the data is collected from individuals.
Retention periods for requests
Please note that if the data controller does not respond to a request to exercise a right, the data subjects may lodge a complaint with the supervisory authority and take legal action. This exposes the organisation to both scrutiny by the authority and a penalty. Hence the importance of keeping a record of all requests processed and documenting the processes.
Furthermore, the processing of requests constitutes the processing of personal data, which requires the data to be kept for the time necessary to complete the requests.
Regarding the length of time requests are kept:
The periods must be defined in terms of responsibility, in accordance with any statute of limitations. For example, the following retention periods may be recommended:
- 5 years from the end of the calendar year of your request.
- 1 year for the copy of your identity document, if requested.
- 6 years, if you exercise your right to object.
The retention of data must be carefully analysed. It is necessary to minimise the amount of data kept solely for the purpose of preserving evidence.
Depending on the sensitivity of the data and the processing, it may be necessary to retain more information. For example, the transmission of data from a medical file or extremely sensitive data may require the retention of more evidence than the deletion of a loyalty account from a retail chain. In all cases, this must be justified.
Conclusion
We have drawn the following conclusions from this analysis:
Many hidden costs
If you're not equipped with a request automation tool, you're going to find yourself very quickly overwhelmed by a complex process with a shared e-mail address system.
- Most companies today use shared e-mail addresses such as [email protected], privacy@...). This is a system that can work well with good governance and a low density of data to manage. But very quickly, if the volume of requests increases, you will realise that the hidden costs of a request will explode: numerous round trips between the parties involved, lack of traceability, centralisation of evidence in a drive, etc.
- Although it is no substitute for good internal organisation, a tool will help you to scale up and structure the process by centralising requests and their evidence and delegating responsibilities to users.
Here is an overview of the interface for managing a request to exercise rights in Dastra:
Automate!
With Dastra, you can automate the entire process from collection, identity validation, processing and even communication. Without going into over-engineering, you can set up a no-code collection form that will allow you to automatically check the identity of the requester while perfectly qualifying the request. A system will also allow you to automatically allocate requests to different database managers.
In this way, you can put the management of requests to exercise rights on automatic pilot. All this will save you time, allowing you to focus on your core business.
Want to go further?
- Have a look at our documentation on exercising rights
- Read the guide to implementing the automated request collection widget
- Request a demo with one of our experts