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

on August 17, 2026August 17, 2026 by pithayutr

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

PDPA: AI Is Not Replacing Privacy Law—It Is Changing How We Apply It

on August 5, 2026August 5, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: AI Is Not Replacing Privacy Law—It Is Changing How We Apply It

Artificial intelligence has rapidly become part of everyday business operations. Recommendation engines personalize online shopping experiences, chatbots answer customer enquiries, fraud detection systems identify suspicious transactions, recruitment platforms screen job applicants, and generative AI assists with customer service, marketing and document preparation.

As AI adoption accelerates, organizations frequently ask whether the Personal Data Protection Act (PDPA) contains special rules governing AI.

The answer is both simple and nuanced.

Thailand’s PDPA does not establish a standalone regulatory framework for artificial intelligence. Unlike some jurisdictions that have introduced AI-specific legislation, the PDPA remains technology neutral. The same legal principles governing all personal data processing—including lawfulness, purpose limitation, transparency, data minimization, security, and accountability—continue to apply regardless of whether personal data is processed manually or through sophisticated AI systems.

Nevertheless, the Personal Data Protection Committee’s (PDPC) recent consultation on marketing and direct marketing demonstrates that the regulator increasingly recognizes AI-assisted personalization, profiling, and automated decision-making as ordinary components of modern business operations rather than exceptional technologies. This signals an important evolution in regulatory expectations. The question is no longer whether AI falls within the scope of the PDPA. Instead, organizations should consider how existing privacy principles should operate when personal data is processed at unprecedented speed and scale.

AI changes the scale—not the legal principles:

One misconception is that AI requires an entirely new compliance framework.

In reality, the core legal questions remain familiar.

Why is personal data being processed?

Is there an appropriate legal basis?

Have individuals been informed?

Is the processing proportionate?

Are appropriate safeguards in place?

These questions existed before AI and remain the foundation of PDPA compliance.

What AI changes is the scale and complexity of those questions.

A marketing employee might manually analyze one hundred customer records to recommend products.

An AI system may analyze ten million records every day, continuously refining customer profiles and generating individualized recommendations without direct human intervention.

The legal principles remain the same.

The governance challenge becomes significantly greater.

Organizations should focus on the processing—not the technology:

Discussions about AI frequently focus on algorithms.

Privacy law focuses on personal data.

Organizations should therefore avoid beginning compliance discussions with technical questions such as:

“Are we using AI?”

Instead, they should ask:

“How is personal data being collected, analyzed, combined, retained and disclosed?”

This shift in perspective has practical consequences.

An AI system recommending products based upon purchasing history raises different privacy considerations from an AI system screening job applicants or detecting fraudulent transactions.

The technology may be identical.

The processing purposes are not.

Organizations should therefore evaluate each AI use case separately rather than adopting a single enterprise-wide conclusion regarding AI compliance.

Profiling is becoming an ordinary business activity:

One of the most significant aspects of the PDPC’s recent consultation is the inclusion of profiling alongside AI-assisted marketing and automated decision-making.

This reflects commercial reality.

Retailers profile customers to recommend products.

Banks profile spending behaviour to identify suitable financial services.

Hotels profile travel patterns.

Streaming platforms profile viewing preferences.

Insurance companies profile claims histories.

Profiling has become routine.

The regulatory focus is therefore shifting away from asking whether profiling exists toward examining whether organizations understand, govern and explain how profiling operates.

Transparency becomes particularly important where profiling materially influences commercial decisions affecting individuals.

Explainability is becoming a governance issue:

Many AI systems are capable of generating sophisticated outputs while providing limited insight into how those outputs were produced.

This creates a practical challenge.

Organizations may be able to explain what an AI system does without fully understanding why it reached a particular recommendation.

The PDPA does not require organizations to explain complex algorithms.

However, organizations should be capable of explaining much more fundamental issues.

What personal data does the AI system use?

Why is that information necessary?

What business objective does the system support?

Who reviews significant outputs?

What safeguards exist to identify inappropriate outcomes?

These governance questions are likely to become increasingly important as AI adoption expands.

Vendor governance is becoming AI governance:

Few organizations develop AI systems internally.

Most rely on external providers.

Large language models.

Cloud AI services.

Marketing automation platforms.

Customer relationship management systems.

Fraud detection software.

Human resources platforms.

Consequently, AI governance increasingly depends upon vendor governance.

Organizations should understand:

where personal data is processed;
whether overseas transfers occur;
whether providers use customer data to train models;
whether subcontractors process personal data;
how security is maintained;
how long information is retained.

Vendor due diligence therefore becomes an essential component of AI governance under the PDPA.

Human oversight still matters:

AI enables organizations to automate decisions at unprecedented scale.

Automation, however, should not eliminate accountability.

Organizations should identify situations where meaningful human review remains appropriate.

Examples may include:

rejecting employment applications;
detecting suspected fraud;
evaluating insurance claims;
determining customer eligibility for significant commercial benefits.

The appropriate level of oversight will depend upon the context and the potential impact on individuals.

Organizations should therefore design governance frameworks that ensure AI supports decision-making without entirely replacing human judgement where significant interests are involved.

AI governance is ultimately privacy governance:

Perhaps the most important lesson is that organizations should resist creating isolated AI compliance programs.

Instead, AI should be incorporated into existing privacy governance.

Records of Processing Activities should identify AI-supported processing.

Privacy notices should accurately describe AI-related processing where appropriate.

Legal basis assessments should consider AI processing explicitly.

Vendor management should address AI providers.

Privacy impact assessments should evaluate AI risks.

Training programs should include AI governance.

In other words, organizations should integrate AI into their existing accountability framework rather than building a separate compliance structure.

Looking ahead:

Artificial intelligence will continue to reshape business operations.

The more significant challenge under the PDPA, however, is unlikely to be the technology itself.

It will be governance.

Organizations capable of explaining why AI is used, what personal data supports it, how risks are managed, and how decisions remain accountable are likely to be better prepared than organizations focusing exclusively on technical innovation.

The PDPC’s recent consultation suggests that this is the direction in which Thailand’s privacy regime is evolving. AI is becoming an ordinary business tool. As a result, organizations should treat AI governance as an ordinary component of privacy governance.

Key takeaways:

The PDPA does not establish separate legal principles for AI; existing privacy obligations continue to apply regardless of the technology used.
AI increases the scale and complexity of personal data processing but does not replace the need for lawful basis, transparency, purpose limitation, and accountability.
Organizations should assess individual AI use cases rather than treating all AI deployments identically.
Profiling and AI-assisted decision-making are becoming mainstream regulatory concerns and should be supported by appropriate governance and transparency.
Vendor management is increasingly inseparable from AI governance because many AI capabilities are provided by third-party platforms.

The organizations best prepared for future regulation will be those that integrate AI into existing privacy governance rather than treating it as a separate compliance project.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPA: Data Breach Governance Is More Than a 72-Hour Deadline

on July 22, 2026July 22, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: Data Breach Governance Is More Than a 72-Hour Deadline

