Tag: Data Privacy

on by

PDPA: Cross-Border Data Transfer Compliance for Bank Z Under Thailand’s Data Protection Law – Key Takeaways

Thailand’s Personal Data Protection Act B.E. 2562 (PDPA) regulates the transfer of personal data abroad, imposing conditions to ensure adequate protection under Section 28. The Ad Hoc Subcommittee under the Personal Data Protection Committee has addressed Bank Z’s obligations when submitting directors’ personal data to comply with the Accounting and Corporate Regulatory Authority (ACRA) of Singapore and other foreign regulations. This analysis details the facts, the subcommittee’s rulings, and the resulting compliance framework.

Factual Background:

Bank Z must transmit directors’ personal data to meet ACRA requirements in Singapore and potentially other foreign laws. Under PDPA Section 28, cross-border data transfers require the recipient country or international organization to have adequate data protection standards, as determined by the Personal Data Protection Committee per Section 16(5), unless an exception applies. Bank Z faces uncertainty about whether “compliance with the law” under Section 28(1) includes foreign laws and, if not, how to proceed absent adequacy decisions for destination countries.

Subcommittee Decisions:

The subcommittee clarified Bank Z’s PDPA obligations as follows:

  1. Scope of “Compliance with the Law” Under Section 28(1)
    • Cross-border data transfers are permissible only if the destination has adequate protection standards, per Section 28 and criteria set under Section 16(5). Exceptions under Section 28(1)–(6) or Section 29 may apply. For Section 28(1)—compliance with the law—the law must be Thai and legally binding on the data controller. Foreign laws, such as ACRA regulations, do not qualify as a basis under this provision. Thus, Bank Z cannot rely on Section 28(1) to justify transfers based on Singaporean or other foreign legal obligations.
  2. Absence of Adequacy Decisions and Next Steps
    • No adequacy decisions exist under Section 16(5) and Section 28, as the committee has not yet designated any country or organization (e.g., Singapore) as having sufficient data protection standards. Without such designation, Bank Z must assess exceptions under Section 28(1)–(6). For instance, transferring directors’ data could fall under Section 28(3)—necessary to perform a contract where the director (data subject) is a party, such as employment or governance agreements—or pre-contractual steps requested by the director. If no exception applies (e.g., Sections 28(1), (3)–(6)), Bank Z must obtain explicit consent from directors per Section 28(2), informing them of the potentially inadequate protection standards in the destination country (e.g., Singapore) beforehand.

Implications for Compliance:

The subcommittee’s rulings restrict “compliance with the law” to Thai jurisdiction, excluding foreign mandates like ACRA’s as a direct basis. Absent adequacy decisions, Bank Z must either find a contractual or similar exception or secure directors’ informed consent, highlighting risks in destination countries. This dual approach balances legal obligations with data subject rights, pending future committee guidance on adequacy.

Key Takeaways:

  • Section 28(1) Is Thai-Law Specific: “Compliance with the law” applies only to Thai statutes, not foreign regulations like ACRA’s.
  • No Adequacy, No Free Pass: Without designated adequate destinations, transfers hinge on exceptions (e.g., Section 28(3)) or consent under Section 28(2).
  • Consent Requires Transparency: If consent is the basis, directors must be notified of inadequate protections in recipient jurisdictions.
  • Contractual Basis Offers Flexibility: Section 28(3) may cover director data transfers tied to governance duties, bypassing consent if applicable.

Bank Z’s scenario underscores PDPA’s stringent cross-border framework, prioritizing Thai legal authority and data subject awareness until adequacy standards are clarified. Compliance demands the strategic use of exceptions or proactive consent processes to align with international obligations.

Author: Panisa Suwanmatajarn, Managing Partner.

Other Articles

on by

PDPA: Does Removing a Name Make Data Anonymous?

Organizations increasingly remove names and other obvious identifiers from datasets before using the data for analytics, research, artificial intelligence development, or sharing it with third parties. A common assumption is that once names and identification numbers have been removed, the information is no longer personal data and therefore falls outside the Personal Data Protection Act B.E. 2562 (2019) (PDPA).

That assumption can be dangerous. Recent guidance from the Personal Data Protection Committee (PDPC) provides an important reminder: removing a person’s name does not, by itself, make data anonymous.

