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