PDPA Compliance Checklist for Thai Businesses (2026)

Thailand’s Personal Data Protection Act (PDPA) took full effect on 1 June 2022 after two postponements, and enforcement is now routine rather than theoretical. The Act provides for administrative fines up to THB 5 million, with separate civil liability including punitive damages of up to twice the actual damages, and criminal penalties for the most serious categories of misuse.

Yet most Thai businesses still treat PDPA as a one-time legal exercise — a policy PDF, a cookie banner, done. Auditors and the PDPC do not look at the PDF. They look at whether the controls behind it exist. This checklist covers the IT side: the controls that are actually inspected.

What does the PDPA actually require?

The PDPA requires you to know what personal data you hold, have a lawful basis for processing it, apply appropriate security measures, honour data-subject rights within statutory timeframes, and report qualifying breaches to the PDPC within 72 hours. Everything below is an implementation detail of those five obligations.

The Act applies to any organisation that collects, uses or discloses the personal data of people in Thailand — including businesses based outside Thailand that offer goods or services to, or monitor the behaviour of, people in the country. Company size does not exempt you. The obligations scale, but they do not disappear.

Step 1 — Map what personal data you hold

Build a data inventory before anything else: what personal data you collect, where it lives, who can access it, and how long you keep it. You cannot protect, delete or produce data you have not mapped, and every downstream obligation depends on this record existing.

Cover every location, not just the obvious database: production systems, SaaS tools, shared drives, email archives, spreadsheets on individual laptops, CCTV recordings, backups, and anything held by a vendor on your behalf. In practice this single step is where most organisations discover their real exposure — forgotten staging databases with production data in them, HR files on an unmanaged share, and access that was granted years ago to people who have since changed roles.

Record the outcome as a Record of Processing Activities (RoPA). Section 39 requires controllers to maintain one, and it is the first document requested in any inquiry.

• What categories of personal data do you hold, including any sensitive data under Section 26 (health, biometrics, religion, criminal record, union membership)?
• Where does each category physically live, including backups and vendor systems?
• Who has access today, and does each of them still need it?
• What is the retention period, and what actually enforces it?
• Which processing activities involve a third-party processor, and is there a data processing agreement in place?

Step 2 — Establish a lawful basis for every activity

Every processing activity needs a documented lawful basis. Consent is only one of several, and it is often the weakest choice because it can be withdrawn. Where you do rely on consent, it must be freely given, specific, informed, and recorded — a pre-ticked box is not consent under the PDPA.

Many organisations default to consent for everything, which creates an operational trap: if a customer withdraws consent for processing you actually need to perform a contract, you have manufactured a conflict that did not need to exist. Contractual necessity, legal obligation and legitimate interest are all available and are frequently the better fit.

Whichever basis you rely on, the technical requirement is the same: it must be recorded per-activity and per-person, retrievable on request, and withdrawable through a mechanism that actually propagates to your systems. A consent checkbox that writes to nothing is worse than no checkbox, because it creates a documented claim you cannot substantiate.

Step 3 — Implement the technical safeguards

Section 37 requires "appropriate security measures." In practice the PDPC and auditors look for six: least-privilege access control, encryption in transit and at rest, audit logging, tested backups, patch management, and a written incident-response plan. These are standard IT controls, not specialist compliance tooling.

Pairing PDPA with an ISO 27001-style framework is the cheapest way to make these measures defensible, because it gives you a repeatable control set and evidence trail rather than a collection of one-off fixes. You do not need to certify to benefit from the structure.

The 72-hour breach-notification window under Section 37(4) is the requirement that catches organisations out. Seventy-two hours is not long enough to build detection capability after the fact — you need logging and alerting in place beforehand, plus a runbook that names who decides, who notifies, and what evidence gets preserved. If you cannot currently answer "has anyone accessed this data improperly?" then that is the first gap to close, ahead of everything else on this list.

Step 4 — Be able to honour data-subject requests

Data subjects can request access, correction, erasure, restriction, portability and objection. You must respond within 30 days. The practical test is whether you can locate every copy of one person’s data across every system — which is only possible if Step 1 was done properly.

Run the drill before someone makes a real request. Pick a name from your own customer database and try to produce every record you hold about them, from every system, including backups, within the statutory window. Most organisations discover during this exercise that erasure is the hard one: deleting from production is straightforward, but the same record persists in backups, in an analytics warehouse, and in three years of email.

Document the answer you arrive at. A defensible, written position on backup retention is acceptable; being unable to describe what happens is not.

Where most companies fall short

The common failures are not exotic. In our assessment work the same six issues recur: shared administrator accounts, no audit logging, unencrypted backups, third-party vendors with unmanaged standing access, no working consent withdrawal path, and no way to meet the 30-day response window.

Every one of these is fixable with standard IT controls, and none of them requires specialist compliance software. What they require is that someone owns the work and that it is treated as an operational discipline with a review cycle, rather than a project that finished when the policy was published.

If you want a second pair of eyes on where you actually stand, we run a technical PDPA assessment that produces a written gap list mapped to these controls — no obligation, and you keep the findings whether or not you engage us.