When does data become anonymous?

The key question is not simply whether direct identifiers have been deleted, but whether an individual can still be identified from the remaining information.

The PDPC’s approach indicates that data may be treated as anonymized where the data subject cannot be identified without additional information and appropriate technical and organizational measures have been implemented to ensure that identification is not reasonably possible in practice.

This distinction is particularly important where a dataset contains multiple indirect identifiers. Removing a person’s name while retaining information such as age, date of birth, location, gender, occupation, accident location, medical information, or other characteristics may still allow that person to be identified when those data points are considered together or combined with information from other sources.

Accordingly, de-identification is a question of substance, not merely the removal of specified fields.

Pseudonymization is not anonymization:

Organizations should also distinguish anonymization from pseudonymization.

If a person’s name is replaced with a code but the organization retains a separate table linking that code to the individual’s identity, the information remains capable of being attributed to that person. The dataset is therefore pseudonymized rather than truly anonymized.

Pseudonymization can be an important security and privacy measure, but it does not automatically take the data outside the PDPA. By contrast, properly anonymized information that can no longer reasonably be linked to an identifiable individual is no longer personal data for PDPA purposes.

This distinction has significant practical consequences. An organization cannot simply label a dataset “anonymous” or remove names and assume that the PDPA no longer applies.

Research provides a useful illustration:

The issue arose in the context of research into the causes of motorcycle accidents. Such research may involve ordinary personal data as well as sensitive personal data, particularly health information concerning injured persons.

The PDPA expressly recognizes research and statistical purposes as circumstances in which personal data may be processed without relying exclusively on consent. Section 24(1) provides a basis relating to research or statistical purposes, subject to appropriate safeguards protecting the rights and freedoms of data subjects. For sensitive personal data, Section 26(5)(d) similarly permits processing where necessary for scientific, historical or statistical research, or other public-interest purposes, subject to necessity and appropriate safeguards.

The PDPC has also prescribed specific safeguards for processing personal data for research and statistical purposes.

The practical significance is that organizations should not assume that anonymization is the only way to conduct research lawfully. Personal data may remain subject to the PDPA and nevertheless be processed for legitimate research purposes where the applicable statutory requirements and safeguards are satisfied.

What should organizations do in practice?

For organizations seeking to take datasets outside the scope of the PDPA, anonymization should be treated as a risk-based technical and governance process, rather than a simple data-cleaning exercise.

Direct identifiers should be removed, but organizations should also assess combinations of indirect identifiers and consider whether information could be matched against other reasonably available datasets. Where coded identifiers have been used, organizations should consider whether any linkage mechanism remains available. If a mapping table between codes and identities continues to exist, the resulting dataset is likely to remain pseudonymized rather than anonymous.

Depending on the nature of the dataset, additional techniques may be necessary, including aggregation, generalization, suppression, masking, reducing geographic or temporal precision, and other techniques designed to reduce re-identification risk.

Organizations should also document the anonymization process, the methodology used, the potential sources of re-identification, and the conclusion reached regarding residual risk. Technical measures should be accompanied by organizational controls restricting access and preventing attempts to re-identify individuals.

Why this matters for AI, analytics and data sharing:

The distinction has implications well beyond academic research.

Businesses increasingly want to use existing customer, employee, patient, transaction, location, behavioral, and operational datasets for AI development and training, statistical analysis, product improvement, or collaboration with external service providers and research institutions.

Where the information remains identifiable, the organization must continue to consider the PDPA requirements applicable to its collection, use, disclosure, retention, security, and other processing activities.

Where information has been effectively and irreversibly anonymized so that individuals are no longer reasonably identifiable in practice, however, the resulting dataset may fall outside the scope of the PDPA.

This makes anonymization potentially valuable for data-driven businesses, but it also means that organizations should be cautious about treating anonymization as a shortcut around data protection obligations. A dataset that can realistically be reconstructed, linked, or matched back to individuals remains exposed to PDPA risk regardless of what the organization calls it.