One of the best-known requirements under Thailand’s Personal Data Protection Act (PDPA) is the obligation to notify the Personal Data Protection Committee (PDPC) of certain personal data breaches without undue delay and, where required, within 72 hours.

As a result, many organizations approach breach preparedness primarily as a reporting exercise. Internal discussions often focus on when the 72-hour period begins, what information should be included in the notification, and whether affected individuals must also be informed.

These are important questions.

They are also the wrong place to begin.

The Personal Data Protection Committee’s recent consultation on security measures and personal data breach management suggests a broader regulatory perspective. Rather than treating breach notification as the central compliance obligation, the consultation emphasizes governance before, during and after a security incident. It discusses risk management, organizational measures, technical safeguards, incident response planning, documentation, and continuous improvement as integral components of compliance. The message is clear: a well-governed organization should be managing breach risk long before it considers whether a notification must be submitted.

A breach rarely begins with the breach:

Organizations often describe a breach as a discrete event.

An employee clicks a malicious link.

A laptop is stolen.

A cloud storage bucket is misconfigured.

A ransomware attack encrypts corporate systems.

Yet these events rarely occur in isolation.

Most data breaches reflect weaknesses that existed long before the incident itself. Poor access management, inadequate vendor oversight, outdated systems, excessive user privileges, insufficient employee training, and incomplete asset inventories frequently contribute to the eventual breach.

Consequently, organizations should regard breach management as an ongoing governance process rather than an emergency response exercise.

The most effective incident response plans are developed before they are needed.

Security is an organizational responsibility:

Information security is often viewed primarily as an IT issue.

The PDPA takes a broader approach.

Protecting personal data requires coordinated action across multiple business functions.

Senior management establishes governance.

Human resources develops training.

Procurement evaluates vendors.

Legal reviews contractual protections.

Business units determine what personal data is collected and why.

Information technology implements technical controls.

Each function contributes to reducing breach risk.

Organizations that treat cybersecurity as the sole responsibility of technical teams may overlook governance failures that contribute equally to privacy incidents.

Incident response plans should answer practical questions:

Many organizations maintain incident response policies that satisfy regulatory requirements but provide limited operational guidance.

An effective incident response plan should answer practical questions before an incident occurs.

Who investigates the incident?

Who determines whether personal data has been compromised?

Who decides whether notification is required?

Who communicates with regulators?

Who informs affected individuals?

Who preserves evidence?

Who approves public statements?

Who manages communications with vendors?

These decisions should not be made for the first time during a cybersecurity incident.

Clear governance significantly improves response quality while reducing confusion during high-pressure situations.

Vendors increasingly determine organizational resilience:

Modern organizations rarely process personal data entirely within their own infrastructure.

Cloud providers.

Payroll processors.

CRM vendors.

Marketing platforms.

AI providers.

Managed security services.

Software developers.

Each may process significant volumes of personal data on the organization’s behalf.

Consequently, incident preparedness increasingly depends upon vendor governance.

Organizations should understand how vendors detect incidents, when they notify customers, what contractual obligations apply, how investigations are coordinated, and whether subcontractors introduce additional risk.

Vendor due diligence should therefore extend beyond procurement and continue throughout the contractual relationship.

Documentation matters before regulators ask for it:

Organizations often focus on documenting the breach itself.

Increasingly, regulators may also expect organizations to demonstrate what preventive measures existed before the incident.

Could the organization explain:

why specific security measures were selected?
why particular risks were considered acceptable?
when systems were last reviewed?
whether employees received appropriate training?
whether incident response plans had been tested?
whether previous incidents had resulted in corrective action?

These questions reflect organizational accountability rather than incident reporting.

Good documentation demonstrates that the organization actively managed risk rather than merely reacting after an incident occurred.

Every breach should improve the organization:

The conclusion of an investigation should not mark the end of breach management.

Every incident provides an opportunity to improve governance.

Organizations should conduct post-incident reviews addressing not only technical causes but also organizational lessons.

Were responsibilities clearly allocated?

Did communication function effectively?

Were vendors responsive?

Did documentation prove sufficient?

Were customers informed appropriately?

Could similar incidents occur elsewhere within the organization?

Continuous improvement is one of the strongest indicators of a mature privacy governance program.

The future of breach management:

Cyber threats will continue to evolve.

Artificial intelligence will introduce new attack vectors.

Cloud ecosystems will become increasingly complex.

Third-party dependencies will continue expanding.

Against this background, organizations should avoid viewing the PDPA primarily as imposing notification obligations.

The broader challenge is establishing governance capable of identifying, managing and learning from security incidents before they become regulatory problems.

The organizations that respond most effectively to future breaches are unlikely to be those that simply notify within 72 hours.

They will be those that can demonstrate that security, governance and accountability existed long before the incident occurred.

Key takeaways:

Personal data breach management begins before a breach occurs through governance, risk management and organizational preparedness.
Effective breach response requires coordination among legal, IT, information security, procurement, human resources and senior management.
Incident response plans should allocate responsibilities and decision-making authority before an incident arises.
Vendor governance has become an essential component of breach preparedness because third-party providers increasingly process personal data on behalf of organizations.
Documentation of preventive measures and continuous improvement may become as important as the breach notification itself.
Organizations should view breach management as an ongoing governance process rather than a regulatory reporting obligation.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPA: PDPC Clarifies the Scope of “Health Data”

on July 20, 2026July 20, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: PDPC Clarifies the Scope of “Health Data”

The Personal Data Protection Committee (PDPC) has recently issued an advisory opinion addressing whether the appearance of the Thai Red Cross symbol and the wording indicating organ donor status on Thailand’s new driver’s license constitutes sensitive personal data under Section 26 of the Personal Data Protection Act B.E. 2562 (2019) (PDPA). While the factual question concerned organ donor status, the more significant legal development lies in the PDPC’s interpretation of what constitutes “health data” under the PDPA.

The issue arose following the Department of Land Transport’s introduction of a new driver’s license format that allows license holders who have registered their intention to donate organs with the Thai Red Cross Society to display the Thai Red Cross symbol together with a statement indicating organ donor status on the face of the license. A private-sector organization sought clarification from the PDPC regarding whether such information should be treated as sensitive personal data under Section 26 of the PDPA.

The PDPC’s Interpretation of Health Data:

Section 26 of the PDPA imposes enhanced protection requirements on certain categories of sensitive personal data, including data concerning health. However, the PDPA does not provide a specific definition of “health data”.

In considering the issue, the PDPC examined various legislative and regulatory sources relating to healthcare information. The Committee observed that information concerning healthcare services, healthcare-related intentions and the expression of wishes regarding organ donation have traditionally been regarded as information connected with an individual’s health and healthcare status.

The PDPC emphasized that the information displayed on the driver’s license is not merely a symbol or administrative notation. Rather, it reflects an individual’s expressed intention relating to organ donation and is intended to be used by medical personnel and relevant authorities in circumstances where healthcare services and organ transplantation procedures may become relevant. As a result, the information is intrinsically connected to healthcare services and medical treatment.

