Two versions of this request arrive and they are frequently confused. An individual exercising a right under the DPDP framework or GDPR asks for the personal data you hold about them. An enterprise customer leaving, or preparing to, asks for the data their organisation put into your product. Both are obligations, they have different scopes and formats, and a product that handles one badly usually handles both badly.
The individual request is the harder of the two because personal data is scattered by nature. The primary record is straightforward. What is not: entries in audit logs, support ticket history, email content in your CRM, session recordings, analytics events, error reports capturing request payloads, and rows in a data warehouse populated by a nightly job. Any of those containing an identifier is in scope, and a response that covers the application database while omitting six downstream systems is incomplete in a way the requester cannot see and a regulator can.
So the prerequisite is a map, and building it is the actual work. For every system in your estate, what personal data does it receive, keyed on what identifier, and how would you extract one person's records from it. Most teams doing this exercise for the first time find between three and six systems nobody had counted. Doing it once, and keeping it current as part of adding any new service, converts a two-week scramble into a query.
The enterprise export is more about completeness and format than discovery. What a departing customer needs is everything they created — records, documents, configuration, history — in a form another system could actually ingest. A CSV of the main table is not that. A structured export with referential integrity, documented, including uploaded files and the relationships between objects, is. And it should be self-service rather than a support request, because a customer who has to ask you for their own data forms an opinion about lock-in that they share with others.
Build both as product features rather than as manual procedures. A manual export is performed by whoever is available, differently each time, with no record of what was included, and it will eventually miss something or over-disclose. An automated export runs the same way every time, logs what it produced, and can be verified. Under a regulatory timeline it is also the only version that reliably completes on schedule.
One caution about over-disclosure, which is the failure nobody anticipates. An individual's export must contain their data and not somebody else's, and that is harder than it sounds in any product with shared objects — a support ticket mentioning two customers, an audit log entry naming an administrator and a subject, a document uploaded by one person about another. Deciding those boundary cases in advance, in writing, is better than deciding them under a thirty-day clock with a lawyer on the call.
