Skip to main content

กำลังโหลด...

Southern Whale

Website Privacy Policy Under Thailand's PDPA: What Your Business Needs (2026)

October 23, 2026
Cute whale mascot holding a padlock shield beside a website screen with a cookie banner and privacy policy document in a modern office

Many business owners know their website “needs PDPA”, but ask what that involves and the answer is often a privacy policy copied from another site with the company name swapped, plus a cookie banner with a single “Accept” button. Neither may match what the site actually does.

This article explains, from a web developer’s perspective, what a website privacy policy under Thailand’s Personal Data Protection Act (PDPA) should cover, how a cookie banner should behave, what to write under your forms, and how long to keep data, so you can prepare your site the right way. It is especially relevant if you run a business in Thailand with a site serving Thai and international customers.

Disclaimer: this article is general information from a web development perspective and is not legal advice. Laws, notifications and guidance from Thailand’s Personal Data Protection Committee (PDPC) can change. Businesses handling large volumes of data or sensitive data should consult a lawyer or PDPA specialist directly.

How the PDPA Applies to Business Websites

The PDPA (Personal Data Protection Act B.E. 2562 / 2019) sets duties for anyone who collects, uses or discloses personal data, meaning information that can identify a person directly or indirectly.

On a typical business site, personal data shows up in more places than you might think:

  • Names, phone numbers and emails from contact, quote request or booking forms
  • Delivery addresses and order history in an online shop
  • IP addresses and cookie IDs collected by analytics tools such as Google Analytics
  • Ad pixels such as Meta Pixel or remarketing tags
  • Data from chatbots or embedded chat buttons
  • CVs and job applications uploaded through the site

In legal terms, your business is the Data Controller, while outside services that process data on your behalf, such as hosting, email systems or analytics tools, are usually Data Processors.

What a Website Privacy Policy Should Include

A privacy policy (or privacy notice) exists to inform data subjects what you do with their data. The sections a typical business site should have:

Section What to write
Data controller Business name, address, contact details
Data collected The real categories, such as name, phone, email, IP, cookies
Sources Entered via forms, collected automatically, or received from third parties
Purposes Answering enquiries, preparing quotes, delivering goods, analytics, marketing
Legal basis For example contract, consent, legitimate interest, legal obligation
Disclosure Who receives data, such as couriers, system providers, authorities when legally required
Cross-border transfer If you use cloud services or tools with servers outside Thailand
Retention period How long you keep data, or the criteria used to decide
Data subject rights Access, correction, deletion, objection, withdrawing consent, complaints
Cookies Which types are used and why (or a separate cookie policy)
Security measures A brief summary of how data is protected
Contact / DPO How to exercise rights, and the data protection officer if you have one
Policy changes Effective date and last updated date

Key principle: write what your site actually does

The most common mistake is a policy that says “we do not use marketing cookies” on a site running Meta Pixel, or a ten-page policy that never says what the forms collect. Before writing the policy, build a data inventory:

  1. Go through every form on the site, note which fields it collects and where the data goes (email, Google Sheets, CRM)
  2. Go through every script installed, such as GA4, Google Tag Manager, pixels, chat, maps and embedded video
  3. List the external providers involved
  4. Ask your team what they do with the data afterwards, such as sending promotions or only replying to questions

Write it so people can understand it

A good policy does not need to be long, but it must be clear. Use language ordinary customers understand, break it into sections, and if your site is multilingual, provide the policy in the same languages your customers use.

Cookies roughly divide by purpose:

  • Strictly necessary: make the site work, such as the shopping cart, login and remembering consent choices
  • Analytics: such as Google Analytics, for visitor statistics
  • Marketing / advertising: such as ad pixels and remarketing
  • Functional: remembering language or extra features

Common practice is that strictly necessary cookies need no consent, while other categories should get consent first. Things many sites get wrong:

  1. Scripts must actually be blocked until consent is given, not just a banner shown while scripts have already loaded
  2. The reject button should be as easy to find as accept, not buried in a submenu
  3. Allow choice by category, for example accepting analytics but not marketing
  4. Make withdrawing consent easy, such as a “Cookie settings” link in the footer
  5. No pre-ticked boxes for non-essential categories
  6. Record consent: what the user chose and when

If you use Google Analytics 4 or Google Ads, set up Consent Mode v2 so Google tags behave according to each user’s choice. When a user declines, the tags do not set analytics or advertising cookies.

Technical details that often get missed

  • If your site has a Content Security Policy (CSP), it must allow your consent tool’s domain, or the banner may silently fail to appear
  • On mobile, the banner should not cover important buttons or a bottom navigation bar
  • Test in incognito mode that no marketing cookies are set before you click accept (check in your browser’s DevTools)

Forms are where personal data is collected most directly. Principles to follow:

1. Collect only what you need (data minimisation)

A contact form does not need a date of birth, ID card number or address if you do not actually use them. The less you collect, the less you are responsible for, and the easier the form is to fill in.

2. State the purpose under the form

Example wording (adapt it to your business):

The information you provide will only be used to contact you and answer your enquiry. See our Privacy Policy for details.

Then link to the policy page.