Key Takeaways:

  • Deleting names does not automatically anonymize personal data.
  • Organizations must consider whether individuals remain identifiable from other information or combinations of information in the dataset.
  • Pseudonymized data remains personal data where a person can be re-identified using additional information.
  • Proper anonymization requires technical and organizational measures designed to make re-identification impracticable.
  • Research and statistical processing may have specific legal bases under Sections 24(1) and 26(5)(d), subject to appropriate safeguards.
  • Organizations using data for AI, analytics, research or external data sharing should conduct and document a re-identification risk assessment before treating a dataset as outside the PDPA.
  • Anonymization should be viewed as an ongoing risk-management and governance exercise, not simply the deletion of names or identification numbers.

Author: Panisa Suwanmatajarn, Managing Partner.

Other Articles

on by

PDPA: Disclosure of Personal Data to Third Parties for Legal Proceedings

A recurring practical question under the Personal Data Protection Act B.E. 2562 (2019) (“PDPA”) is whether an organization may disclose personal data to a third party who needs the information to pursue a legal claim. Organizations often take a conservative position that personal data cannot be disclosed without the data subject’s consent. However, consent is only one of the legal bases under the PDPA, and the fact that information constitutes personal data does not, by itself, prohibit its disclosure. A recent opinion issued in response to a consultation by the Department of Land Transport (“DLT Opinion”) provides useful guidance on this issue and is particularly relevant to requests for personal data made for the purpose of exercising legal rights or pursuing legal proceedings.

Disclosure Does Not Necessarily Require Consent:

The DLT Opinion illustrates an important distinction between two questions: whether the information constitutes personal data and, if so, whether there is a lawful basis for its disclosure. Once information falls within the definition of personal data, its collection, use, or disclosure must comply with the PDPA, but this does not mean that disclosure is prohibited unless the data subject has given consent. Section 24 recognizes several legal bases for processing personal data without consent. Depending on the circumstances, disclosure to a third party may therefore be permissible where an appropriate legal basis exists. This is particularly important where the requesting party requires information to establish or exercise a legal right, claim damages, identify a responsible party, or commence legal proceedings. For example, a person who suffers damage involving a vehicle may know the vehicle registration number but may not know the identity of the person against whom a claim should be made. Similarly, a person injured in an incident recorded by CCTV may need the footage to establish the circumstances of the incident and pursue a claim. Treating the PDPA as an absolute prohibition against disclosure in such circumstances could prevent a person from effectively exercising legitimate legal rights.

Legitimate Interests and Legal Claims:

One potentially relevant legal basis is legitimate interests under Section 24(5) of the PDPA. This provision permits processing where it is necessary for the legitimate interests of the controller or another person, except where those interests are overridden by the fundamental rights of the data subject. A genuine need to obtain information for the establishment, exercise, or defense of a legal claim may constitute a significant legitimate interest. However, merely stating that information will be used in litigation should not automatically entitle a requester to obtain another person’s personal data. The controller should consider whether the claimed legal interest is genuine, whether disclosure of the requested information is necessary to pursue that interest, and whether the interests of the requester outweigh the privacy interests and fundamental rights of the data subject. In practical terms, this can be approached through a purpose–necessity–balancing analysis. The controller should first identify the legal purpose for which the information is requested; determine whether disclosure is reasonably necessary to achieve that purpose; and then balance that interest against the potential impact on the data subject. Supporting documents, such as a police report, evidence of damage, a demand letter, court documents, or other evidence demonstrating an actual or reasonably contemplated legal claim, may assist the controller in making and documenting this assessment.

The same reasoning has broader significance beyond vehicle-registration information. Government guidance discussing requests for CCTV footage has referred to the DLT Opinion by analogy when considering whether personal data may be disclosed to enable an injured person to exercise legal rights. This suggests that the Opinion may become an important reference point for third-party disclosure requests generally. Comparable issues arise frequently in the private sector: condominium juristic persons receive requests for CCTV footage following accidents or disputes; employers receive requests concerning former employees; insurers may hold information concerning parties to an accident; property owners may receive requests concerning tenants; and online service providers may receive requests for information identifying persons alleged to have committed a civil wrong. In each case, the correct question should not simply be whether the requested information is personal data, but whether the proposed disclosure has an appropriate legal basis and satisfies the requirements of necessity and proportionality.

Disclosure Should Be Limited to What Is Necessary:

