Skip to content
+66 93 004 4098 Get a quote
Get a quote Call +66 93 004 4098

PDPA and compliance

A PDPA audit checklist for your website, from cookies to breach response

Six groups of checks you can run on your own website with a browser and the admin panel, from the cookie banner to breach response.

By Website Development Bangkok team, reviewed by Litesh DhirPublished 6 min read
Cover image for this guide: Checklist

What does a PDPA website audit check?

A PDPA audit of a website comes down to one question: does the site handle personal data the way your privacy notice says, and the way Thailand's Personal Data Protection Act requires? You can answer most of it yourself in an afternoon with a desktop browser, access to your website admin panel, and a notepad.

The checks below fall into six groups, starting with what visitors see (banner and forms) and working down to what they do not (storage, access, breach plans). Work through them in order, note every failure, and fix the visitor-facing problems first because they are the easiest for anyone to spot. This is a do-it list, not a legal explainer; if you need the background first, read our overview of what the PDPA law asks of websites. For legal judgement calls, such as your lawful basis for a particular use, involve a Thai lawyer.

1. Map where your site collects data

You cannot audit what you have not listed. Open a spreadsheet with four columns: collection point, data collected, where it goes, who can see it. Then walk the site page by page, on mobile and desktop, in both languages if you have them. A hotel website or a clinic website may turn up a forgotten booking widget on an old campaign page; a shop may find a second newsletter form in the footer.

  • FormsContact, quote, booking, job application and newsletter forms. Note every field and whether it is required.
  • Checkout and accountsCustomer accounts, order forms, delivery addresses and payment steps on a shop.
  • Tracking scriptsAnalytics, Meta Pixel, TikTok Pixel, Google Ads tags, heatmaps and session recording tools.
  • Chat and messagingLive chat widgets, WhatsApp and LINE buttons, and any chatbot that stores conversations.
  • Embedded contentYouTube videos, Google Maps and social feeds, which can set their own cookies.
  • Server logsHosting and security plugin logs that record IP addresses.

2. Cookies and the consent banner

A common failure is a banner that looks right while tracking scripts load anyway. Test it properly: open the site in a private window, open the browser's developer tools (F12 in Chrome), and look at the Application tab under Cookies and the Network tab before you touch the banner. Anything from analytics or advertising domains that appears at that point fired before consent.

If the banner is the weak point, a dedicated PDPA consent platform can block scripts until the visitor agrees and log each choice.

  • Nothing optional before consentOnly strictly necessary cookies appear before the visitor chooses. Recheck after clearing cookies.
  • Accept and reject are equalRejecting is as easy as accepting, on the first layer, with buttons of similar weight.
  • Categories are realAnalytics and marketing can be switched on and off separately, and the switches actually change what loads.
  • Choices are remembered and reversibleThe banner does not reappear on every page, and a settings link lets visitors change their mind later.
  • Both languagesThe banner shows in Thai on Thai pages and English on English pages.
  • Consent is loggedThe tool keeps a record of who agreed to what and when.

3. Forms and the privacy notice

Forms are where visitors knowingly hand you data, so they deserve a slow check. Submit each one yourself with test details and follow the entry to wherever it lands: the inbox, the admin panel, a CRM or a spreadsheet. Then read your notice side by side with what you just saw. If the notice needs rewriting, our guide to writing a PDPA privacy policy for your website gives a section-by-section outline.

  • Only the fields you needRemove fields you never use. A quote form rarely needs a date of birth or ID card number.
  • Notice linked at the formA short line near the submit button says why you collect the data and links the privacy notice.
  • Separate marketing consentNewsletter or promotion consent is an unticked checkbox, not bundled into the enquiry.
  • Notice is complete and datedIt covers purposes, data, retention, recipients, your contact details and rights, with an effective date.
  • Notice matches realityEvery tool found in group 1 appears in the notice, and nothing listed there is out of date.

4. Third parties and data leaving Thailand

Take the "where it goes" column from your map and turn it into a list of processors: every company that stores or handles personal data on your behalf. For each one, find where its servers are and what its terms say about data protection. Sections 28 and 29 of the Act set conditions for transfers abroad, and most website tools store data outside Thailand. If you also serve European customers, our PDPA and GDPR comparison shows where the two regimes line up.

  • Processor list existsHosting, email delivery, analytics, payment gateway, couriers such as KEX Express (formerly Kerry Express) or Flash Express, CRM and chat.
  • Agreements in placeEach processor has terms or a data processing agreement covering security and confidentiality. Save a copy or link.
  • Server locations knownYou know which country each service stores data in, and your notice mentions transfers abroad.
  • Nothing unexpectedNo abandoned tools still receive data, such as an old email marketing account or a trial chat widget.

5. Storage, access and security