If you want to send news or promotions, add a separate, unticked checkbox that is not required to submit the form, for example:

☐ I would like to receive news and promotions by email (optional)

4. Take extra care with sensitive data

Businesses such as aesthetic clinics, dental clinics or wellness spas may receive health information through forms. Health data is sensitive data under the law, with stricter conditions. In this case, consult a lawyer before designing the form, and consider whether you really need to collect it through the website.

5. Transmit data securely

The whole site must run on HTTPS (see how to fix the “Not Secure” warning). Form notification emails should not go to staff members’ personal inboxes, and form data should not be scattered across several places with nobody responsible for it.

Data Retention and Deletion

The PDPA does not set a fixed number of days for every case. The principle is to keep data only as long as needed for the purpose, and to state that in your policy. Practical guidelines:

Data type How to set retention
Contact form messages from non-customers A reasonable period after the conversation ends, then delete
Customer and order data For the contract term and as required by accounting/tax law
Newsletter list Until consent is withdrawn
Job applications During the hiring process, or longer if the applicant agrees
Analytics data Set retention in the tool itself, such as Data Retention in GA4
Server logs As needed for security and relevant laws

Technical steps worth taking:

  • Turn on automatic deletion in systems that support it
  • Delete data from every place it is copied, not only the website (email, spreadsheets, CRM)
  • Review once a year as part of your website maintenance checklist

Data Subject Requests and Data Breaches

Data subject requests

People may ask to see, correct or delete their data, or withdraw consent. Your site should have a clear channel, such as a dedicated email address or request form, and your business should have an internal process for who handles requests, how identity is verified, and replying within the legally required time.

If data leaks

If your site is hacked and customer data may have leaked, the law requires notifying the regulator within a set time where there is a risk, and in some cases notifying the affected people too. Talk to a lawyer immediately. On the technical side, backups, access logs and regular security updates reduce risk and help you investigate afterwards.

PDPA Checklist for Business Websites

  • Data inventory: every form, every script, every provider
  • A privacy policy page that matches actual use, with a last updated date
  • Policy link in the footer of every page and under every form
  • A cookie banner that really blocks scripts, has a reject button and allows choice by category
  • A cookie settings link so consent can be withdrawn later
  • Consent Mode v2 if you use Google tools
  • Forms that collect only what is needed, with separate marketing consent
  • HTTPS across the whole site
  • Retention periods and deletion methods set
  • A channel for data subject requests and an internal process
  • Translated policies for multilingual sites
  • Legal review if you handle sensitive data or large volumes of data

What a Web Team Can Do and What Needs a Lawyer

Splitting responsibilities clearly saves both sides time.

  • Lawyer / PDPA consultant: legal basis, policy wording, sensitive data, cross-border transfers, processor agreements, breach response
  • Web development team: listing scripts and forms from the live site, installing a cookie banner that genuinely blocks scripts, setting up Consent Mode, adjusting forms, placing the policy page and links, configuring retention in tools

The Southern Whale freelance team handles these technical pieces on new builds and existing sites alike, from cookie banners and Consent Mode to forms that collect only what is needed. For the legal content itself, we always recommend a lawyer’s review. See our web development service or message us on LINE OA.

Frequently Asked Questions

Does a small site with just a contact form need a privacy policy?

It should have one. A contact form collects names, phone numbers or emails, which are personal data, and most sites also run analytics that use cookies. A small site’s policy can be short and simple.

Can I copy a privacy policy from another website?

Not recommended. Besides copyright on the text, a copied policy rarely matches the data your site actually collects, which amounts to giving people inaccurate information. Use others as a structural guide, but write the content from your actual setup.

If your site uses non-essential cookies such as analytics or marketing, a banner with no way to decline is not a freely given choice. Include a reject button and settings by category.

GA4 uses analytics cookies, so it is commonly treated as a category that needs consent first, with Consent Mode v2 set so tags follow the user’s choice.

What is the difference between a privacy policy and terms of use?

A privacy policy explains how personal data is handled. Terms of use set the rules for using the site and services, such as orders, refunds and content copyright. They are separate documents.

Do I need a Data Protection Officer (DPO)?

It depends on the nature and volume of data your business processes, as defined by law and PDPC notifications. Many small businesses may not meet the threshold, but confirm your case with a lawyer.

Summary

A good website privacy policy under Thailand’s PDPA starts with knowing what data your site really collects and stating it clearly, together with a cookie banner that genuinely blocks scripts and gives users a choice, forms that collect only what is needed with separate marketing consent, defined retention periods, and a working channel for data subject requests. Let your web team handle the technical side and a lawyer review the legal interpretation, and your site will be both trustworthy and ready to welcome customers with confidence.

About the author

Kreangsak S.

Kreangsak S.

Southern Whale team · SEO & WordPress Specialist · Web Developer

Over 10 years building websites and doing SEO, focused on WordPress and e-commerce sites with SEO built in from day one, now using AI to ship faster.

LinkedIn ↗Fastwork ↗Chat on LINE ↗

Want us to handle this for you?

We audit your site for free first. Send the URL and we will tell you where it is losing ground and what to fix in what order.