Even where a lawful basis exists, the controller should not assume that all information in its possession may be disclosed. The scope of disclosure should be limited to information reasonably necessary for the stated legal purpose. If a requester needs information to identify a person against whom proceedings may be commenced, disclosure of the person’s name and information necessary for the relevant legal process may potentially be justified, while disclosure of unrelated information—such as identification numbers, telephone numbers, dates of birth, historical records, or other data not required for the claim—may not be. Redaction, partial disclosure, controlled access, or other safeguards should therefore be considered where appropriate. This distinction can be expressed simply as two separate questions: “Can the information lawfully be disclosed?” and “How much information is necessary to disclose?” Establishing a legal basis answers only the first question; the principles of necessity, proportionality, purpose limitation, and data minimization remain relevant to the second.

Organizations should also distinguish ordinary personal data under Section 24 from sensitive personal data under Section 26. Section 26 contains specific exceptions relating to processing necessary for the establishment, compliance, exercise, or defense of legal claims. Where sensitive personal data is involved, the requirements of Section 26 should therefore be considered separately rather than assuming that the legal basis applicable to ordinary personal data automatically applies. In all cases, organizations should consider implementing a documented Third-Party Personal Data Disclosure Request Procedure requiring verification of the requester’s identity, the purpose of the request, evidence supporting the claimed legal interest, the categories of information genuinely required, possible effects on the data subject, appropriate redaction or other safeguards, and a record of the reasons for approving or rejecting the request. Such documentation can be particularly important where the controller relies on legitimate interests and must subsequently demonstrate how the competing interests were assessed.

Key Takeaways:

The DLT Opinion is significant because it reinforces that the PDPA should not be treated as an automatic barrier to disclosure whenever personal data is involved. Consent is not the only legal basis for disclosure, and a genuine need to obtain information for the establishment, exercise, or defense of legal rights may support disclosure where the applicable requirements of the PDPA are satisfied. At the same time, an assertion that information is required for litigation does not create an unrestricted right of access to another person’s personal data. Controllers should assess the purpose, necessity, and balancing of interests, require appropriate evidence where necessary, limit disclosure to the minimum information reasonably required, and document the decision-making process. The broader lesson is that the PDPA is not intended to make personal data permanently inaccessible; rather, it establishes a framework for determining when disclosure is lawful, why it is necessary, and how much information may appropriately be disclosed.

Author: Panisa Suwanmatajarn, Managing Partner.

Other Articles

on by

PDPA: Applicability to a Facebook User’s Posting of Personal Data – Key Takeaways

Thailand’s Personal Data Protection Act B.E. 2562 (PDPA) regulates systematic personal data handling, with exemptions for personal or familial use. The Ad Hoc Subcommittee under the Personal Data Protection Committee has evaluated whether a Facebook user’s posting of an allegedly defamatory image and text qualifies them as a data controller under PDPA, as raised by Police Station F in a criminal investigation. This analysis outlines the facts, the subcommittee’s rulings, and the compliance implications.

Factual Background:

Police Station F received a complaint alleging that a Facebook user posted an image of the complainant with text causing insult or hatred, prompting a criminal case. The prosecutor’s office (C) requested the station to investigate: (1) whether the post’s visibility settings (public symbols like a globe or people) made it accessible to the general public or a specific group, and (2) whether the suspect qualifies as a data controller under PDPA Section 6 for posting the complainant’s image and text.

Subcommittee Decisions:

The subcommittee addressed the issues as follows:

  1. Post Visibility (Issue 1)
    • The question of whether the suspect’s Facebook post—with a globe or people symbol—was visible to the public or a limited group falls outside PDPA’s direct scope. PDPA defines “personal data” under Section 6 as information identifying a living individual, directly or indirectly (e.g., the complainant’s image). However, visibility settings pertain to evidence in a criminal investigation, not PDPA enforcement. The subcommittee deemed this a factual matter for the police to assess independently, unrelated to PDPA compliance.
  2. Data Controller Status (Issue 2)
    • Under PDPA Section 6, a “data controller” is a person or entity with authority to decide on the collection, use, or disclosure of personal data, subject to duties like lawful bases (Sections 24, 26), notification (Section 23), security (Section 37), and rights responses (Sections 30–36). The law targets systematic or regular data processing, not isolated acts, per its intent and Section 4(1) exemption for personal or family use. The suspect, a natural person posting on Facebook, isn’t a data controller if the act was for personal purposes (e.g., expression) without systematic intent. Absent evidence of regular, organized data handling, PDPA doesn’t apply, per Section 4(1). However, the act may violate other laws (e.g., Computer Crime Act B.E. 2550, Penal Code defamation, or Civil Code torts under Section 420), which the police should pursue separately.

