How it works today in most organizations
The legal notice lists an address like "privacy@company.com". Behind it sits a shared mailbox that three or four people can access. Whatever arrives there is read and moved into the Outlook folder "Data subject requests". On a good day, someone also adds a row to a list with the name, the date of receipt and a status.
For the first few cases this works. Someone writes "Please send me all the data you have stored about me", a person on the team replies, and the matter is closed. It becomes difficult as soon as several requests run in parallel and each one has its own schedule.
The deadline starts earlier than everyone assumes
The one-month deadline under Art. 12(3) GDPR runs from receipt of the request – not from the day someone discovers it in the mailbox. An email that arrives on a Friday at 5 p.m., while the responsible person is away for two weeks, consumes half the deadline before any handling even begins. A shared mailbox has no concept of a deputy: a message is read or unread, but assigned to no one.
On top of that, by no means every request is a request for access. Erasure, rectification, restriction, data portability, objection and the withdrawal of consent are separate rights with separate consequences. Anyone who treats everything as an access request regularly answers something other than what was asked for.
Collecting the data turns into an email chain
Once it is clear what is being demanded, the collection begins. HR, CRM, accounting, marketing, support: every department receives an email asking them to "have a quick look". Answers come back as a screenshot, as running text, or not at all. Who has already delivered and who is still outstanding is known only to the person who started the chain – from memory.
Two points almost always remain unregulated. First, identity verification: the fact that proof was requested before disclosure sits at best in an email in the mailbox, not in the case. Second, the extension: for complex requests the deadline may be extended by two further months, but only if the data subject is informed within the first month and the delay is justified.
The moment it becomes obvious
This rarely shows up in day-to-day work, but in three situations: when a data subject complains to the supervisory authority, when a customer asks about the process during a vendor review, or when the responsible person leaves the organization. The question is then not "Did you reply?" but "When did the request arrive, when was it answered, how was identity verified, and what exactly was disclosed?" A mailbox has no reliable answer to any of these questions.
The analysis
Five problems the shared mailbox creates
They arise regardless of how carefully the mailbox is tended – they are properties of the tool, not of the person.
View data subject requests in preecoThe deadline runs before anyone looks
What counts is receipt, not awareness. Vacation, illness or a full mailbox consume part of the one-month deadline without anyone noticing. The delay is spotted only when there is hardly any time left.
Identity verification is not documented
Before any disclosure it has to be clear who is asking. If the proof is requested by email alone, neither the time of the request nor its outcome can be evidenced later. In case of doubt, the word of one person stands against an empty mailbox.
Collecting the data hangs on an email chain
Five departments, five open emails, no shared status. Whoever does not reply is noticed only when the deadline is already tight – and nobody knows for certain whether every system was actually queried.
Extension without justification or notice
Two additional months are permitted, but only with notice to the data subject within the first month and with a justification. Without a fixed process step, the deadline is in practice missed rather than formally extended.
In the end the evidence is missing
When did the request arrive, what was disclosed, who contributed? Scattered emails and a folder are not evidence. In the event of a complaint, exactly this reconstruction is the real work.
The target process in six steps
A dependable workflow differs from the mailbox not by more effort, but by fixed points at which something is recorded in a binding way. These six steps describe it – regardless of the tool you work with.
1. Record the receipt as a case. Every request is created as a case of its own: with the date of receipt, the requesting person and the channel used. So that the process does not hang on the mailbox, a web form on the website or in the intranet can route the request straight into the case. Freely definable recipients are notified of the receipt, so the start does not depend on a single person.
2. Determine the type of request. Access, rectification, erasure, restriction, data portability, objection, withdrawal of consent: the classification decides what has to be done and what is ultimately disclosed. It belongs at the beginning of the case, not in the last week of the deadline.
3. Verify identity with documentation. The proof is requested, the time of the request is recorded, and so is the outcome. If no proof arrives, that is a documented ground for refusal – as are manifestly unfounded or excessive requests. Both belong in the case, not in an email thread.
4. Hand subtasks to the departments. Instead of an email chain, each department gets a task with a responsible person and a due date of its own. Linking the case to the affected processing activities shows which data processing systems and data fields can be involved at all – which turns "Whom do we have to ask?" into an answerable question.
5. Track the deadline visibly. The one-month deadline is monitored automatically from receipt; cases that are due or overdue appear on the dashboard and trigger notifications. If an extension is necessary, it is treated as a step of its own: justify it, inform the data subject within the first month, note it in the case.
6. Answer and close. The reply goes out by email directly from the system, and quick text blocks cover recurring wording. All processing steps end up in the activity log, and the case can be exported as PDF or DOCX.
Why identity verification is the most delicate step
It collides with itself: verify too little and you may disclose personal data to the wrong person. Demand too much – a copy of an ID card, say, even though the person has been writing under the same customer number for years – and you collect additional data and delay the handling. Both can only be resolved with a fixed rule that defines in advance when which proof is required.
What matters, therefore, is less the strictness of the check than its documentation: what was requested when, what was presented, who decided. Precisely these three details are regularly missing from the mailbox process – and precisely these are demanded in the event of a complaint.
Before and after in direct comparison
| Criterion | Before: shared mailbox | After: structured case |
|---|---|---|
| Start of the deadline | Begins when it is read, not on receipt | Date of receipt per case, deadline runs from receipt |
| Visibility | Read or unread, nothing else | Status, responsibility and remaining time on the dashboard |
| Identity verification | Somewhere in the email thread | Request, timing and outcome documented |
| Types of request | Everything is treated as an access request | Access, erasure, rectification and objection kept separate |
| Collaboration | Open emails to five departments | Tasks with responsibility, due date and progress |
| Extension | Falls through the cracks | A step of its own with justification and notice |
| Evidence | Reconstruction from mailbox and folder | Activity log and export per case |
| Continuity risk | Vacation or a change of staff stops the handling | A deputy takes over the running case |
In practice
What this looks like in preeco | data protection
The three building blocks that carry the process described above.
Data subject requests and deadlines
All types of request from access to objection, documented identity verification including the time the proof was requested, recorded grounds for refusal, automatic monitoring of the one-month deadline under Art. 12(3) GDPR, and web forms for website and intranet.
Tasks for the departments
Tasks can be created, assigned and prioritized directly from a data subject request. The people responsible are notified by email, comment in the case and update the progress.
Evidence and reporting
The activity log documents every processing step with a timestamp and user. Status reports, compliance metrics and notifications about deadlines coming due keep the current state verifiable at any time.
What the switch means in practice
The effort does not lie in the technology but in two decisions that are due anyway: who decides on identity verification, and who supplies data from which system? Once those two questions have been answered, the rest is routine – every further request follows the same path instead of being organized from scratch.
It makes sense to start with the next real case rather than with a concept. The first request that runs completely in the system shows more reliably than any process description which department delivers quickly, which system was overlooked, and how much of the one-month deadline actually goes into collecting the data.
The number of requests rarely puts the effort into perspective the way people expect, either. Many organizations handle only a handful of cases a year – and that is exactly why the procedure is new every time. In this constellation a defined process saves less handling time than start-up time: nobody has to remember how it went last time.
Three mistakes that make the new process needlessly hard
Letting the shared mailbox run on in parallel. Two intake channels mean two versions of the truth about when the deadline started. The address from the legal notice should lead into the case, not alongside it.
Mapping only the access request. Requests for erasure, rectification and objection arrive less often, but they do arrive. If they are not kept as separate types of request from the start, they end up being handled as a special case by email again later.
Involving the departments only when it is urgent. Anyone who clarifies which system holds which data only at the first request loses exactly the days that are missing at the end. Mapping the processing activity, the system and the responsible person to each other belongs done beforehand.
How to tell that it is time
A shared mailbox is not a mistake. It becomes a risk as soon as at least one of these points applies:
- For any given request, you cannot say straight away when it arrived.
- Handling stalls during vacation or illness.
- Identity verification is established practice, but documented nowhere.
- More than two departments have to contribute to one access request.
- You have already missed a deadline once without formally extending it.
If none of this applies, the mailbox is enough. If two or more apply, it is already working against the deadline.
FAQ
Frequently asked questions about data subject requests
One month. Under Art. 12(3) GDPR the data subject has to be informed without undue delay and in any event within one month of receipt of the request. What counts is receipt – not the day someone notices the request in the mailbox. That is precisely why a documented date of receipt is the first step of the process.
Yes, under conditions. For complex requests or a high number of requests, the deadline may be extended by two further months. The data subject must, however, be informed of this within the first month, and the delay has to be justified. There is no tacit extension.
Where there are reasonable doubts about identity, additional information may be requested. The check should remain proportionate: a copy of an ID card is not the standard case but the exception. More important than the strictness is the documentation – what was requested when, and with what outcome. In preeco | data protection the identity verification including the time the proof was requested is recorded in the case.
Yes. Alongside access, the rights of data subjects include rectification, erasure, restriction of processing, data portability, objection and the withdrawal of consent. They are subject to the same deadline but lead to different processing steps. That is why the type of request is kept as an attribute of its own in preeco | data protection.
Through a complete history of the case. All processing steps are logged automatically with a timestamp and user, and comments and file attachments stay with the case. The complete case can be exported as PDF or DOCX and is therefore usable directly towards the supervisory authority or in the context of a vendor review.
Go through your request process together with us
Bring a typical case with you. In 30 minutes we will show you where the deadline is lost and how the case runs instead.