Section 37 of the Act requires controllers to keep appropriate security measures. On a website that starts with a few plain checks in the admin panel and at your hosting account. Log in and look at who else can.

  • Admin accounts reviewedEvery user account belongs to a current person. Former staff and agencies are removed or downgraded.
  • Strong sign-inAdmin accounts use unique passwords and two-factor authentication where the platform supports it.
  • HTTPS everywhereEvery page, including forms and checkout, loads over HTTPS with no mixed-content warnings.
  • Updates currentWordPress core, themes and plugins, or Shopify apps, are up to date, and unused plugins are deleted.
  • Backups workBackups run automatically, are stored away from the server, and one has been restored as a test.
  • Retention appliedOld form entries and abandoned carts are deleted on a schedule that matches the retention periods in your notice.

6. Breaches, requests and records

This group is about being ready rather than about the site's code. Under Section 37(4), a controller must notify the PDPC of a personal data breach without delay and, where feasible, no later than 72 hours after becoming aware of it, unless the breach is unlikely to put people's rights and freedoms at risk.

Where the risk is high, the affected people must be told too. Section 39 covers records of processing, and Section 41 sets out when a data protection officer is required. Check the PDPC's current notifications, because some duties are relaxed for smaller businesses.

Gaps here carry the heaviest consequences; we cover them in our summary of PDPA penalties and fines.

  • Breach plan writtenOne page saying who decides whether a breach is notifiable, who contacts the PDPC, and where the hosting and developer contacts are.
  • Request channel worksThe email or form named in your notice for rights requests is monitored, and someone knows how to find, export or delete a person's data.
  • Records keptA simple record of what data the website processes, why, and where it goes. Your map from group 1 is a good start.
  • DPO question answeredYou have checked whether Section 41 applies to you, and noted the answer and the reason.

After the audit

You will likely end up with a list of ten to thirty items. Sort them into three piles:

  1. Fix this week: trackers firing before consent, forms with no notice link, former staff with admin access, missing HTTPS.
  2. Fix this month: rewriting the notice, adding retention clean-up, collecting processor agreements, writing the breach plan.
  3. Schedule: a repeat audit after every significant site change and at least once a year.

Some fixes are content work you can do in-house. Others, such as rebuilding a banner so it truly blocks scripts or adding consent logging to forms, need a developer. If you want that part handled, our PDPA website audit and fixes cover cookie consent, the privacy notice page and consented forms, and maintenance after launch is priced per site on request. If the audit shows the site needs rebuilding rather than patching, send us the address for a website development quote. Related guides are collected under PDPA and website compliance.

Share this page

More on PDPA and websites

Sources

Litesh Dhir, co-founder of Website Development Bangkok
Reviewed by Litesh DhirCo-founder, SEO and web development

Builds and ranks the websites: the systems behind the 17 client sites whose Search Console numbers we publish. This guide was written by the Website Development Bangkok team. More about us

Common questions

How often should I audit my website for PDPA?

Run a full audit at least once a year, and a shorter check whenever the site changes how it handles data: a new form, booking tool or plugin, a new analytics or advertising tag, a change of hosting or email provider, or a redesign. Redesigns are the riskiest moment, because old scripts and forms often survive on pages nobody remembers to review.

Can I run a PDPA website audit myself?

Yes, most of the checks need only a browser, the developer tools built into it, and access to your admin panel and hosting account. Where you may need help is in fixing what you find, such as making a banner block scripts properly, and in legal judgements such as choosing a lawful basis or drafting notice wording, which a Thai lawyer should review.

Do small businesses need a Data Protection Officer?

Not automatically. Section 41 requires a DPO mainly where core activities involve regular, large-scale monitoring of people or large-scale processing of sensitive data, or where the controller is a public authority. Many small shops, restaurants and service firms fall outside that, but a clinic handling health data may not. Check the PDPC's current rules and record your reasoning either way.

What should I do if my website has a data breach?

Contain it first: change admin passwords, remove the compromised plugin or account, and ask your host for logs. Then assess what data was exposed and whose. Section 37(4) requires notifying the PDPC without delay and, where feasible, no later than 72 hours after becoming aware, unless the breach is unlikely to create risk. If the risk to people is high, inform them as well. Keep notes of every step.

Which free tools help check the cookies on my site?

Your browser already has the main one. In Chrome or Edge, press F12, open the Application tab and look under Cookies, then check the Network tab for requests to analytics and advertising domains before you answer the banner. Firefox has the same features under Storage. Repeat the test in a private window after rejecting all optional cookies to confirm nothing still fires.

Tell us about your website

Send a few lines on WhatsApp or through the quote form. You get a written quote with the scope, timeline and price for your project.

Get a quote

Or WhatsApp or call +66 93 004 4098, every day, 10:00 to 19:00 ICT. service@websitedevelopmentbangkok.com

WhatsApp Call