On that basis, the PDPC concluded that the status of being a registered organ donor, as displayed on a driver’s license, constitutes health-related personal data and therefore falls within the scope of Section 26 of the PDPA.

A Broader Understanding of Health Data:

The opinion provides an important indication of how the PDPC is likely to interpret health data in future cases.

Traditionally, organizations often associate health data with medical records, diagnoses, treatment histories, laboratory results or information concerning physical and mental conditions. The PDPC’s reasoning suggests that the concept is broader.

The Committee’s analysis indicates that information may qualify as health data even where it does not reveal a specific illness or medical condition. Information that reflects an individual’s healthcare-related intentions, healthcare choices or participation in healthcare-related activities may also fall within the scope of health data where such information is sufficiently connected to healthcare services or medical treatment.

This interpretation reinforces the need for organizations to assess the nature and purpose of information being processed rather than relying solely on traditional assumptions about what constitutes medical information.

Practical Implications:

Although the PDPC classified organ donor status as health data, the opinion also contains practical guidance for organizations that routinely collect copies of driver’s licenses.

The Committee recognized that where a data controller collects a copy of a driver’s license solely for identification or verification purposes and does not collect, use or disclose the organ donor information for the purpose of identifying an individual’s donor status or obtaining health-related information, such processing should not automatically be regarded as the collection of health data under Section 26 merely because the information incidentally appears on the document.

This aspect of the opinion will be particularly relevant to banks, financial institutions, insurers, employers, telecommunications providers and other organizations that regularly collect copies of official identification documents as part of their business operations.

At the same time, organisations that specifically collect, use or disclose information concerning donor status or other healthcare-related declarations should carefully assess whether Section 26 applies and whether an appropriate legal basis exists for the processing of such sensitive personal data.

Key Takeaways:

The PDPC has confirmed that organ donor status displayed on a driver’s license constitutes health-related personal data under Section 26 of the PDPA.
The opinion suggests that health data is not limited to medical records or information concerning diseases and medical conditions.
Information reflecting healthcare-related intentions, wishes or decisions may also constitute health data where it is closely connected to healthcare services or medical treatment.
Organizations should review whether information they process could reveal healthcare-related intentions or decisions, even where it does not contain traditional medical information.
The incidental collection of such information as part of a driver’s license copy does not necessarily mean that the organization is processing health data, provided the information is not used for health-related purposes.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPA: The PDPC Is Redefining Marketing Compliance

on July 17, 2026July 20, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: The PDPC Is Redefining Marketing Compliance

Marketing has evolved dramatically over the past decade, yet many organizations continue to approach compliance under Thailand’s Personal Data Protection Act (PDPA) as though marketing still begins with an email campaign or a promotional text message. In practice, modern marketing starts much earlier. Businesses routinely collect, combine and analyze personal data to understand customer behavior, predict purchasing decisions and personalize customer experiences long before any advertisement reaches its intended audience.

This transformation has gradually blurred the distinction between marketing, customer analytics and data governance. Customer relationship management (CRM) platforms, loyalty programs, online tracking technologies, behavioral advertising, recommendation engines and artificial intelligence (AI) have become ordinary components of commercial operations. Personal data is no longer used simply to communicate with customers; it is increasingly used to decide what products customers see, when they see them and how organizations engage with them.

Against this backdrop, the Personal Data Protection Committee (PDPC) has released a consultation draft on marketing and direct marketing. Although the consultation is not yet legally binding, it provides an important indication of how the regulator interprets marketing under the PDPA. Significantly, the consultation extends beyond traditional direct marketing to include digital marketing, cookies and tracking technologies, targeted advertising, profiling, AI-assisted personalization and automated decision-making. In doing so, it reflects a broader regulatory understanding of marketing itself.

For businesses, this matters because it changes the focus of compliance. The central issue is no longer simply whether an organization has obtained consent before sending promotional communications. Increasingly, the question is whether the organization can justify and govern every significant use of personal data throughout the marketing lifecycle.

Marketing now begins with customer insight:

Traditional marketing compliance focused primarily on communications. Organizations assessed whether they could lawfully send promotional emails, SMS messages or telephone calls.

The consultation suggests that this perspective is becoming too narrow.

Marketing increasingly begins with customer insight rather than customer communication. Organizations analyze website activity, purchasing history, mobile application usage and online interactions to understand customer preferences before deciding which advertisements to display or which products to recommend. By the time a customer receives a promotional message, multiple processing activities may already have taken place.

Recognizing this distinction is essential. Compliance should not be confined to the final communication but should extend to the collection, analysis and use of personal data that supports marketing decisions.

The same customer data may support very different purposes:

One of the most significant practical consequences of this broader perspective is that organizations should avoid treating all customer information as though it were processed for a single purpose.

Consider an online retailer. Purchase history may initially be processed to complete an order and arrange delivery. The same information may later be used to administer a loyalty program, identify customer purchasing patterns, recommend complementary products, measure campaign effectiveness and improve future marketing strategies.

Although the dataset remains the same, the purposes differ.

This distinction is important because the PDPA regulates the processing of personal data according to purpose rather than according to the dataset itself. Organizations should therefore identify each processing activity separately and ensure that the legal basis relied upon corresponds to the actual business objective.

This represents a more sophisticated approach than simply obtaining a broad marketing consent covering every future use of customer information.

Profiling has become an ordinary commercial activity:

Customer profiling is no longer limited to technology companies.

Retailers recommend products based on purchasing history. Airlines personalize travel offers. Financial institutions categorize customers according to spending behavior. Hotels tailor promotions using previous booking information. Streaming services continuously refine recommendations according to viewing habits.

These activities have become standard business practice.

The more relevant compliance question is therefore no longer whether profiling occurs but whether profiling is appropriately governed.

Organizations should understand what information is analyzed, how customer profiles are created, whether those profiles influence commercial decisions and how customers are informed about these practices. Transparency becomes particularly important where profiling extends beyond simple customer segmentation and begins influencing individualized offers or recommendations.

AI magnifies existing compliance obligations:

Artificial intelligence has transformed the scale of modern marketing.

Tasks previously performed by marketing teams can now be undertaken automatically through recommendation engines, predictive analytics and generative AI. Systems can analyze millions of customer interactions, identify purchasing patterns and personalize marketing campaigns with minimal human intervention.

Despite these technological developments, AI does not alter the core legal principles established by the PDPA.

Organizations remain responsible for identifying an appropriate legal basis, limiting processing to specified purposes, maintaining transparency and respecting data subject rights.

What AI changes is the scale at which those obligations must be managed.

Organizations should therefore integrate AI into existing privacy governance rather than treating AI compliance as a separate exercise. Effective governance requires understanding what personal data is processed, how AI systems generate recommendations and what oversight exists to monitor automated outcomes.

Cookie compliance is only the beginning:

Cookies have traditionally been regarded as a website compliance issue.

In reality, they often represent only the first stage of a much larger processing ecosystem.

Information collected through tracking technologies may subsequently be combined with CRM data, disclosed to advertising technology providers, incorporated into customer profiles, analyzed using AI and ultimately used to deliver targeted advertising across multiple platforms.

