When a data subject asks for a copy of their personal data, the IT team's first question is where that person's data actually lives. This article covers the per-person data map, the identifier crosswalk, and what to ask external service providers.
An email arrives in the customer service inbox. The sender is a former customer who has not bought anything in years, and they are asking for a copy of all the personal data the organization holds about them. Customer service forwards it to the IT team, and the first question IT has to answer is not how to export a file. It is where this person's data is.
In an organization that has grown over several years, that question cannot be answered in one sentence. One customer's data may sit in the sales system, the invoicing system, the email marketing tool, the complaints desk, a team spreadsheet, and a forgotten copy in a test environment. We write this as the team that has to design systems so that the question can be answered, and it is not legal advice. We will explain what a per-person data map is, what belongs in it, and why it is worth building before the first request arrives. Your organization's actual obligations under the law should be confirmed by whoever is responsible for personal data protection, or by legal counsel.
What the new rule on access requests covers, and how far we have read
Thailand's Personal Data Protection Act B.E. 2562 (PDPA) gives data subjects the right to request access to their personal data and a copy of it. The right itself is not new. What has changed, according to reports from several law firms, is that the Personal Data Protection Committee (PDPC) issued a notification in July 2026 setting out how the right is exercised in practice: how requests are received, how identity is verified, response timing, fees, grounds for refusal, and record keeping (see for example the report by Tilleke & Gibbins).
We should be plain that we have not read the full text of the notification. The Royal Gazette website sits behind a Cloudflare challenge that we do not work around, and the PDPC's own page does not carry the text. The secondary sources we could open disagree on some details, especially the effective date and the length of each step. For that reason this article gives no timing figures at all. If your organization needs them, read the notification in the Royal Gazette directly or ask whoever is responsible for personal data protection.
What we can write without those figures is the systems question every organization has to answer whatever the timing turns out to be: where does one person's data live, how can it be found, and in what format can it be exported?
Where one person's data is scattered
When we walk through an organization's systems one by one, a person's personal data tends to sit in the places below. Some of them are not on anyone's mind when the first request comes in.
Core systems in daily use, such as membership, sales and accounting systems. These usually have a clear owner and can be searched.
External service providers' tools, such as email sending, a customer support desk or product analytics. The data lives in their system, but your business chose to send it there.
Files that team members keep themselves: customer list spreadsheets, exports made for a report, email attachments. All of these sit outside any system's control.
Copies and backups, including databases in test environments and the backups of those environments. We wrote about this separately in our article on real data in test environments.
Logs and traffic data that carry user IDs, IP addresses or values that identify a person directly or indirectly. Keeping the mapping between IDs and people in a more tightly controlled place is covered in our article on log retention.
IT already knows about some of these places. Others are known only to someone else, for example a marketing team that signed up for a new tool on a department credit card. The problem is not that anyone did something wrong. It is that nobody holds the whole list in one place.
What a per-person data map is
A per-person data map is a single document that answers: if there is a request about one individual, where do we need to look, what do we search with, and how do we pull the data out? We do not treat it as a legal document. It is an operating manual for the IT team, something a person who has never worked on a given system can read and follow.
For each system or data source, we record at least five things.
The name of the system and the person who owns it
The categories of personal data held in it
The identifier used to search, such as email, phone number or customer ID
How one person's data can be pulled out, and in what format
Where that data is passed on to, in people or in systems
Secondary sources we read report that the records of processing activities under Section 39 of the PDPA are the basis for responding to a request, which fits how we think about it. If your organization already keeps such records, use them as the starting point for the map, then add what the actual search work needs: how to search, how to export, and who can do it. We have not read Section 39 itself, so we do not conclude whether the records your organization holds are complete as the law requires. Have whoever is responsible for personal data protection check that.
The hidden problem is the missing common identifier
If every system used the same customer ID, searching would be easy. In practice the sales system may key on email, the accounting system on a tax ID, and the marketing tool on an email address spelled slightly differently. Some systems hold only a phone number. One person ends up with several identifiers and nobody has matched them all.
Our approach is an identifier crosswalk: a table that says which identifier a person has in which system. The table is itself personal data, and a powerful one, because it links an identity across every system. We therefore keep it in a more tightly controlled place than ordinary systems, log who opens it, and keep it out of sight of teams working with test data or logs. It follows the same principle as the mapping table we described in the log article.
The limit to know about is that the crosswalk is only as complete as the data the systems give it. If a customer signs up for one tool with a personal email and buys through another channel with a work email, nothing will show they are the same person. Verifying that the requester really is the data subject is a separate matter, and it belongs to the organization's identity verification process, not to this table.
Which systems can search and export by person
When we go through each system asking whether it can search by individual, the answers fall into three broad groups.
The first group is systems that already have search and export functions, which can be used once the procedure is written down. The second is systems where a developer or database administrator has to write a query. That works, but it needs someone who understands the table structure and has access. We usually recommend preparing the query or script in advance and testing it against dummy data. The third is systems owned by an external provider, where all you can ask is whether they offer an export function to their customers and how long it takes. The answer for this group has to come from the provider, not from guessing off a sales brochure.
The export format deserves thought too. Data that opens in ordinary software, such as table files or standard structured files, can be read by the requester and by your team alike. Data that needs the old system's own software to open is a problem we often meet when an old system is replaced. This connects to what we wrote in our article on validation and cutover.
External providers belong on your map
A system where an external provider holds data on your behalf still belongs on the map, because the data your organization sent there is still data your organization may have to answer for when a request arrives. Handing data to someone else's system does not make the request go away. The legal role of each provider is something whoever is responsible for personal data protection has to assess case by case, and we do not rule on it.
What IT can do is ask the provider three things before signing or renewing: can you export one person's data, in what format, and where does the data sit once the contract ends. We wrote about the same idea in our article on conditions to put in a TOR, and about providers who may not be around in year three in our article on the risk that a vendor disappears.
When the search results include other people's data
Searching by name or email usually returns more than you want. One file can hold data on several people, and a support ticket can mention two customers in the same thread. Secondary sources report that the new notification sets out cases in which disclosure may be refused or limited when it would affect other people's rights, but we have not read the text, so we do not say what to do in each case.
From the systems side, we recommend that a person always review the results before anything is exported, and that the system or script that pulls the data separates items that belong directly to the requester from items where other people's data is mixed in, so that the reviewer can decide more easily. Deciding what to disclose belongs to whoever is responsible for personal data protection and to legal, not to a script.
The limits we should state plainly
If your organization has only one system that holds personal data, one person looking after it, and nobody has ever asked for their data, a full data map may be more than you need. One sheet of paper that says where the data is, who can reach it and how to pull it out is a fair place to start, because a document larger than the job becomes one nobody updates, and an out-of-date document is worse than none, since people trust it.
The other thing we want to say is that a data map does not prove a search was complete. Data in files nobody recorded, in private chats or on paper will not be on the map. What a map can do is make the part you know about searchable in a systematic way, and turn the part you do not know about into a visible gap to close rather than a hidden risk.
An objection we often hear
The objection we hear most is that nobody has ever asked for their data, so why prepare. It is a fair question, and if no request has ever arrived, this should not outrank a system that has problems every week. But a data map is not only for answering access requests. If someone asks for their data to be deleted, or a data breach occurs, the first question is the same: where is the data?
Another objection is that the legal team or whoever is responsible for personal data protection already handles this. That is true, and it is how it should be. But that role can only decide on what IT tells them accurately. The data map is what IT hands over. IT knows what the systems can really do, and the data protection role knows what the law requires. The two need the same document on the table.
Where to start
List the systems that hold personal data, including external services, files people keep themselves, and copies in test environments. Ask each department what tools it uses, not only the IT team.
Name an owner for each source, as a person, not a department.
Try searching for one person across every system, using a made-up person or a staff member who agrees, and note where you get stuck.
Write down how to search and export for each system, so that someone who has never done it can follow it, and keep the queries or scripts where the team can reach them.
Send the map to whoever is responsible for personal data protection to review, with the list of gaps you could not close, and set a date to review it again.
Summary
If you take only one thing from this article, try searching for one person across every system your organization has, and note where you get stuck. The places where you get stuck are what has to be fixed before the first request arrives.
If your organization is still scoping the work and would like someone to talk through the problem first, you can reach Superdev at 088-983-9386 or [email protected]. Our office is in Bangkapi, Bangkok. There is no deadline, you do not need complete documents to start, and if it turns out the timing is not right to build a new system, we will say so plainly, because starting a project at the wrong time costs more than waiting one more quarter.
FAQ: Frequently Asked Questions about This Article
A collection of questions and answers to help you better understand the content of this article.
Tags: