gdpria.eu

What documents do you need for a data subject access or deletion request?

An overview of the documents you need to properly handle a data subject access or deletion request, with special attention to the identification issue that most often goes wrong in this context.

What documents do you need for a data subject access or deletion request?

When someone asks you for access to their data, or for deletion of that data, you need a number of documents to handle that request properly: a receipt confirmation with date, a way to verify the identity of the requester, an overview of what you actually process about that person, a written decision with reasoning, and if necessary, a notice in which you extend the deadline. Together, these documents form the file with which you can show what was requested and what you did with it.

The part that creates the most uncertainty is not the list itself but the identity verification. Asking too few questions is a risk because you might then provide data to the wrong person; asking too many questions is also a risk, because the GDPR specifically asks not to request more data than necessary to verify identity. A complete copy of an identity document is usually not needed for this and moreover introduces new data that you must then secure and destroy in a timely manner.

Verifying identity without over-requesting

In practice, it often works with data you already have: a customer number, a previously known email address, or a brief callback verification. Only if there is doubt about who is making the request does additional verification make sense. The Dutch Data Protection Authority and the EDPB guidelines explicitly address this, precisely because this is the point where organisations most often overcompensate. A fixed procedure for identity verification, which you establish once and then repeat, prevents you from having to reinvent this each time.

What else belongs in the file

In addition to identity verification, the file should include an overview of the data itself that is processed: where it comes from, with whom it is shared, and how long you have had it. In practice, you retrieve this overview from your records of processing activities, if that is in order. Without a register, you must manually look this up in your systems for each request, which takes more time and increases the chance of an incomplete answer. In the knowledge base you will find explained per situation what a complete answer entails.

With a deletion request, an additional document is added: the assessment of whether there is a legal retention obligation that prevents deletion (temporarily), for example with tax data. You document this assessment in writing, even if the outcome is that you do not delete (fully). This document is just as important as the deletion itself, because it shows that a deliberate choice was made and not a forgotten request.

Why this is linked to your register and your tools

A data subject access or deletion request rarely affects just one system. Customer data is often stored in a CRM, an accounting package and an email program at the same time, and with each one the question arises whether and how long deletion is possible. If you map out in advance which SaaS tools contain which data, you don't have to discover this anew for each request. Whether your settings align with what the regulation requires, you can check via the guidance on privacy and data security.

The decision itself is also a document: a short letter or email stating what was requested, what you did, and within what timeframe. That timeframe is set in the regulation and runs from the moment of receipt, not from the moment you get around to it. An overview of frequently asked questions about these timeframes and exceptions can be found in frequently asked questions about data subject requests.

Recording pays off, even after handling

The file you build when handling a request is not only for that single moment. It also shows, should a supervisory authority or the data subject themselves ask about it later, that the request was recognized, assessed, and handled within the set deadline. Whether your current practice already covers this is something you can best discuss with a legal advisor or with the Dutch Authority for Data Protection if you have doubts about a specific situation.

Would you like to see in a few minutes how this works concretely for your business, without having to figure everything out yourself first? Take the free quick-scan or start a business account to keep your register and requests organized.

This article is general information and not legal advice.