Organizations should therefore move beyond focusing exclusively on cookie banners. Compliance should encompass the downstream use of tracking information throughout the digital advertising ecosystem.

Governance—not consent—will define future compliance:

Perhaps the most significant message emerging from the PDPC’s consultation is that marketing compliance is becoming a governance issue.

Historically, organizations invested considerable effort in drafting consent forms and updating privacy notices. Those measures remain important, but they no longer provide a complete compliance framework.

Organizations should instead ask broader governance questions.

Can we explain why customer information is collected?

Can we justify each processing activity?

Do we understand how profiling influences marketing decisions?

Can we identify every external platform receiving customer information?

Are customer objections implemented consistently across all marketing systems?

Can these decisions be demonstrated through appropriate documentation?

These questions reflect accountability rather than procedure.

As marketing technologies continue to evolve, organizations capable of answering them convincingly are likely to be better positioned than those relying primarily upon consent as evidence of compliance.

Looking ahead:

The PDPC’s consultation represents more than a discussion of direct marketing. It reflects an evolving regulatory understanding of how personal data underpins modern marketing.

Organizations should therefore resist the temptation to treat the consultation as another checklist of compliance requirements. Its broader significance lies in demonstrating that regulatory attention is shifting from individual communications toward governance of the entire marketing ecosystem.

Businesses that recognize this shift early—and embed privacy considerations into customer analytics, profiling, AI deployment and digital advertising—will be better prepared not only for future regulatory developments but also for an increasingly data-driven commercial environment.

Key takeaways:

The PDPC’s consultation reflects an expanded understanding of marketing that extends beyond promotional communications to encompass customer analytics, digital advertising, profiling, AI-assisted personalization and automated decision-making.
Organizations should identify individual processing activities and their purposes rather than treating all marketing-related processing as a single activity.
Customer profiling has become an ordinary business practice and should be governed through transparency, accountability and appropriate internal controls.
AI increases the scale of personal data processing but does not replace the fundamental principles of the PDPA.
Marketing compliance is increasingly defined by governance of the entire marketing lifecycle rather than by obtaining consent alone.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPA: Legitimate Interest Is No Longer a Shortcut

on July 16, 2026July 20, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: Legitimate Interest Is No Longer a Shortcut

For many organizations implementing Thailand’s Personal Data Protection Act (PDPA), legitimate interest has become the preferred legal basis whenever obtaining consent appears impractical. Marketing activities, CCTV surveillance, fraud prevention, internal investigations, customer analytics, vendor due diligence, and employee monitoring are frequently justified on the basis that the organization has a legitimate business interest in processing personal data.

Yet legitimate interest is often misunderstood.

Some organizations treat it as a convenient alternative to consent, while others avoid relying on it altogether for fear that regulators may later disagree with their assessment. Both approaches overlook the purpose of legitimate interest within the PDPA.

The Personal Data Protection Committee’s recent consultation on legal bases provides an important indication of how the regulator expects organizations to approach legitimate interest. Rather than treating it as a residual category available whenever consent cannot be obtained, the consultation emphasizes a structured decision-making process requiring organizations to identify the processing purpose, assess necessity, balance competing interests, and document their reasoning. Although the consultation remains subject to revision, it reflects a broader movement toward accountability-based compliance rather than checklist compliance.

Legitimate interest is a legal analysis—not a business preference:

One of the most common misconceptions is that organizations may choose whichever legal basis they prefer.

The PDPA does not permit such flexibility.

Instead, the legal basis should reflect the actual purpose of the processing activity. Organizations should therefore begin by asking why the processing is taking place before considering whether legitimate interest is available.

For example, processing customer contact details to deliver purchased goods differs fundamentally from processing the same information to analyze purchasing behavior for future marketing campaigns. Likewise, operating CCTV to protect premises serves a different purpose from monitoring employee productivity.

Each processing activity should therefore be assessed independently.

Legitimate interest becomes relevant only after organizations have clearly identified the processing purpose and determined that no more appropriate legal basis applies.

Legitimate interest requires necessity:

The consultation suggests that organizations should demonstrate that the processing is genuinely necessary to achieve the identified purpose rather than merely convenient.

Necessity does not require the organization to prove that no alternative exists. However, it should be able to explain why the processing contributes meaningfully to the legitimate objective and why less intrusive alternatives would not achieve substantially the same result.

For example, a shopping mall operating CCTV in public areas for security purposes may reasonably conclude that surveillance is necessary to deter crime and investigate incidents. By contrast, continuous monitoring of employees in low-risk office environments may require a much more persuasive justification.

Organizations should therefore avoid assuming that every commercially useful processing activity automatically satisfies the necessity requirement.

Balancing interests requires more than common sense:

Perhaps the most significant aspect of legitimate interest is the balancing exercise.

Organizations should evaluate not only their own commercial interests but also the likely impact on individuals.

Relevant considerations may include:

the nature of the personal data;
the reasonable expectations of the individuals concerned;
the relationship between the organization and the individual;
the potential consequences of the processing;
whether adequate safeguards have been implemented; and
whether individuals can reasonably object to the processing.

This balancing exercise is particularly important where organizations undertake customer profiling, behavioral analytics, fraud detection, or other activities involving continuous monitoring.

Importantly, the outcome is not predetermined. Two organizations undertaking similar processing activities may legitimately reach different conclusions depending upon their operational context and safeguards.

Documentation is becoming as important as the decision itself:

One of the clearest messages emerging from the PDPC’s recent consultation is that organizations should be able to explain how they reached their legal conclusions.

Historically, many organizations simply recorded “Legitimate Interest” in their Records of Processing Activities or privacy notices without documenting the underlying reasoning.

That approach is becoming increasingly difficult to justify.

Organizations should instead maintain contemporaneous records explaining:

the legitimate interest pursued;
why the processing is necessary;
how competing interests were balanced;
what safeguards were implemented; and
when the assessment will be reviewed.

These records not only support regulatory accountability but also improve internal governance by ensuring that legal basis assessments remain consistent across different business units.

Legitimate interest should evolve with the processing:

A legal basis assessment should not be regarded as a one-time exercise.

Business practices evolve. New technologies are introduced. AI systems become more sophisticated. Customer expectations change.

Processing that was originally assessed as proportionate may become significantly more intrusive over time.

Organizations should therefore periodically review Legitimate Interest Assessments, particularly where processing activities involve profiling, AI-assisted decision-making, large-scale analytics, or new categories of personal data.

Periodic review is consistent with the broader accountability framework underpinning the PDPA and helps ensure that legal basis assessments remain aligned with actual business practices.

Legitimate interest is ultimately about governance:

Perhaps the most important lesson emerging from the PDPC’s consultation is that legitimate interest should not be viewed primarily as a legal exception to consent.

Instead, it should be understood as a governance framework requiring organizations to demonstrate thoughtful decision-making.

Organizations that simply declare legitimate interest without documented analysis are unlikely to satisfy increasing regulatory expectations.

