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