PDPA: New Section 30 Access Rules Put Data Subject Access Request Operations on a Compliance Clock

The Personal Data Protection Committee (PDPC) has issued a binding notification setting out detailed rules for data subjects exercising the right of access under section 30 of the Personal Data Protection Act B.E. 2562 (2019) (PDPA).

Published in the Royal Gazette on 16 July 2026, the Notification will take effect after the expiration of 60 days from publication. It should therefore be treated as an immediate implementation project rather than simply a regulatory development to monitor.

The importance of the Notification lies in its operational detail. Section 30 already gives data subjects the right to access and obtain copies of personal data concerning them that is under a controller’s responsibility, as well as to request disclosure of the source from which personal data was obtained without their consent. The new rules now specify how requests must be received, verified, assessed, fulfilled, refused, charged for, and recorded.

For controllers, this moves data subject access requests (DSARs) firmly from privacy-notice language into operational compliance.

Controllers Must Make Relevant Information Accessible:

The Notification requires controllers to make available information that enables data subjects to exercise the section 30 right. This includes personal data collected directly from the data subject, personal data collected from other sources, and information concerning the source or acquisition of personal data obtained without the data subject’s consent.

The controller must also make accessible relevant information that it is required to provide under section 23 of the PDPA and relevant items contained in the controller’s records of processing under section 39 that the data subject is entitled to access.

This requirement makes data inventory and data mapping particularly important. A controller cannot respond effectively to an access request if it does not know where an individual’s data is stored, how it was obtained, and which systems or service providers hold it.

Mandatory Request Channels:

The Notification does not leave request channels entirely to the controller’s discretion.

At a minimum, controllers must permit requests to be submitted:

in person at the controller’s place of business or another contact location notified to data subjects under section 23; and
by registered mail sent to that location.

Controllers may provide additional electronic or other channels. A data subject may exercise the right personally or through an authorized representative.

This is a significant implementation point. An organization that currently accepts DSARs only by email or through an online privacy portal should review whether its procedure accommodates the channels expressly required by the Notification.

Controllers should also determine how requests received at reception desks, branch offices, HR functions, customer-service centers, or by post will be recognized as section 30 requests and routed immediately to the responsible team.

Requests Must Contain Prescribed Information:

A request must be made in writing or electronically and must contain specified information and supporting evidence.

Among other things, the request must identify the data subject, specify the requested access or copy and, where relevant, disclosure of the source of personal data obtained without consent, provide sufficient details of the data requested, and carry the signature or electronic signature of the data subject or authorized representative.

The Notification also sets out identity-verification requirements.

Where a data subject submits a request in person, official identification may be required. Where a request is made by registered mail, certified copies of relevant identification documents may be required. The controller may use alternative verification methods, but those methods must not create an unreasonable obstacle to the exercise of the right. Controllers may also request additional information where necessary to establish identity, verify the request, or communicate with the data subject, including identifiers and contact information already known to the data subject.

The practical challenge is to strike the correct balance. Insufficient authentication can result in disclosure of personal data to the wrong person, while excessive authentication requirements may improperly obstruct the exercise of the right.

Representatives Require Proper Authority:

The Notification expressly addresses requests submitted through representatives. An authorized representative must provide a power of attorney identifying the matter for which authority has been given, with the required stamp duty and signatures, together with appropriate identification documentation for the relevant parties. Alternative verification methods may again be used, provided they do not create an unreasonable obstacle.

Controllers should therefore review their procedures for requests submitted by lawyers, family members, guardians, employee representatives, and other authorized persons. A generic assumption that an email from a representative is sufficient may no longer be appropriate.

A 15-Day Initial Review Stage:

One of the most important procedural features of the Notification is an initial review stage.

After receiving a request, the controller must examine the request details, supporting documents, and whether the requester is the data subject or a genuinely authorized representative. This review must be completed without delay and no later than 15 days from receipt of the request. If the request or supporting documents are incorrect or incomplete, or if the controller cannot verify the requester, the controller must notify the requester to correct the request or provide additional documents.

The controller must provide a period of not less than 10 days for the requester to correct the deficiency. For purposes of the subsequent process, the request is treated as received when the corrected request or complete supporting documentation has been received. If the requester does not correct the deficiency within the specified period, the request is treated as abandoned. The controller must notify the requester accordingly, although the data subject remains entitled to submit a new request.