By contrast, organizations capable of demonstrating why processing is necessary, how competing interests were balanced, and what safeguards were implemented will be better positioned to justify their decisions if questioned by regulators or affected individuals.

The emphasis is therefore shifting from selecting a legal basis to demonstrating why that legal basis remains appropriate throughout the lifecycle of the processing activity.

Looking ahead:

As organizations increasingly deploy AI, customer analytics, fraud detection systems, behavioral advertising, and other data-driven technologies, reliance on legitimate interest is likely to become more common rather than less.

This makes governance increasingly important.

The PDPC’s consultation suggests that future enforcement may focus less on whether organizations selected legitimate interest and more on whether they can demonstrate the quality of the assessment supporting that decision.

Organizations that treat Legitimate Interest Assessments as living governance documents rather than compliance paperwork will be better prepared as Thailand’s privacy regime continues to mature.

Key takeaways:

Legitimate interest is not an alternative chosen for convenience but a legal basis that should reflect the actual purpose of processing.
Organizations should identify each processing activity separately before determining whether legitimate interest is appropriate.
Necessity and balancing are substantive assessments that should be documented rather than assumed.
Legitimate Interest Assessments should evolve alongside changes in technology, business practices, and customer expectations.
Increasingly, regulatory scrutiny is likely to focus on the quality of governance and documentation supporting legitimate interest rather than the mere assertion that it applies.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint

on July 15, 2026July 20, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint

For many organizations, preparing a Record of Processing Activities (ROPA) has been one of the least engaging aspects of complying with Thailand’s Personal Data Protection Act (PDPA). Frequently viewed as a statutory obligation rather than a practical management tool, ROPAs are often prepared once, filed away, and revisited only when requested during internal audits or regulatory inquiries.

This perception is beginning to change.

The Personal Data Protection Committee’s (PDPC) recent consultation on Records of Processing Activities suggests that the regulator increasingly views the ROPA as more than a compliance checklist. Instead, it appears to regard the ROPA as the central document connecting an organization’s privacy governance framework. Although the guidance remains subject to public consultation, it illustrates how the regulator expects organizations to understand, document, and govern personal data processing across the enterprise. Rather than serving as a static inventory of personal data, the ROPA is evolving into a living record of how an organization manages privacy risks and demonstrates accountability under the PDPA.

This shift is significant because it mirrors the growing complexity of modern business operations. Organizations increasingly process personal data through cloud services, software-as-a-service platforms, artificial intelligence (AI), customer relationship management systems, outsourced service providers, and cross-border digital ecosystems. A ROPA that merely lists departments and categories of personal data is unlikely to provide meaningful insight into how those activities actually operate.

A good ROPA should explain how the business works:

Many organizations approach a ROPA as a spreadsheet of processing activities.

That is an understandable starting point, but it is no longer sufficient.

A well-developed ROPA should allow someone unfamiliar with the organization to understand how personal data flows through the business. It should explain why personal data is collected, who uses it, where it is stored, whether it is shared with third parties, whether it leaves Thailand, how long it is retained, and what safeguards protect it.

Viewed in this way, a ROPA resembles a process map rather than an inventory.

This broader perspective benefits the organization as much as the regulator. It enables legal, compliance, information security, procurement, and business teams to work from a common understanding of data processing activities rather than maintaining separate records that quickly become inconsistent.

Processing activities—not departments—should become the focus:

One recurring challenge is that organizations frequently prepare ROPAs according to organizational structure rather than business activities.

Typical entries include “Human Resources,” “Finance,” or “Marketing.”

While administratively convenient, these categories often obscure the underlying processing activities that matter under the PDPA.

For example, a marketing department may collect personal data to administer loyalty programmes, analyze customer behavior, operate targeted advertising campaigns, manage promotional events, and respond to customer inquiries. Each activity may involve different categories of personal data, different legal bases, different retention periods, and different third-party service providers.

Documenting each activity separately provides a more accurate picture of privacy risk and facilitates more meaningful governance.

A ROPA should reveal dependencies:

One of the most valuable functions of a ROPA is identifying operational dependencies.

Many organizations discover during ROPA preparation that multiple business units rely on the same customer database, share vendors, or process identical information for different purposes.

These dependencies often remain invisible until the organization attempts to document its processing activities comprehensively.

Recognizing them can improve not only privacy compliance but also cybersecurity, procurement, contract management, and incident response planning.

The ROPA therefore becomes a tool for organizational learning rather than regulatory compliance alone.

AI and cloud services are changing what a ROPA should capture:

When many organizations first prepared ROPAs, processing activities were comparatively straightforward.

Today, organizations increasingly rely on cloud platforms, AI-powered customer service tools, outsourced analytics providers, and software supplied by multiple vendors.

This evolution raises new governance questions.

A modern ROPA should help organizations understand:

which AI tools process personal data;
what information is transferred to cloud providers;
whether overseas processing occurs;
what vendors act as processors or sub-processors;
how long AI systems retain information;
what contractual safeguards exist.

These questions are increasingly relevant regardless of whether AI is used internally or through third-party services.

ROPAs should support decision-making:

The most effective ROPAs are not prepared for regulators.

They are used internally.

Before launching a new customer loyalty programme, introducing AI-powered customer service, engaging a new cloud provider, or expanding into another jurisdiction, organizations should review existing processing activities through the ROPA.

Doing so helps identify whether new processing purposes arise, whether additional legal bases are required, whether privacy notices should be updated, and whether vendors require additional contractual protections.

Used effectively, the ROPA becomes an operational governance tool rather than a historical record.

Keeping the ROPA alive:

One of the greatest risks is allowing the ROPA to become outdated.

Business models evolve continuously. New technologies are introduced. Vendors change. Retention periods are revised. AI capabilities expand.

A ROPA that accurately reflected the organization two years ago may no longer describe current processing activities.

Organizations should therefore integrate ROPA maintenance into existing governance processes.

Updates should occur whenever significant changes are introduced, including new products, major technology implementations, acquisitions, outsourcing arrangements, or cross-border processing activities.

Periodic review should become part of normal business governance rather than a special compliance exercise.

Looking ahead:

The PDPC’s consultation suggests that the ROPA is evolving from a statutory record into a central governance document. This reflects a broader movement under the PDPA toward accountability and demonstrable compliance rather than documentation for its own sake.

Organizations that treat the ROPA as a living blueprint of their data processing environment will be better equipped to respond to regulatory inquiries, support privacy impact assessments, evaluate AI deployments, manage vendors, and demonstrate compliance with the PDPA.

Key takeaways:

A ROPA should describe how personal data flows through the organization rather than merely listing departments.
Processing activities—not organizational units—should form the foundation of the ROPA.
A well-maintained ROPA helps identify operational dependencies, shared datasets, and vendor relationships that may otherwise remain unnoticed.
Modern ROPAs should capture AI systems, cloud services, cross-border processing, and processor/sub-processor relationships where relevant.
Organizations should treat the ROPA as a living governance document that supports operational decision-making rather than as a static compliance record.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

on July 14, 2026July 20, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

