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: Data Breach Governance Is More Than a 72-Hour Deadline
• PDPA: PDPC Clarifies the Scope of “Health Data”
• PDPA: The PDPC Is Redefining Marketing Compliance
• PDPA: Legitimate Interest Is No Longer a Shortcut
• PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint
• PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

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: Data Breach Governance Is More Than a 72-Hour Deadline
• PDPA: PDPC Clarifies the Scope of “Health Data”
• PDPA: The PDPC Is Redefining Marketing Compliance
• PDPA: Legitimate Interest Is No Longer a Shortcut
• PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint
• PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

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: Data Breach Governance Is More Than a 72-Hour Deadline
• PDPA: PDPC Clarifies the Scope of “Health Data”
• PDPA: The PDPC Is Redefining Marketing Compliance
• PDPA: Legitimate Interest Is No Longer a Shortcut
• PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint
• PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

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:

1. the legitimate interest pursued;
2. why the processing is necessary;
3. how competing interests were balanced;
4. what safeguards were implemented; and
5. 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: Data Breach Governance Is More Than a 72-Hour Deadline
• PDPA: PDPC Clarifies the Scope of “Health Data”
• PDPA: The PDPC Is Redefining Marketing Compliance
• PDPA: Legitimate Interest Is No Longer a Shortcut
• PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint
• PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

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: Data Breach Governance Is More Than a 72-Hour Deadline
• PDPA: PDPC Clarifies the Scope of “Health Data”
• PDPA: The PDPC Is Redefining Marketing Compliance
• PDPA: Legitimate Interest Is No Longer a Shortcut
• PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint
• PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

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: Data Breach Governance Is More Than a 72-Hour Deadline
• PDPA: PDPC Clarifies the Scope of “Health Data”
• PDPA: The PDPC Is Redefining Marketing Compliance
• PDPA: Legitimate Interest Is No Longer a Shortcut
• PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint
• PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is

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

• PDPA: Data Breach Governance Is More Than a 72-Hour Deadline
• PDPA: PDPC Clarifies the Scope of “Health Data”
• PDPA: The PDPC Is Redefining Marketing Compliance
• PDPA: Legitimate Interest Is No Longer a Shortcut
• PDPA: ROPA Is Becoming the Organization’s Privacy Blueprint
• PDPA: The DPO Is Not Responsible for Compliance—Your Organization Is