Data subject requests, and building for them early

How long do you actually have?

One month from receipt, extendable by a further two months where the request is complex or numerous, provided you tell the person inside the first month and explain why. Article 12(3) sets this out. The clock runs from receipt rather than from the point the request reaches the right team, which is why a request sent to a support inbox or an individual employee's address is a real risk.

There is normally no fee. You may charge a reasonable fee or refuse where a request is manifestly unfounded or excessive, and repetitive requests can attract a fee, but this is a narrow exception rather than a workload management tool. You can also ask for information to verify identity, and Article 12(6) lets you delay while you do, which is the only legitimate way to buy time.

Assume the first request will be adversarial. Access requests are a routine step in employment disputes and in consumer complaints, which means the first one you receive is likely to be scrutinised closely and followed by a complaint to a regulator if handled poorly.

Which rights do you need to support?

Six, and they have different scopes, which is the detail that trips up teams building a single generic pipeline. Access and erasure get the attention, but portability is narrower than access, objection is a switch rather than an export, and rectification frequently requires propagating a correction to systems that already copied the wrong value.

The differences below are worth encoding in the tooling. Treating all six as one workflow produces either over-disclosure or refusals you cannot justify.

What is the part that takes the time?

Finding the person, not exporting them. A request requires searching every store that holds their data, and the identifier differs between stores: an email address in the CRM, a numeric account id in the database, a hashed device identifier in analytics, a free text name in support tickets, a phone number in the telephony system. Joining those is a data engineering problem and it is the reason a request that should take an hour takes three weeks.

The second consumer is unstructured material. Support tickets, attachments, internal notes, chat messages and call recordings all contain personal data and none of it is queryable by identifier. Teams end up reading, which does not scale and is where the extension gets used.

This is why subject identity resolution is the first thing to build. A service that takes any known identifier and returns the full set of identifiers plus the stores implicated turns each request from an investigation into a lookup, and the same component is what lets you scope a breach and enforce a deletion.

What must you withhold, and what must you not?

You must not disclose personal data about other people where doing so would adversely affect their rights, which Article 15(4) makes explicit. In practice this means redacting names and identifying details of colleagues in internal notes, other customers in shared tickets, and anyone else who appears incidentally. It does not mean withholding the whole document because it is awkward, which is the more common overreach.

You are also entitled to hold back material covered by legal professional privilege and by exemptions in national law, which vary by jurisdiction and are the point at which counsel should be involved rather than an engineer. Where an exemption is applied, record which one and why, because that record is what a regulator reviews if the person complains.

What you must not do is limit the response to the tidy structured record. Internal notes, opinions recorded about the person and the reasoning behind an automated decision are all in scope, and a response that returns only a profile export while a manager's notes sit in a ticketing system is the classic under-disclosure. Assume the requester knows those notes exist.

What should you automate, and what should stay manual?

Automate discovery, collection and packaging. A pipeline that resolves identifiers, calls a defined export endpoint on each system, records what each returned including empty results, and assembles a single bundle removes almost all the elapsed time and produces an audit trail as a side effect.

Keep three steps human. Identity verification, because an access request is an effective route to someone else's data and impersonation is a real attack. Redaction review, because third party rights are a judgement. And the release itself, because once sent it cannot be recalled.

The pattern that works is a per-system export contract: every service that holds personal data implements the same two operations, export by subject and delete by subject, and registers itself. New services then inherit the obligation at build time instead of being discovered during a request. Making that a platform requirement is far cheaper than the alternative of a central team maintaining a list of who to email.

How do you test this before the first request?

Run one on a volunteer employee and time it. Ask a colleague to submit a real access request naming only their email address, then handle it exactly as you would for a stranger, and record where the hours went. Most teams find that two thirds of the effort went to two or three systems nobody expected, and that at least one store was missed entirely and surfaced only when someone remembered it.

Then run an erasure request against the same person in a non-production environment and check every store 24 hours later for their identifiers. Backups aside, anything that still returns a row is a gap in the deletion path, and the log platform and the analytics warehouse are the usual answers.

Repeat both after any significant architecture change. The value of the drill is not the result on the day but the register of implicated systems it produces, which is the most accurate data map most organisations will ever have.