One of the most persistent misconceptions surrounding Thailand’s Personal Data Protection Act (PDPA) is that appointing a Data Protection Officer (DPO) satisfies an organization’s compliance obligations.

In practice, many organizations regard the DPO as the person responsible for “doing PDPA.” Privacy notices, data subject requests, breach notifications, contract reviews, training, audits and even cybersecurity issues are routinely directed to the DPO, often regardless of whether the DPO has the authority, resources or operational involvement to manage those activities effectively.

This perception is understandable. The PDPA requires certain organizations to appoint a DPO, and the role naturally becomes the focal point for privacy-related matters. However, the PDPC’s recent consultation on DPOs suggests that this understanding is incomplete. Rather than placing responsibility for compliance on the DPO, the consultation reinforces a governance model in which responsibility remains with the organization itself. The DPO’s role is to advise, monitor and facilitate compliance—not to replace management’s accountability.

This distinction may appear technical, but it has significant practical consequences for how organizations should structure their privacy governance.

Compliance belongs to the organization:

Privacy compliance is often described as a legal function, yet effective compliance depends upon decisions made throughout the organization.

Marketing teams determine how customer data is used.

Human resources departments manage employee information.

Information technology teams implement technical safeguards.

Procurement negotiates contracts with service providers.

Business units decide what personal data should be collected and why.

These operational decisions cannot realistically be delegated to a single individual.

The DPO may advise on each of these activities, but the responsibility for making business decisions—and ensuring those decisions comply with the PDPA—remains with the organization.

This governance model is consistent with the broader direction of the PDPC’s recent consultations, which increasingly emphasize accountability across the organization rather than concentrating responsibility within a single compliance function.

Independence does not mean isolation:

The PDPA requires that the DPO perform their duties independently.

This requirement is sometimes misunderstood to mean that the DPO should operate separately from the business.

In practice, independence means something quite different.

A DPO should be able to provide objective advice without inappropriate influence from commercial considerations. Management should not pressure the DPO to approve questionable processing activities or discourage the DPO from identifying compliance risks.

At the same time, independence should not prevent close collaboration with business units.

An effective DPO understands the organization’s operations, participates in project planning, and provides practical advice before privacy issues become compliance problems.

The most successful DPOs are therefore integrated into decision-making while remaining sufficiently independent to challenge proposals where necessary.

The DPO should be involved early:

Privacy risks are easiest to manage before systems are implemented.

Once a customer platform has been launched, an AI tool deployed, or a vendor contract executed, addressing privacy concerns often becomes significantly more expensive.

Organizations should therefore involve the DPO during the planning stage of new initiatives.

Examples include:

launching new digital products;
introducing AI-powered customer service;
implementing HR technologies;
engaging cloud providers;
deploying CCTV systems;
expanding overseas operations.

Early involvement allows privacy considerations to be incorporated into business decisions rather than added after implementation.

Expertise matters more than job title:

The PDPA does not prescribe a single professional background for DPOs.

In practice, effective DPOs come from diverse disciplines, including law, information security, compliance, risk management and information technology.

What matters is not professional qualification alone but the ability to understand both legal requirements and operational realities.

An effective DPO should be capable of translating legal principles into practical business guidance while communicating effectively with senior management, technical specialists and operational teams.

Organizations should therefore focus on competence rather than formal titles when appointing a DPO.

Conflicts of interest deserve careful consideration:

One of the most challenging aspects of DPO governance is avoiding conflicts of interest.

Individuals responsible for determining why and how personal data is processed may struggle to provide independent oversight of those same decisions.

For example, appointing the head of marketing as DPO may create tension where marketing initiatives require objective privacy review.

Similarly, information technology leaders responsible for designing systems may find it difficult to independently assess privacy risks arising from those systems.

Organizations should therefore consider whether reporting structures, operational responsibilities and decision-making authority could compromise the DPO’s independence.

The objective is not to prohibit dual roles entirely but to ensure that privacy oversight remains objective and credible.

A successful DPO builds a privacy culture:

Perhaps the greatest misconception is that privacy compliance can be centralized.

No DPO—regardless of experience—can personally oversee every processing activity across a large organization.

Long-term success depends upon building privacy awareness throughout the business.

Training, internal guidance, standardized procedures, governance committees and clearly allocated responsibilities often contribute more to sustainable compliance than expanding the DPO’s workload.

The DPO’s most valuable contribution may therefore be enabling others to make better privacy decisions rather than making every decision personally.

Looking ahead:

The PDPC’s consultation reflects an increasingly mature understanding of the DPO function.

Rather than acting as the organization’s privacy manager, the DPO is emerging as an independent adviser who supports, challenges and guides the organization while management retains responsibility for compliance.

Organizations that recognize this distinction will be better positioned to establish sustainable governance frameworks rather than relying excessively on a single individual to solve increasingly complex privacy issues.

Key takeaways:

Appointing a DPO does not transfer PDPA compliance responsibilities from the organization to the DPO.
The DPO’s role is to advise, monitor and facilitate compliance while management remains accountable for processing decisions.
Independence enables objective advice but should not prevent close collaboration with business units.
Early involvement of the DPO in new projects helps identify and address privacy risks before implementation.
Organizations should carefully assess potential conflicts of interest and ensure that the DPO has sufficient authority, resources and access to senior management.
A mature privacy program depends on organization-wide governance and a culture of compliance, not on the DPO alone.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPA: Why Many Compliance Programs Fail Before They Begin

on July 13, 2026July 20, 2026 by pithayutr

PDPA Insights: Building Effective Privacy Governance

PDPA: Why Many Compliance Programs Fail Before They Begin

For many organizations, implementing Thailand’s Personal Data Protection Act (PDPA) begins with a familiar request.

“Can you send us a privacy notice?”

“Do you have a consent form we can use?”

“Can we copy the privacy policy from another company?”

These questions are understandable. Privacy notices, consent forms and cookie banners are visible. Customers can see them, business partners frequently request them during due diligence, and regulators often ask for them during investigations. Producing these documents therefore creates the impression that an organization is making tangible progress towards compliance.

Yet, in practice, this approach often starts the compliance journey in the wrong place.

The Personal Data Protection Committee’s (PDPC) recent series of draft guidelines consistently points towards a broader principle. Whether discussing legal bases, direct marketing, Records of Processing Activities (ROPAs), Data Protection Officers (DPOs), or security measures, the common theme is not documentation—it is governance. The regulator’s emerging expectation is that organizations first understand how personal data is processed before attempting to document those activities.

The consequence is significant. Many compliance programs fail not because organizations lack policies or templates, but because they build documentation before understanding the business processes those documents are intended to describe.

Compliance should begin with understanding the business—not drafting documents:

Perhaps the most common mistake is assuming that PDPA compliance starts with drafting a privacy notice.

In reality, a privacy notice should be one of the last documents prepared.

Before an organization can explain how personal data is processed, it must first understand its own processing activities. That requires data mapping and gap analysis.

Organizations should begin by asking practical questions.