Implications for Compliance:

The suspect’s posting likely falls outside PDPA’s ambit as a one-off personal act, not subjecting them to data controller obligations (e.g., consent, security measures). Police Station F must focus on criminal or tort laws for liability, using post visibility as evidence, not a PDPA issue. PDPA applies to entities with structured data practices, not casual social media use.

Key Takeaways:

  • PDPA Targets Systematic Use: The suspect isn’t a data controller under Section 6 unless their posting reflects regular, purposeful data management, per Section 4(1) exemption.
  • Personal Acts Are Exempt: One-time social media posts for personal ends fall outside PDPA, per Section 4(1), unlike organizational data handling.
  • Other Laws Apply: Privacy breaches or defamation may trigger liability under the Computer Crime Act, Penal Code, or Civil Code, not PDPA.
  • Visibility Is Investigative: Post accessibility (public vs. private) is a factual issue for criminal evidence, not a PDPA concern.

This ruling clarifies PDPA’s scope, excluding personal social media acts from its framework, directing Police Station F to pursue alternative legal avenues for the complainant’s grievance.

Author: Panisa Suwanmatajarn, Managing Partner.

Other Articles

on by

Employee Benefits and the Personal Data of Family Members

Employee benefit programs frequently require employers to process personal data not only of their employees, but also of their employees’ spouses, children, parents, or other family members. Typical examples include medical benefits, insurance coverage, educational allowances, travel benefits, and other welfare programs. While such processing is routine from an HR perspective, it raises an important question under the Personal Data Protection Act B.E. 2562 (2019) (PDPA): can an employer rely on the same lawful basis for the employee and the employee’s family members?

This issue was addressed by the Office of the Personal Data Protection Committee (PDPC Office) in Consultation No. 10/2568 concerning a bank’s processing of personal data of employees and their family members for employee benefits. The consultation is particularly useful because it illustrates a point that is sometimes overlooked in HR privacy compliance: identifying a legitimate business purpose is not enough. The data controller must identify the appropriate lawful basis in relation to each data subject whose personal data is being processed. The consultation also refers to the PDPA provisions concerning minors and purpose limitation, making the issue especially relevant where employee benefits extend to children.

The Employee and the Family Member Are Different Data Subjects:

For the employee, the analysis is relatively straightforward. Where benefits form part of the employee’s employment package, the employer may need to process the employee’s personal data to administer those benefits. Section 24 of the PDPA permits processing without consent in several circumstances, including where processing is necessary for the performance of a contract to which the data subject is a party, compliance with a legal obligation, or legitimate interests, subject to the applicable conditions.

Accordingly, where a benefit arises from the employment relationship, the contractual basis may potentially support processing of the employee’s personal data if that processing is objectively necessary to perform the employer’s obligations under the employment arrangement. Other benefits may instead be supported by a legal obligation or legitimate interests, depending on their nature and purpose.

The position becomes more complicated when the same benefit requires information about the employee’s spouse, child, parent, or other family member. Those individuals are separate data subjects. More importantly, they will ordinarily not be parties to the employment contract between the employer and the employee. The fact that processing their data enables the employer to provide a contractual benefit to the employee does not automatically make the family member a party to that contract.

This distinction matters because the contractual basis under the PDPA focuses on a contract to which the data subject is a party. Employers should therefore be cautious about treating the employment contract as a blanket lawful basis covering everyone whose information happens to be required for HR administration.

What Lawful Basis Can Apply to Family Members?

The appropriate basis must instead be considered according to the particular processing activity. Depending on the circumstances, an employer may be able to rely on legitimate interests, provided that the processing is necessary for a legitimate purpose and the employer has appropriately considered the rights and interests of the affected family members. Consent may be relevant where no other lawful basis is available, although it should not automatically be treated as the default solution merely because the individual is not an employee.