This makes DSAR intake more than a logging exercise. Controllers should be able to distinguish between receipt of an initial request, completion of the verification process, requests for additional information, and the point from which the substantive response period runs.

The Substantive Response Period Is 30 Days:

Where the request is complete, the requester has been verified, and no ground for refusal applies, the controller must fulfill the request without delay and no later than 30 days from receipt of the request. The Notification allows an extension where the request concerns a large volume of information or where another necessity prevents the controller from completing the request within the ordinary period.

Importantly, the permitted extension is no more than an additional 30 days. The controller must inform the data subject or authorized representative of the necessity for the extension and the relevant details. This corrects an important point appearing in some descriptions of the new regime: the official Notification does not provide for a further 60-day extension. For implementation purposes, organizations should therefore build their DSAR workflow around a 30-day substantive response period, with only a limited additional 30-day period where the conditions for extension are satisfied.

How Access Can Be Provided:

The Notification permits several methods of fulfilling a request.

A controller may:

allow the data subject to inspect relevant personal data;
prepare and provide copies of documents containing the relevant personal data; or
provide access, copies, or source information electronically or in another format agreed between the controller and the data subject.

Where the data subject submits the request electronically and does not request another format, the controller must provide the response electronically where this can reasonably be done. Controllers should therefore consider not only whether data can be found, but also whether it can be extracted into a format that can safely and intelligibly be provided to the requester.

Refusal Grounds Are Now More Operationally Defined:

The Notification provides greater detail concerning circumstances in which a controller may refuse to comply with a request.

A request may be refused where compliance would be contrary to law or a court order. Refusal may also be permitted where compliance would adversely affect the legally protected rights and freedoms of another person. The Notification expressly refers to matters including another person’s personal data, official secrets, trade secrets, copyright, and other intellectual property rights.

A controller may also refuse a request that is manifestly unfounded or that would impose an unreasonable burden on the controller. However, third-party information does not automatically justify refusing the entire request.

Where disclosure would affect another person’s rights and freedoms, the controller must comply with the request to the extent reasonably possible after balancing the relevant rights and interests. The Notification expressly contemplates deletion, redaction, or other measures that prevent disclosure of information that would adversely affect the third party. This makes document review and redaction a core part of DSAR compliance.

Employee DSARs May Become Particularly Significant:

For HR functions, the new rules could have substantial practical consequences.

Employee personal data is rarely located in a single personnel file. It may be distributed across HR information systems, payroll platforms, performance evaluations, email, internal messaging systems, access-control records, CCTV, workplace monitoring tools, expense systems, disciplinary records, and documents held by external service providers.

A section 30 request may therefore require coordination between HR, legal, IT, information security, facilities, and other business functions. The 30-day substantive response period means that organizations should establish internal search and escalation procedures before requests are received, rather than attempting to construct the process after the clock has started.

AI Systems Should Be Included in DSAR Readiness Testing:

Organizations deploying AI should also consider whether personal data contained in or processed through AI systems can actually be identified and retrieved when a section 30 request is received.

Depending on the architecture, relevant personal data may exist in prompts, uploaded documents, user profiles, interaction histories, logs, retrieved contextual information, generated outputs linked to identifiable individuals, or data stores supporting an AI application.

The Notification does not create separate rules for AI. The practical point is that the same access obligation applies where relevant personal data is held within an AI-enabled environment. Accordingly, it is not sufficient for a privacy notice simply to state that data-subject rights are available. The technical architecture must allow the organization to operationalize those rights within the applicable timetable.

Processor and Vendor Cooperation Should Be Tested:

The Notification places the legal obligation to respond on the controller, but much of the relevant personal data may be held by processors or other service providers.

Controllers should therefore review processor and vendor agreements to determine whether they contain adequate obligations concerning:

assistance with data-subject requests;
data searches and retrieval;
response times;
provision of copies in usable formats;
identification of relevant systems and repositories;
preservation of data during the request process; and
assistance with deletion, redaction, or other measures needed to protect third-party information.

A processor that is contractually permitted to take several weeks simply to begin searching for data may make it difficult for the controller to comply with its own regulatory timetable.

Fees Are Permitted Only in Defined Circumstances