What categories of personal data are collected?
Why is each category collected?
Which departments use the information?
Which vendors receive it?
Does the information leave Thailand?
How long is it retained?
Which legal basis supports each processing activity?

Only after these questions have been answered can an organization prepare a privacy notice that accurately reflects its operations.

A privacy notice should describe reality—not define it.

Unfortunately, many organizations reverse this process. They prepare documentation first and attempt to fit their operations into those documents afterwards. The result is often a privacy notice describing processing activities that do not exist while overlooking activities that are central to the business.

Compliance therefore begins with understanding data flows rather than drafting legal documents.

Visible documents should not be mistaken for compliance:

Another widespread misconception is that having a privacy notice, consent form and cookie banner demonstrates compliance.

These documents are important.

They are not, however, evidence that personal data is being processed lawfully.

An organization may publish an excellent privacy notice while having no documented legal basis assessments, no ROPA, no retention schedule, no vendor management procedures, no incident response plan and no understanding of how AI systems process personal data.

In other words, documentation can describe compliance without demonstrating it.

A useful distinction is this:

A privacy notice tells customers what an organization says it does. Governance demonstrates what the organization actually does.

The latter is what increasingly matters.

Every organization has different data flows:

Organizations frequently ask whether they may use another company’s privacy notice as a starting point.

While templates may provide useful drafting ideas, no two organizations process personal data in exactly the same way.

Even businesses operating within the same industry often differ significantly.

One retailer may outsource customer relationship management while another performs those functions internally.

One financial institution may process customer information entirely within Thailand while another relies extensively on overseas cloud providers.

One hospital may deploy AI-assisted diagnostic tools while another does not.

These operational differences inevitably influence legal basis assessments, retention periods, vendor management, international transfers and privacy notices.

Consequently, copying another organization’s documentation without first understanding one’s own processing activities risks producing documentation that is inaccurate from the outset.

Privacy documentation should therefore be tailored to the organization’s actual business model rather than borrowed from comparable organizations.

Consent is not the answer to every question:

Another persistent misconception is that obtaining consent automatically resolves privacy compliance.

Consent certainly plays an important role under the PDPA, but it should not become the default legal basis simply because it appears straightforward.

The more appropriate starting point is to identify the processing activity and understand why personal data is being processed.

Different activities frequently require different legal analyses.

Customer information collected to deliver purchased goods serves a different purpose from analyzing purchasing behavior to personalize future recommendations. Human resources information collected to administer payroll differs from information processed for employee engagement surveys.

Treating all processing activities as though they rely upon a single consent often oversimplifies legal requirements while creating unnecessary operational complexity.

Privacy is not the DPO’s responsibility alone:

Appointing a Data Protection Officer is another milestone that organizations sometimes mistake for compliance.

The DPO performs an important governance role, but the DPO does not “own” privacy.

Marketing determines how customer information is used.

Human resources processes employee information.

Information technology implements security measures.

Procurement appoints vendors.

Management determines business objectives.

Privacy compliance therefore depends upon decisions made throughout the organization rather than by one individual.

Organizations that rely exclusively upon the DPO often discover that privacy issues continue arising because governance has not been embedded into operational decision-making.

A ROPA is more than regulatory paperwork:

Many organizations prepare a Record of Processing Activities only because they believe the law requires one.

This perception overlooks the ROPA’s greatest value.

A well-maintained ROPA explains how personal data moves through the organization.

It identifies processing activities, legal bases, recipients, retention periods, international transfers and relationships with processors.

Perhaps more importantly, it often reveals inconsistencies that organizations had not previously recognized.

Different departments may retain identical information for different periods.

Separate business units may rely upon the same vendor.

Customer information may be transferred internationally without centralized oversight.

Viewed this way, the ROPA becomes a governance tool rather than merely a compliance document.

Cybersecurity does not equal privacy compliance:

Investment in cybersecurity has increased significantly in recent years.

Organizations deploy multi-factor authentication, endpoint detection systems, encryption technologies and internationally recognized security standards.

These investments are essential.

However, privacy compliance extends beyond technical security.

Organizations must still determine whether they collect more personal data than necessary, retain information for appropriate periods, rely upon suitable legal bases, manage processors appropriately and provide individuals with meaningful transparency.

Strong cybersecurity reduces certain risks.

It does not replace governance under the PDPA.

AI has not replaced traditional privacy principles:

Artificial intelligence has prompted many organizations to assume that entirely new privacy obligations now apply.

In reality, AI changes the scale of processing rather than the legal principles themselves.

Organizations should still ask familiar questions.

Why is personal data being processed?

What legal basis applies?

What information is being used?

Who receives it?

How are decisions documented?

AI governance therefore begins with ordinary privacy governance rather than replacing it.

Organizations that already understand their data flows will usually be better positioned to manage AI than those attempting to develop AI policies without first understanding their existing processing activities.

Compliance is not a project with an end date:

Perhaps the most damaging misconception is that PDPA compliance can be completed once and then forgotten.

Many organizations implemented privacy notices and consent forms when the PDPA first became fully enforceable.

Since then, business operations have changed considerably.

Organizations have adopted cloud platforms, AI tools, digital marketing technologies, remote working arrangements and increasingly sophisticated customer analytics.

Privacy governance should evolve alongside those changes.

Compliance should therefore be viewed as an ongoing governance function rather than a one-time legal project.

Looking ahead:

The common thread running through the PDPC’s recent draft guidance is that privacy compliance is becoming increasingly operational.

Organizations are expected not merely to produce documentation but to understand their processing activities, justify their decisions, manage risk and demonstrate accountability throughout the lifecycle of personal data.

That begins with understanding the business itself.

Organizations that start with data mapping, gap analysis and governance are likely to produce privacy notices, consent forms and internal policies that accurately reflect their operations.

Organizations that begin with templates may produce attractive documentation but still struggle to explain how personal data actually moves through the business.

Ultimately, effective PDPA compliance is not built by copying documents. It is built by understanding the organization those documents are intended to describe.

Key takeaways:

Effective PDPA compliance should begin with data mapping and gap analysis rather than drafting privacy notices or consent forms.
Privacy notices should reflect an organization’s actual processing activities and should be developed after those activities have been identified and documented.
Copying another organization’s privacy documentation without understanding one’s own data flows often results in inaccurate and ineffective compliance.
Consent is only one of several legal bases and should not be treated as the default solution for every processing activity.
Privacy governance is an organization-wide responsibility involving management, business units, IT, HR, procurement and legal—not only the DPO.
A well-maintained ROPA is a governance tool that helps organizations understand data flows, vendors and operational risks.
Strong cybersecurity supports privacy compliance but does not replace broader governance obligations under the PDPA.

Privacy compliance should be treated as a continuous governance function that evolves alongside changes in technology and business operations.

Author: Panisa Suwanmatajarn, Managing Partner.

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

PDPC Certification: Turning Privacy Compliance into a Competitive Advantage

on July 1, 2026July 1, 2026 by pithayutr

PDPC Certification: Turning Privacy Compliance into a Competitive Advantage

