The most common mistake when handling a data subject request lies not in the deadline by which you respond, but in the content of your answer. Businesses often either return too little data in response to an access request, or delete data in response to a deletion request that they were actually required to keep. Both mistakes occur because the request is treated as a single simple action, when in fact a number of questions must first be answered.
The core of the mistake is this: a request for access or deletion requires an assessment for each piece of data, not a button that you press. If someone deletes an entire personnel file because a former employee asks them to, they may well delete data that must be retained on the basis of another legal obligation, such as tax or employment law retention periods. If someone sends only an export from a single system in response to an access request, they often miss data that exists elsewhere, for example in a separate Excel file or in a manager's mailbox.
Why this mistake occurs so often
The GDPR grants data subjects the right of access and, subject to conditions, the right to erasure. Both rights are not unlimited. The right to erasure does not apply, for example, when there is a legal retention obligation, or when the data is needed to establish, exercise or defend a legal claim. This distinction is not contained in a simple checklist, and that makes it difficult for someone handling this for the first time.
A second reason is that data in an average SME is scattered: in the CRM, in the accounts, in email, sometimes in a chat app. A request is often answered from a single system, while the data subject has the right to a complete picture. That is precisely where a current processing register makes a difference: if you have already documented in advance which systems contain personal data and whose data, you do not have to figure that out under time pressure at the moment a request comes in.
The second mistake: not verifying identity
In addition to the substantive assessment, things often go wrong at the first step: determining who is making the request. A request for access or erasure often contains sensitive information, and that information should only reach the data subject themselves. Handling a request too quickly without verifying identity can result in one person's data reaching the wrong person. At the same time, an unnecessarily strict identity check delays the processing and can be perceived as a barrier that is out of proportion to the request.
How you can prevent this mistake
The first step is to properly record the request itself: what exactly is being asked, by whom, and on what date did it arrive. From that moment, the legal deadline starts running, and that deadline applies regardless of whether the request comes by email, phone or letter.
The second step is to determine which systems contain data for this person. A processing register that is up to date significantly speeds this up, because then you already know which tools and vendors process data of employees or customers. Anyone who does not yet have this centrally organized can knowledge base with explanations for different situations see what exactly should be in a register before a request arrives.
The third step is to assess for each piece of data whether erasure or disclosure is permitted, instead of dealing with the entire file at once. If you are in doubt about a legal retention obligation that stands against the request, it is advisable to seek legal advice on this; the supervisory authority mentions this distinction in her guidelines, but the outcome depends on the specific situation.
Finally, it helps to have a fixed process in place in advance for this type of request, so that you don't have to reinvent who is responsible for what each time. Answers to frequently asked questions on this subject are conveniently listed together in the collection of frequently asked questions, and those who want to see how gdpria.eu indicates the source of each answer can read that on the page explanation of how the information is compiled.
A well-maintained processing record and a fixed process do not prevent a request from arriving, but they do prevent it from going wrong under time pressure. If you prefer to arrange this structurally rather than working it out again on a case-by-case basis, you can explore a business account for free and in this way bring the overview per system and per request into order.
Are you curious what your own situation looks like? The free quick scan gives a first indication in a few questions, without requiring you to have an account for it.