The Notification also contains detailed rules on fees.

Where access is provided electronically and the controller does not need to prepare data in a special medium or incur direct delivery costs, the controller must not charge a fee. Fees may be charged in other cases, but they must be reasonable and must not exceed actual costs. Certain copying charges are also subject to maximum rates specified in the annex to the Notification.

Where requests are repetitive, involve large volumes of information, or impose a greater-than-normal burden, the controller may charge a reasonable fee having regard to its costs. The controller may also limit the scope or method of compliance to the extent necessary, taking into account both the data subject’s rights and the burden involved.

The Notification further permits controllers to waive or reduce fees for low-income data subjects or in other appropriate circumstances. If a fee will be charged, the controller must notify the data subject before or when exercising the right to charge it. Controllers should therefore avoid adopting a standard DSAR fee without first determining whether charging is permitted in the particular circumstances.

Record-keeping Is Mandatory:

Controllers must maintain records of requests, supporting documentation, and the action taken or refusal to act on each request for at least two years for verification and evidentiary purposes. Those records may be kept electronically.

Where a request is refused, the controller must notify the data subject or representative of the refusal and the reasons, and the refusal and its basis must also be recorded in the controller’s records maintained under section 39 of the PDPA.

This makes a DSAR register or case-management system increasingly important. The record should allow the controller to reconstruct the lifecycle of the request, including receipt, identity verification, deficiencies, internal searches, processor involvement, redactions, extensions, fees, disclosure, refusal, and final closure.

What Controllers Should Do Before the Notification Takes Effect:

Controllers should use the remaining implementation period to test whether their existing DSAR procedure can comply with the new rules in practice.

Priority areas include:

request channels — ensuring that in-person and registered-mail requests can be received, recognized, and logged, in addition to any electronic channels;
identity verification — establishing proportionate procedures for verifying data subjects and representatives;
initial review — implementing the 15-day assessment process and procedures for curing incomplete requests;
internal routing — identifying responsible contacts in HR, IT, marketing, customer service, security, legal, and other relevant functions;
data discovery — determining how personal data can be located across email, HR, CRM, cloud services, CCTV, monitoring systems, archives, and other repositories;
processor cooperation — testing whether processors and vendors can retrieve relevant information quickly enough;
third-party information — establishing review and redaction procedures;
deadline controls — monitoring the 30-day response period and any justified additional 30-day extension;
response formats — determining how inspection, copies, and electronic access will be provided;
fees — ensuring that charges are imposed only where permitted and within the applicable limits;
refusals — developing a documented process for assessing refusal grounds and issuing required explanations; and
records — maintaining evidence of requests and their handling for at least two years.

A practical way to test readiness is to run a mock DSAR involving an employee or customer whose information is spread across several systems and at least one external processor. That exercise is likely to identify operational weaknesses more effectively than simply reviewing the wording of the organization’s privacy notice.

Key Takeaways:

The new Notification materially changes the operational expectations surrounding section 30 access requests.

Controllers will need more than a general statement in their privacy notices that data subjects have a right of access. They need an end-to-end process capable of receiving requests through the required channels, verifying identity and authority, identifying deficiencies within the initial review period, locating data across internal and external systems, protecting third-party rights, producing the requested information, managing statutory deadlines, documenting refusals, applying fee rules correctly, and preserving evidence of compliance.

Two timing points deserve particular attention: the controller must conduct the initial review without delay and within 15 days, while a valid request that proceeds to fulfillment must generally be completed within 30 days, subject to a justified extension of no more than an additional 30 days.

For organizations with mature DSAR procedures, the immediate task should be a gap analysis against the Notification. For organizations that have treated access rights primarily as privacy-notice language, a more substantial operational implementation project is required. The key compliance question is now straightforward: if a real section 30 request arrived today, could the organization authenticate the requester, find the relevant personal data across all relevant systems and processors, review it for third-party information, provide it in the required manner, and demonstrate that every step was completed within the prescribed timetable?

Author: Panisa Suwanmatajarn, Managing Partner.

Related Articles in the “PDPA Insights: Building Effective Privacy Governance” Series

Posted in

Legal Articles

News

PDPA: New Section 30 Access Rules Put Data Subject Access Request Operations on a Compliance Clock