The Office of the Personal Data Protection Committee (PDPC) has recently introduced a formal certification framework for personal data protection under the Personal Data Protection Act B.E. 2562 (2019) (PDPA). The framework establishes a mechanism through which organizations may obtain certification and display certification marks demonstrating adherence to recognized data protection standards.

While many organizations may initially view certification as another compliance exercise, the broader significance of the new framework lies in its potential to transform privacy compliance from a legal obligation into a strategic business asset. As customers, business partners, investors, and regulators place increasing emphasis on data governance, certification offers organizations an opportunity to distinguish themselves in an increasingly competitive marketplace.

Privacy as a Business Differentiator:

Over the past several years, data privacy has evolved from a niche compliance issue into a boardroom-level concern. High-profile data breaches, growing public awareness of privacy rights, and increasingly stringent regulatory requirements have elevated privacy protection into a key component of corporate governance.

As a result, organizations are increasingly expected not only to comply with legal requirements but also to demonstrate that compliance in a credible and transparent manner.

The new certification framework addresses this need by providing a mechanism through which organizations can obtain independent recognition of their privacy management practices. Rather than merely asserting compliance, certified organizations can point to a formal assessment conducted under a framework recognized by the PDPC.

In many industries, this distinction may prove valuable. Consumers are becoming more selective about how their personal information is collected, used, and protected. Organizations that can demonstrate a higher level of commitment to privacy may gain a competitive advantage over those that rely solely on contractual assurances or privacy notices.

Strengthening Customer Trust:

Trust is often one of the most valuable intangible assets an organization possesses. In the digital economy, that trust is closely linked to how personal data is managed.

Organizations routinely collect personal information from customers, employees, suppliers, and business partners. Any perceived weakness in data protection practices can quickly damage brand reputation and customer confidence.

Certification can help bridge the trust gap by providing independent verification that an organization has implemented appropriate data protection controls. Customers may view certification as evidence that an organization takes privacy obligations seriously and has invested in developing robust governance measures.

For businesses operating in sectors involving extensive personal data processing—such as financial services, healthcare, technology, telecommunications, hospitality, retail, and e-commerce—the ability to demonstrate recognized privacy standards may become an increasingly important competitive differentiator.

Facilitating Business-to-Business Relationships:

The benefits of certification may extend well beyond customer-facing activities.

Organizations increasingly conduct privacy and cybersecurity due diligence before engaging vendors, service providers, and business partners. Privacy questionnaires, vendor assessments, and contractual compliance reviews have become standard features of commercial transactions.

A recognized certification may help organizations streamline these processes by providing objective evidence of their privacy governance capabilities. Business partners may gain greater confidence in certified organizations, reducing the need for extensive verification exercises and accelerating commercial negotiations.

This may be particularly beneficial for service providers that process personal data on behalf of clients, including cloud service providers, software companies, outsourcing providers, human resources service providers, and professional service firms.

As privacy-related contractual obligations become more sophisticated, certification may increasingly serve as a practical tool for demonstrating compliance readiness.

Enhancing Corporate Governance:

One of the most significant benefits of certification may be the strengthening of internal governance structures.

Organizations pursuing certification are likely to establish clearer accountability mechanisms, more structured policies, improved risk management processes, and stronger oversight of personal data processing activities.

These governance improvements often extend beyond privacy compliance itself. Well-designed privacy programs frequently contribute to broader organizational objectives, including operational efficiency, information security, risk management, and regulatory compliance.

In this respect, certification should not be viewed merely as a badge or marketing tool. The process of achieving and maintaining certification may encourage organizations to embed privacy considerations more deeply into their governance culture and decision-making processes.

Supporting Regulatory Engagement:

Certification does not eliminate an organization’s legal obligations under the PDPA, nor does it provide immunity from regulatory enforcement.

Nevertheless, certification may serve as evidence that an organization has implemented structured and recognized measures to protect personal data.

Should a regulatory inquiry, investigation, or enforcement action arise, certification may help demonstrate that the organization has adopted a proactive and accountable approach to compliance. While each case will depend on its specific facts and circumstances, organizations that can demonstrate established governance frameworks may be better positioned when engaging with regulators.

This reflects a broader shift in privacy regulation globally, where regulators increasingly focus on accountability and governance rather than merely technical compliance.

Alignment with International Privacy Developments:

The introduction of a certification framework also aligns with broader international developments in privacy regulation.

The European Union’s General Data Protection Regulation (GDPR) recognizes data protection certification mechanisms under Articles 42 and 43 as tools for demonstrating compliance with data protection requirements. Although GDPR certification schemes are still developing across Europe, the underlying principle is clear: independent certification can strengthen trust, transparency, and accountability in personal data processing.

The PDPC’s certification framework follows a similar philosophy. Rather than relying exclusively on enforcement mechanisms, the framework encourages organizations to demonstrate compliance proactively through recognized standards and independent assessment.

For multinational organizations, this development may be particularly significant. Many businesses already operate under global privacy frameworks and seek consistency across jurisdictions. The availability of a domestic certification mechanism may help organizations align local compliance initiatives with broader international privacy governance strategies.

Supporting Cross-Border Business Opportunities:

As businesses increasingly participate in regional and global digital ecosystems, privacy credentials can become an important factor in commercial decision-making.

Foreign customers, investors, and business partners often assess privacy governance capabilities before entering into business relationships involving personal data processing. Organizations that can demonstrate recognized privacy standards may enjoy greater credibility during these assessments.

Certification may therefore provide advantages when competing for international business opportunities, participating in global supply chains, or providing services to overseas customers.

While certification alone will not satisfy all cross-border compliance requirements, it may serve as a valuable indicator of organizational maturity and commitment to responsible data management.

Looking Ahead:

The introduction of the PDPC’s certification framework represents more than a new compliance mechanism. It signals the continuing evolution of privacy regulation toward a model centered on accountability, governance, and demonstrable trustworthiness.

Organizations that view certification solely as a regulatory requirement may overlook its broader strategic value. In an environment where privacy expectations continue to rise, certification has the potential to strengthen customer confidence, facilitate commercial relationships, enhance corporate governance, and support long-term business growth.

For many organizations, the most significant benefit of certification may ultimately be its ability to transform privacy compliance from a cost center into a source of competitive advantage.

Key Takeaways:

The PDPC has introduced a formal certification framework for personal data protection under the PDPA.
Certification enables organizations to demonstrate privacy compliance through independent assessment and recognition.
Certified organizations may strengthen customer trust and enhance their market reputation.
Certification can facilitate vendor due diligence and improve business-to-business relationships.
The framework encourages stronger governance, accountability, and risk management practices.
Certification may help organizations demonstrate proactive compliance efforts when engaging with regulators.
The framework aligns with international developments, including certification mechanisms recognized under the GDPR.
Organizations engaged in cross-border business activities may benefit from the increased credibility and trust that certification can provide.
Privacy certification should be viewed not merely as a compliance tool, but as a strategic asset capable of creating competitive advantage.

Author: Panisa Suwanmatajarn, Managing Partner.

Other Articles

Tag: Data Processor

Tag: Data Processor

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