- 20
- July
A Data Subject Access Request (DSAR) is the right under Section 30 of Thailand's Personal Data Protection Act (PDPA) that lets an individual ask to see and receive a copy of the personal data an organisation holds about them, and to be told where that data came from if they never consented to it. Thailand's Personal Data Protection Committee has now issued the first detailed rules for exercising that right: the notification was published in the Royal Gazette on 16 July 2026 and takes effect on 14 September 2026. This article sets out what the rules require, what processes and systems organisations need in place, and why any organisation whose data is scattered across departments is at real risk of missing the 30-day deadline.
In one line: From 14 September 2026, when someone asks to access or obtain a copy of their own personal data, a Thai organisation must complete the request within 30 days (extendable by up to another 30 days with notice and justification) and keep records of the whole process for at least two years.
What the new notification is, and why it arrived now
The right of access has existed since Section 30 of the PDPA came into force — the Act itself was published in 2019. But the statutory wording was deliberately broad: it said the data controller must act "without delay" and left everything else open. It did not spell out what form a request must take, whether an organisation could charge for copies, or on what grounds a request could be refused. In practice that meant every organisation interpreted the obligation differently.
The 2026 notification fills those gaps. It was published in the Royal Gazette, Volume 143, Special Part 175 Ngor, on 16 July 2026, and applies once 60 days have elapsed from publication — that is, 14 September 2026. Organisations therefore have roughly two months to prepare.
| Date | Event |
|---|---|
| 27 May 2019 | Personal Data Protection Act B.E. 2562 published in the Royal Gazette — Section 30 grants the right to access and obtain copies |
| 1 June 2022 | PDPA takes full effect after two postponements |
| 16 July 2026 | Notification on rules for access to and copies of personal data published in the Royal Gazette |
| 14 September 2026 | Notification takes effect (60 days after publication) |
What an organisation has to do when a request arrives
The notification lays out a sequence, from opening a channel for requests through to retaining evidence. The two clauses that deserve the closest reading are the minimum intake channels and the identity verification step, because both have to be designed in advance — they cannot be improvised once a request lands.
| Step | What the notification requires |
|---|---|
| 1. Intake channel | At minimum, requests must be accepted at the office or by post. Websites, applications and email may be offered in addition. |
| 2. Identity verification | The controller may request further identifying information, but the method must be reasonable and must not create an excessive barrier. |
| 3. Search and collate | Data must be gathered from every system the organisation is responsible for — not just one convenient system. |
| 4. Redact third parties | Anything that would affect the rights of a third party must be redacted before release. |
| 5. Deadline | Act without delay and complete within 30 days of receiving the request; extendable by up to a further 30 days where genuinely necessary, with notice to the requester. |
| 6. Retain evidence | Keep the request, supporting documents, actions taken and any refusal reasons for at least two years. |
Note on fees: delivering data electronically in a standard format must be free of charge. Fees are permitted only where a real and reasonable cost is incurred, and the notification caps them — for example, A4 paper copies at no more than 1 baht per page, computer-printed copies at no more than 3 baht per page, and certification of a copy at no more than 5 baht per certificate.
When a request can be refused
This is not an absolute right. The notification leaves room to refuse, but the room is narrow and every refusal must be recorded. A bare "we can't provide that" with no legal basis behind it is exactly where organisations will get into trouble.
| Permitted ground for refusal | What to watch out for |
|---|---|
| Refusal is required by law or by court order | You must be able to name the law or the order — a general appeal to "other legislation" will not hold up |
| Release would affect the rights and freedoms of others | In practice this is usually solved by redacting the affected parts rather than refusing the whole request |
| The data involves trade secrets or intellectual property | Redact only the confidential portion, not the entire dataset |
| The request is unclear or imposes an unreasonable burden | Go back to the requester to narrow the scope before relying on this ground |
Security warning: a subject access request is also an attack vector — a fraudster can impersonate a data subject in order to extract someone else's records. Identity verification is the step you cannot skip. At the same time, Section 82 of the PDPA provides that a data controller who fails to comply with Section 30 paragraph four (recording the refusal of a request) is liable to an administrative fine of up to 1,000,000 baht. The exposure runs in both directions: releasing data to the wrong person, and withholding it without a documented reason.
Why most organisations will miss the 30-day deadline
Thirty days sounds generous, but the bottleneck is not writing the reply — it is finding all the data. Count how many places one employee's personal data typically lives in a Thai organisation: the HR system, a payroll spreadsheet held by finance, a supplier-contact register in procurement, the fingerprint attendance system, CCTV footage, email attachments, and a paper file in a cabinet.
When data is scattered like that, answering a single request means walking round the departments one by one. It is the same underlying weakness that makes running critical business data in Excel so risky, and the same reason many organisations close their books late: there is no single trustworthy source. It is also why institutional knowledge walks out of the door when a long-serving staff member leaves — only they knew where things were kept.
| State of your data | Time to answer one request | Main risk |
|---|---|---|
| Scattered in departmental files, no central register | Unpredictable — depends who is available | Incomplete answers, missed deadlines, no way to prove afterwards what was sent |
| Partly centralised, parallel spreadsheets still in use | Days to weeks | System and spreadsheet disagree; the requester disputes what you sent |
| Core data in one database, with access control and an audit trail | Hours to a day to locate | Only review and third-party redaction remain |
A checklist for the next two months
What matters between now and 14 September is not buying new software. It is being able to answer one question: what personal data does this organisation hold, about whom, and where? That is the same exercise as the Record of Processing Activities (RoPA) the PDPA already requires.
- Map your data — list every system holding personal data, who owns it, and how data can be extracted from it.
- Publish your intake channels — at minimum an office address and postal address, stated in the privacy notice on your website.
- Write down the identity check — which documents you will ask for, who reviews them, and how the review is evidenced.
- Start a request register with a clock — date received, 30-day due date, current status, so nothing quietly runs over.
- Run one live rehearsal — pick a real employee, simulate the request, and time how long full collation takes. That number is the honest measure of readiness.
An overlooked benefit: organisations that complete the data map for this purpose get repeat value from it — breach notification within the statutory window, faster responses to internal audit, and a more realistic disaster recovery plan. All three depend on the same answer: where does the important data actually live?
How far an ERP system helps — and where it stops
To be straightforward about it: an ERP is not a PDPA request-management platform, and there is no ready-made "answer this DSAR" button. What an ERP does is shrink the underlying problem. When employee, supplier, receivable and payable records live in one central database rather than in departmental files, the question "what do we hold about this person?" becomes a search in one place instead of a tour of the building.
Saeree ERP keeps core records in a single PostgreSQL database, with per-menu user permissions, the ability to set a user to inactive, and valid from–to dates on accounts — all managed by the organisation's own administrator. Every change carries a record of who edited what and when. That trail is needed both when collating a response and when demonstrating to an auditor that access to personal data really is controlled.
Deployment choice matters here too. Organisations that must explain to a regulator exactly where personal data resides often choose an on-premise installation in their own data centre — the trade-offs are covered in On-Premise or Cloud: which to choose. On the access side, Saeree ERP supports two-factor authentication (2FA) to reduce the risk of account takeover, the same risk behind large-scale data breaches in Thailand and a recurring theme in the Thai cybersecurity picture.
Where the boundary sits: an ERP makes the data findable. Deciding what to release, what to redact and on what ground to refuse remains the job of the Data Protection Officer and the legal team. No system should be making that call for you.
Conclusion
The 2026 notification does not create a new right — Section 30 has been on the books since 2019. What changes is precision. Where the Act said only "without delay", there is now a 30-day clock, a cap on fees, an enumerated list of grounds for refusal, and a two-year record-keeping duty.
That precision is good news for organisations that have prepared, and a real exposure for those that still cannot say whose data they hold or where it sits. The time remaining before 14 September 2026 is enough to complete a data map and rehearse one request end to end — the two actions with the highest return right now.
"A 30-day deadline does not measure how quickly you write letters. It measures how well you know your own data."
- The Saeree ERP team
References
- iT24Hrs — New PDPA rules: individuals may request copies of their personal data, organisations must respond within 30 days (July 2026, in Thai)
- Royal Gazette — Personal Data Protection Act B.E. 2562 (Sections 30 and 82)
- Royal Gazette — notification search (Volume 143, Special Part 175 Ngor)
- Office of the Personal Data Protection Committee (PDPC), Thailand
Information verified on 20 July 2026.
How many places does your organisation's data live in?
Talk to the Grand Linux Solution team about consolidating core records into one system, with proper access control and a full audit trail — free, no obligation.
Request a Free DemoTel 02-347-7730 | sale@grandlinux.com
