PDPA for Product Teams: What to Know and a Checklist You Can Use

Start by knowing what you collect and why

Personal data is anything that identifies a person, directly or indirectly: name, phone number, email, address, and also IP addresses, cookie IDs and LINE user IDs that can be traced back to someone. Some categories, such as health, religion or biometric data, are sensitive and carry stricter conditions.

Before reading any legal text, have the team draw a simple data map: what is collected, through which channel, where it is stored, who can access it, and who it is passed to. Teams often find form fields nobody uses but that are still collected, and the law expects you to collect only what is needed for your stated purpose.

Lawful basis and consent

PDPA does not say you need consent every time. Collecting and using data needs one lawful basis, such as consent, performing a contract, a legal obligation, protecting someone's life, a public task, or legitimate interests. Collecting an address to deliver what a customer ordered rests on the contract, so no separate consent is needed.

Consent matters for things like marketing messages and sensitive data. It should be asked for clearly, separate from other terms, never pre-ticked, tied to a stated purpose, and as easy to withdraw as to give. Keep a record of who agreed, when, and to which version of the text.

Privacy notice and data subject rights

Users must be told, before or when you collect data, what you collect, why, which lawful basis applies, how long you keep it, who receives it, and who to contact. Write it in readable Thai rather than several pages of legal text nobody opens, and place the link where data is actually collected, such as under the form.

People have several rights, and the team needs a practical way to honour them: who receives a request, how identity is verified, and which systems must be searched. Setting up a clear request channel early is cheaper than scrambling when the first real request arrives.

• Right to access and obtain a copy of their data
• Right to correct inaccurate data
• Right to erasure or anonymisation
• Right to object and to restrict use
• Right to data portability and to withdraw consent

Retention and vendors

Decide how long each type of data is kept and why. Accounting records that tax law requires you to keep follow that period, while data from rejected job applicants may be kept for far less. Then make deletion or anonymisation automatic instead of hoping someone remembers to do it.

When you use vendors such as email platforms, cloud hosting, analytics tools or a CRM, your company still carries the main responsibility for customer data. Put a data processing agreement in place, check where the vendor stores data, and if data goes abroad, look at the cross-border transfer conditions too.

Data you never collected is data that can never leak.

Breach readiness and a checklist

PDPA requires the data controller to notify the Personal Data Protection Committee (PDPC) within 72 hours of becoming aware of a breach, unless it is unlikely to risk people's rights and freedoms, and to inform the affected individuals too when the risk is high. So write the plan beforehand: who decides, who communicates, and which logs are kept for investigation.

Here is a checklist a team can start using right away. Check the details against the law, the latest PDPC announcements and your own legal counsel. This article is general information, not legal advice.

• A data map of what is collected, where, and who has access
• A written lawful basis and purpose for every collection point
• Consent that is separate, not pre-ticked, withdrawable and recorded
• A readable Thai privacy notice placed at the point of collection
• A process for receiving and answering data subject requests
• Retention periods with automatic deletion
• Data processing agreements with vendors, and a check on overseas transfers
• A breach response plan naming owners and notification steps