PDPA is Thailand’s Personal Data Protection Act: the law that governs how organisations collect, use and disclose personal data about people in Thailand. It has applied in full since 1 June 2022. Compliance by design means building its rules into a system from the first workshop, rather than adding a consent box just before launch.

This article is about the second part: how we design and build systems with the PDPA in mind. It is not legal advice. For advice on your own obligations, speak to a lawyer qualified in Thailand.

What the PDPA is

The Act was passed in 2019, and its main obligations took effect on 1 June 2022 after two postponements. It draws heavily on the EU’s General Data Protection Regulation (GDPR), so an organisation that already builds to GDPR will recognise most of it. The differences are in the detail, which is one more reason to take legal advice.

It applies to organisations in Thailand, and to organisations elsewhere that offer goods or services to people in Thailand or monitor what they do there. The Personal Data Protection Committee (PDPC) oversees it. Breaches can lead to administrative fines, criminal penalties and claims for damages.

The Act gives two roles. The data controller decides why and how personal data is used. The data processor handles it on the controller’s behalf. When a firm builds and runs a system for a client, the client is usually the controller, and the terms between them go in a data processing agreement.

What it asks of a system

In plain terms, a system that handles personal data under the PDPA needs to do eight things.

  1. Have a lawful basis for each use. Consent is one basis. Others include performing a contract, meeting a legal obligation and legitimate interests. The basis is chosen, and recorded, purpose by purpose.
  2. Ask for consent properly, where consent is the basis. Clearly, separately from other terms, in plain language, and as easy to withdraw as to give.
  3. Tell people what happens to their data. At or before collection: the purpose, how long it is kept, who it goes to, and their rights.
  4. Collect only what the purpose needs. Every extra field is something more to protect, explain and one day delete.
  5. Take more care with sensitive data. Health and biometric data, religion, criminal records and similar categories need explicit consent or another specific basis.
  6. Honour people’s rights. To see their data, correct it, have it deleted, object to its use, take it elsewhere, and withdraw consent.
  7. Keep it secure, and report breaches. Where a breach puts people at risk, the PDPC is told within 72 hours of the organisation becoming aware of it, and the people affected are told when the risk is high.
  8. Control transfers abroad. Personal data sent outside Thailand needs adequate protection where it lands, or another basis the law allows.

What compliance by design means in a build

Almost every rule above becomes a decision about screens, data and workflows. Taken at the start, those decisions cost little. Taken late, they mean redesign. On the Tops project, the lesson was that decisions made late are considerably more expensive than decisions made early.

In practice, compliance by design comes down to a handful of choices made before the build.

  • Map the data in discovery. What is collected, why, who sees it and where it goes. On Tops, discovery workshops defined the data requirements, validation rules and operational constraints before any build began.
  • Put consent inside the journey. Consent belongs in the flow the person is already in, at the moment it matters, not in a footer. Done well, it doesn’t slow anyone down.
  • Keep proof of consent. A consent is only useful if it can be shown later: who agreed, to what, when, and which version of the notice they saw.
  • Build for rights requests. Someone will ask what you hold about them, or ask you to delete it. Searching and deleting should be features of the system, not a manual hunt across spreadsheets.
  • Protect documents and access. Uploaded files and the dashboards that show them need the same care as the forms that collect them. We work to ISO 27001, the international standard for information security.
  • Set retention up front. Decide how long each kind of data is kept, and delete it when the time is up.
  • Build to GDPR and PDPA together where a system serves people in both the EU and Thailand, rather than maintaining two versions.

Two projects where we built it in

Tops: supplier onboarding. Tops, one of Thailand’s leading supermarket chains, wanted to bring small local producers onto its shelves. ddx designed and built the online platform suppliers use to register and submit products: a step-by-step application, secure uploads for certifications and product information, and a dashboard for Tops’ teams to review applications. Compliance with both the PDPA and GDPR was embedded throughout, rather than added at the end. The platform launched within two months, and more than 2,100 local suppliers registered and submitted about 12,700 products. Read the Tops case study.

Motor show lead capture. For a German luxury car brand at Thailand’s Motorshow and MotorExpo, ddx replaced paper-based lead capture with a tablet-based Digital Sales Kit: structured lead capture, instant quotations and consent management. Consent workflows built for GDPR and the PDPA sat directly inside the conversation between the sales consultant and the customer. All data capture met both laws, and lead conversion rose by 50%. Read the motor show case study.

Compliance and conversion aren’t a trade-off

The motor show work answers the usual worry, that consent slows sales down. Lead conversion rose by half while every record was captured compliantly. The lesson from that engagement was to design regulation and experience together, not one after the other.

It holds at larger scale too. On One Bangkok’s smart city platform, cybersecurity controls and data privacy compliance were embedded throughout, meeting local Thai regulatory requirements and international standards. And on a digital sales platform for a German automotive brand in Thailand, building data protection into the platform rather than retrofitting it was the right decision, though it took discipline across every workstream from day one.

Where to start

If you’re building or replacing a system that collects personal data in Thailand, three steps come first.

  1. List the personal data it will hold, and why. Purpose by purpose.
  2. Take legal advice on your obligations. From a lawyer qualified in Thailand.
  3. Bring the people who will build it into that conversation early, so the answers become requirements, not rework.

We build privacy and compliance into the platforms we deliver, under the PDPA, GDPR and sector rules. Read more about our Technology practice.

This article describes how we design systems. It is not legal advice.