This distinction becomes even more important where benefits involve sensitive personal data under Section 26, particularly health information. Medical reimbursement and health insurance schemes, for example, may require medical certificates, diagnoses, treatment information, disability information, or other health data concerning an employee or family member. A lawful basis for ordinary personal data under Section 24 does not by itself resolve the processing of sensitive personal data. The employer must separately determine whether one of the conditions under Section 26 applies or whether explicit consent is required.

Children introduce an additional layer of compliance. If an employee submits personal data concerning a child for educational, medical, insurance, or other benefits, the employer must consider the PDPA requirements applicable to minors, including the rules governing consent where consent is the basis relied upon. Consultation No. 10/2568 expressly refers to Section 20 of the PDPA, which contains the statutory framework governing consent involving minors.

Do Not Forget the Privacy Notice:

Another practical issue is transparency. Section 21 requires personal data to be collected, used, and disclosed consistently with the purposes communicated to the data subject, subject to the statutory exceptions. Employers therefore need to consider not only whether they have a lawful basis, but also whether the relevant family members have been properly informed about the processing of their data.

An employee privacy notice that describes how the employer processes employee information does not necessarily solve this problem. The spouse, child, or parent remains a separate data subject. In many organizations, however, the employer obtains the family member’s information indirectly through the employee rather than directly from that family member.

HR teams should therefore review how their privacy notices deal with this situation. Depending on the circumstances, organizations may consider a separate notice for family members and beneficiaries, or incorporate appropriately drafted provisions into the HR privacy framework together with a mechanism for ensuring that the relevant information reaches those individuals. The notice should explain, among other matters, the purposes of processing, categories of information involved, applicable lawful bases, disclosures to insurers or other benefit providers, retention arrangements, and data subject rights.

Practical Implications for Employers:

Consultation No. 10/2568 is a useful reminder that an HR database should not be analyzed simply as a database containing “employee information.” A single employee record may contain personal data belonging to several legally distinct data subjects, and the lawful basis may differ among them.

Employers should therefore map benefit-related processing at the data-subject level. For each benefit, HR and privacy teams should identify whose information is collected, why it is required, whether ordinary or sensitive personal data is involved, the lawful basis applicable to each category of data subject, how the required privacy information is provided, and whether information is transferred to insurers, hospitals, benefit administrators, payroll providers, or other third parties.

This approach is particularly important because many HR processes were designed long before privacy compliance became a formal legal requirement. Forms asking employees to provide the names, identification numbers, dates of birth, relationship information, bank details, or medical information of family members may have existed for years. Their operational familiarity does not remove the need to identify a lawful basis and comply with the PDPA’s transparency, data minimization, security, and retention requirements.

Key Takeaways:

  • Do not automatically extend the employee’s lawful basis to family members. The employee and each family member are separate data subjects.
  • Contractual necessity requires particular attention. A spouse, child, or parent will ordinarily not be a party to the employment contract merely because the employee receives a benefit relating to that person.
  • Consider legitimate interests or another appropriate lawful basis for family-member data rather than treating consent as the automatic solution.
  • Analyze sensitive personal data separately. Health and similar information requires a basis permitted under Section 26 in addition to the analysis applicable to ordinary personal data.
  • Children require additional consideration, particularly where processing relies on consent.
  • Review privacy notices and indirect collection procedures. An employee privacy notice should not automatically be assumed to satisfy transparency obligations toward family members.
  • Audit existing benefit forms and HR systems. Employers should identify exactly what family-member information they collect and whether each data field remains necessary for administering the relevant benefit.

Author: Panisa Suwanmatajarn, Managing Partner.

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

on by

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

on by

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:

  1. rejecting employment applications;
  2. detecting suspected fraud;
  3. evaluating insurance claims;
  4. 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:

  1. The PDPA does not establish separate legal principles for AI; existing privacy obligations continue to apply regardless of the technology used.
  2. AI increases the scale and complexity of personal data processing but does not replace the need for lawful basis, transparency, purpose limitation, and accountability.
  3. Organizations should assess individual AI use cases rather than treating all AI deployments identically.
  4. Profiling and AI-assisted decision-making are becoming mainstream regulatory concerns and should be supported by appropriate governance and transparency.
  5. 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

on by

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

on by

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

on by

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