Thailand’s Personal Data Protection Act (PDPA) has been fully in force since June 2022. A policy alone does not tell a team where personal data sits, who is accountable for it or how to handle a rights request. Organisations should therefore review the evidence and processes they use in practice.
This article provides 15 questions covering governance, legal bases, processing records, data subject rights and incident response. The duties that apply depend on each organisation’s role and processing activities, so the relevant law and notifications should also be checked.
Part 1: Structure and Accountability
Item 1: Appoint a DPO or an Accountable Privacy Lead
Organisations that meet the applicable criteria must appoint a Data Protection Officer (DPO) under Section 41, such as public agencies and organisations conducting processing that meets the nature and scale defined by law. Even where a DPO is not legally required, the organisation should name a person accountable for coordinating PDPA work.
Check whether this person can access the information, authority and resources needed to perform the role. The work should not end with an appointment letter.
Item 2: Review the Privacy Policy
Check that the Privacy Policy matches the organisation’s actual collection points, including websites, applications, paper forms and offline channels. It should tell data subjects what is collected, why it is used and whom they can contact.
Item 3: Define Controller and Processor Roles
Identify whether the organisation acts as a Data Controller or Data Processor for each activity. Then check whether its Data Processing Agreements (DPAs) match the parties’ actual roles and data flows.
Part 2: Legal Basis and Consent
Item 4: Identify the Legal Basis for Each Processing Activity
The PDPA recognises six legal bases: Consent, Contract, Legal Obligation, Vital Interest, Public Task and Legitimate Interest. Record the legal basis used for each activity and the reason for that choice.
Review any activity that relies on Consent by default. Contract or Legitimate Interest may be relevant in some cases, but the choice depends on the actual processing activity.
Item 5: Keep Auditable Consent Records
If Consent is the legal basis, records should show when and how it was given and for which purpose. The process must also support withdrawal under the applicable requirements. Consent logs should retain a reviewable history of changes.
Item 6: Separate Consent by Purpose
Check that purposes are presented separately and that data subjects can make the choices required by the applicable rules.
Part 3: Records and Data Inventory
Item 7: Maintain a Record of Processing Activities (RoPA)
Section 39 requires Data Controllers and Data Processors to maintain a Record of Processing Activities (RoPA) covering data categories, purposes, legal bases, recipients, retention periods and security measures, subject to the conditions in the law.
Item 8: Maintain a Data Inventory and Data Map
The inventory and data map should show where personal data resides, where it moves, who can access it and how long it is retained. This record helps the organisation review legal bases, access and retention from a common view.
Assign an owner to update the record when systems, providers or processes change. Otherwise, the inventory will stop reflecting the actual work.
Part 4: Data Subject Rights and Requests
Item 9: Establish a Process for Data Subject Requests
The process should cover the six types listed here: access, rectification, erasure, restriction, portability and objection. The article uses a response period of 30 days from receipt; check the applicable conditions and exceptions for each request rather than applying one answer to every case.
Item 10: Make Request Channels Easy to Find
Provide a practical channel through which data subjects can submit requests, such as a web form, email or online system. The channel should be visible and connect to a process that assigns, verifies and closes each request.
Part 5: Data Security
Item 11: Review Security Measures
Section 37(1) requires appropriate technical and organisational security measures. Examples include access control, logging, policies, training and review. The measures should follow the risks and the type of processing involved.
Item 12: Prepare a Data Breach Response Plan
The response plan should support assessment of whether the PDPC must be notified within 72 hours and whether affected data subjects must be notified in a high-risk case.
Define roles, reporting channels and the information required for a decision. Then run a scenario exercise to see whether the team can gather the facts and decide in time.
Part 6: Data Transfers and Third Parties
Item 13: Review Agreements with External Processors
Identify which providers process personal data on the organisation’s behalf. Check how the relevant agreements address duties, security measures, audit rights and end-of-contract handling.
Item 14: Review Cross-border Transfers
For any cross-border transfer, record the destination, recipient and transfer mechanism before assessing whether the arrangement meets the applicable requirements. Binding Corporate Rules (BCRs) or Standard Contractual Clauses (SCCs) may be relevant in some cases.
Part 7: Training and Daily Work
Item 15: Train People for Their Roles
PDPA work involves every team that handles personal data. Training should match the role. Sales teams, for example, need guidance on using contact data, while request-handling teams need a clear verification and escalation process. Review frequency should reflect risk, role changes and organisational requirements.
Check that new employees receive guidance before handling personal data and that training or assessment records can be reviewed later.
Turn the Checklist into Reviewable Evidence
After reviewing all 15 areas, select one important processing activity and follow its evidence from beginning to end. A data subject request or a breach-response scenario can reveal where ownership and records break down.
For accountability, check whether consent logs, RoPA, DPAs, training records and incident reports have an owner, a review date and a clear connection to the operating process.
For data subject rights, walk through a request from intake and identity verification to data retrieval, approval and closure. Note where the work stalls.
For a data breach, rehearse how the team would collect facts and assess risk within the 72-hour period. The decision process needs reliable information, not only a written plan.
Start with One Processing Activity
Choose one activity involving personal data. Identify what is collected, the legal basis, who can access it, who approves decisions, how long it is kept and where the evidence sits. This exposes practical gaps before the organisation selects a tool.
If the number of activities, providers or requests becomes difficult to manage with existing files, evaluate tools against the work that needs to be tracked, user permissions, change history, reporting and integration with current systems.
This article provides general information, not legal advice. Check current requirements and the organisation’s context before using the checklist.
