PDPA and Data Breaches From Outdated Websites: The 72-Hour Notification and the Evidence You Need Beforehand

Picture your own office. The front door still uses the same lock that was installed the day you moved in. One day the lock manufacturer announces that this model has a weakness: certain tools can open it in a few minutes, and a fixed version is available as a replacement. That announcement goes to the email of the installer, who stopped working with your company last year.

Six months later, a customer document cabinet in the office is broken into. The people who walk in to ask about it all have the same set of questions. Was the door locked? Which lock model was it? Did you know there was an announcement to replace it? And did anyone write down when the door was last inspected?

A corporate website that hasn't been updated in a long time is in the same condition as that door. The content management system, the plugins and the programming language it runs on all have vulnerability announcements and fixed versions released from time to time. If customer data ever leaks from the website, the one asking that same set of questions is the Personal Data Protection Act, or PDPA, in very similar terms: did the organization have appropriate measures, did it review those measures when technology changed, and did it report the incident in time?

This article is written for executives and system administrators of organizations whose websites collect customer data, whether through a quotation request form, a membership system or a partner portal. It covers what the law looks at if data leaks from the website, how the clock is counted, and what evidence you need to have in place before that day, because this evidence cannot be created retroactively.

Try answering these five questions first. It takes less than ten minutes

You don't need to open any code. Just ask yourself or the team that looks after the website, and count how many you can answer immediately with evidence.

• What system does our website run on, which version, and when was it last updated? Can you answer with a date?

• Who currently holds admin-level passwords, including former freelancers or employees who have since left?

• Where is the data customers enter through forms stored, and who can open it?

• When was the last backup made, and have you ever actually tried restoring from it?

• If the web team spots something abnormal at 2 a.m. on a Friday night, whom in the organization do they call?

If you can answer all five, your organization is in a better position than you may have thought. If you can answer fewer than half, that doesn't mean you are breaking the law. It just means that if you ever have to explain yourself to a government agency, you would be starting to look for the answers from zero, within a window the law gives you of only about three days.

Where the law addresses this

Section 37(1) speaks of review when technology changes

The sentence people tend to skip is in Section 37(1) of the Personal Data Protection Act B.E. 2562 (2019). The provision requires the personal data controller, meaning the organization holding customer data, to provide appropriate security measures to prevent the loss of, unauthorized or unlawful access to, use, alteration, modification or disclosure of personal data, and then adds that those measures must be reviewed "when necessary or when technology has changed."

Read through a web developer's eyes, that sentence matches software updates almost word for word. The day a system's developer announces a vulnerability and releases a fixed version is the day the technology around your website has changed. Measures that were appropriate three years ago may no longer be appropriate if no one goes back to review them.

I should also say here that the law does not specify how many days between updates, or which software version you must run. What counts as appropriate is judged case by case. So I won't claim that a website not updated for a year is already unlawful. What I can say with confidence is that if you ever have to explain yourself, the answer "we didn't know a new version had come out" carries the least weight in the room.

When does the 72 hours start counting?

Section 37(4) of the same law requires notification of a personal data breach to the Office of the Personal Data Protection Committee, or PDPC, without delay and within 72 hours of becoming aware of the incident, where feasible, unless the incident is unlikely to result in a risk to the rights and freedoms of individuals. If the risk is high, the data subjects must also be notified, together with remedial measures, without delay.

The method of notification is detailed in the Notification of the Personal Data Protection Committee on Criteria and Procedures for Notification of a Personal Data Breach B.E. 2565 (2022), published in the Royal Gazette on 15 December 2022. Clause 6 of the notification requires that the report to the PDPC cover four essential points, as far as possible: the nature and type of the breach, which may include the number of data subjects or records involved; the name and contact details of the data protection officer or a coordinator; the likely consequences; and the measures used or to be used to prevent, stop, correct or remedy the damage.

Read these four points again and imagine having to answer them within three days. You will see that almost every one needs information that should already exist before an incident. To say how many records leaked, you must first know what the system stores and where. To say what measures were in use, you must have records of what was done up to that point.

An outside web team has its own clock too

Many organizations hire a company or a freelancer to look after their website. In legal terms, these people are personal data processors. Section 40(2) requires the processor to have appropriate security measures as well, and to notify the controller when an incident occurs. Clause 8 of the 2022 notification states explicitly that the agreement or contract between the two parties must require the processor to notify the organization without delay and within 72 hours of the processor becoming aware of the incident.

I wrote separately about rights in the code and what you should receive at handover in our article on who looks after the system after handover and what to ask before signing a contract. Here I'd like to invite you to check just one thing: does the website maintenance contract your organization holds today include a clause on notifying incidents within 72 hours?

Every section and clause of the notification cited in this article I have read directly from the full text of the law and notification linked here. But we are a web and systems team, not a law firm. If you need an answer for your organization's specific case, you should ask the PDPC or a lawyer who handles this area directly.

Why a website that isn't updated is the first door to be tried

Verizon's 2026 Data Breach Investigations Report, which collected global incidents from 1 November 2024 to 31 October 2025, found that 31% of data breaches began with a software vulnerability, and that vulnerabilities rose to become attackers' number one way in, ahead of the use of stolen passwords.

That figure is a global picture. I could not find a separate figure for Thailand alone, or for Thai corporate websites specifically, from a source that can be opened and checked, so I don't want you to read this as meaning every Thai website is like this. What the figure does tell us is that, in the year the report covers, software vulnerabilities were the way in that attackers used most often.

As for why old websites get tried first, web developers see this as routine. Vulnerability announcements are public information. On the day a developer says which version has a problem, anyone who intends to break in reads the same announcement and uses automated tools to hunt for sites still running that version. So an unmaintained corporate website doesn't need to be anyone's special target. It only needs to be on the list the tools happen to find.

If you want to know what other warning signs your website may show, such as speed, downtime and backups, I've gathered them in our article on why Maintenance & Support matters for a business website.

In the real case where the PDPC imposed a fine, what did it look at?

On 21 August 2024, the Ministry of Digital Economy and Society announced that Expert Committee No. 2 had issued an administrative fine totaling 7 million baht against a large private company selling goods online, after the personal data of more than 100,000 customers leaked to call-center scam gangs. The Ministry's news release said this was the first administrative fine order against a large private company by this committee.

What is interesting for people who look after websites is the reasoning in the order. The release lists three violations: the company had no data protection officer as required by Section 41, did not have appropriate security measures as required by Section 37(1), and reported the incident to the PDPC late under Section 37(4).

Two of those three are Section 37, which we've been discussing from the start, and both are things that must be prepared before an incident occurs.

Besides the fine, the order also required the company to improve its security measures, train its employees, add measures to keep pace with changing technology, and notify the PDPC of its corrective measures within 7 days of receiving the order. Read that list carefully and you will see these are things an organization can do itself starting today, without waiting for an order.

If you'd like an overview of the penalties under each section, I summarized them in PDPA and Business Websites: Is Your Contact Form Asking for Consent Correctly?. For Section 37 specifically, Section 83 of the law sets an administrative fine of not more than three million baht.

"Our website just has a contact form. What is there to steal?"

I hear this question often, and part of it is genuinely true. A corporate website with only a company introduction page and a contact form holds far less data than an online store with a membership system of hundreds of thousands of accounts, and the law itself doesn't treat every incident equally.

Clause 9 of the 2022 notification gives an organization room to claim an exemption from notifying the PDPC if it can prove that the incident poses no risk to the rights and freedoms of individuals, for example where the leaked data cannot identify anyone, or the data is in an unusable state because of adequate technological measures. Clause 7 allows an organization to request an exemption from liability for notifying later than 72 hours if there is an unavoidable necessity, provided it explains the reasons to the PDPC and notifies no later than 15 days after becoming aware of the incident.

Put simply, the law leaves room for organizations that have worked carefully.

But look at the conditions of those two exemptions. Clause 9 asks the organization to submit documents or evidence about its security measures for consideration. Clause 7 requires an explanation of the reasons and details of why the report was late. Every way out that the notification opens passes through evidence the organization already has.

Another point that is often overlooked: the contact forms on B2B websites often hold more than a name and phone number. Many contain a partner company's name, job title, budget, or details of a project that hasn't been made public. This information may not cost anyone money right away, but if it leaks, partners will always remember where it leaked from, and for a business that sells to other organizations, that memory costs many times more than a fine.

Evidence that cannot be created retroactively

Back to the office door once more. If you change the lock today, the door is safer from today. But a record saying you inspected the door last month can never be written retroactively and made real.

Evidence of a website's security measures works the same way. A dated update history, backup logs, or a list of people whose admin rights were removed when they left carry weight only if they were recorded when they actually happened. The sooner you start keeping them, the longer the history, and the better you can answer the question about reviewing measures when technology changes with facts instead of explanations.

Something else builds up alongside it: familiarity. An organization that has rehearsed restoring from backup a few times knows how many hours it takes, who needs to be in the room, and which documents to reach for. That knowledge is worth a great deal on the day the 72-hour clock starts, because every hour not spent working out who holds the passwords is an hour you can spend verifying the facts.

The minimum file a corporate website should have

You don't need to start with a big system. Start with one file that can answer the five questions at the top of this article. From what I've seen in system maintenance work, there should be at least these six things.

A software register for the website. The content management system, plugins, programming language version and server services in use, with the last update date of each. If your web team can produce this within a day, that's a good sign.

Update records and reasons. If a fixed version has been released but not yet installed, note why and when it will be installed. Sometimes the reason is entirely sound, such as needing to test first because another plugin might break. A record like this is the most tangible trace of a review of measures under Section 37(1).

A list of high-privilege accounts. The website admin accounts, hosting accounts and domain accounts, reviewed every time someone joins or leaves the team.

Backup records and restore drill results. Record both the date of the backup and the date you tried a restore, along with the time it took, because a backup that has never been restored cannot tell you whether it really works.

Back-office access logs. Who looked at customer data and when, kept somewhere separate from the website itself, so that someone who breaks into the site cannot easily erase their traces.

An incident contact chart. Who decides to notify the PDPC, who drafts the message to customers, the after-hours contact number for the web team, and the clause in the contract requiring the web team to report incidents within 72 hours.

If data from your forms still flows into a shared inbox or a spreadsheet whose link is shared across the whole company, the last two will be very hard to do. I wrote about organizing a back-office system in our tips for setting up a back-office system in 2026, and if you'd like to see an example of a system that separates user permissions and keeps access logs, see the business systems page for systems TumWebSME builds for clients.

You can start this month

These five steps can be completed in about a month, with no new budget, using only the time of people in your organization and the web team you already have.

1. Ask your web team for a list of all software and versions, with the last update date of each.

2. Go through the admin account list, close the accounts of people who no longer work on the website, and record the date each was closed.

3. Ask the team to try restoring the latest backup to a test machine and note how long it takes.

4. Open your website maintenance contract and check whether it has the 72-hour incident notification clause per Clause 8 of the 2022 notification. If not, talk to your contractor about adding it.

5. Write a one-page incident contact chart, send it to everyone named on it, and schedule a review of the whole file on a regular cycle, for example every quarter.

How do you know you're on the right track?

The simplest way to measure is to go back to the five questions at the start. The first time, it may take several days to get complete answers. If next round you can answer within ten minutes, with evidence you can show, the file is working.

Another number that tells you a lot is the gap between the date a fixed version is released and the date it is actually installed on your website, which you can see from the update records you've started keeping. There is no fixed figure for how short it must be, but it should get shorter, or at least have a reason noted each time it runs long.

You should also record the time each restore drill takes so you can compare rounds. If it keeps getting shorter, and the people who need to be in the room know their roles without asking, then on the day a real incident happens your organization will have time left over for things that matter more than hunting for passwords.

Closing thoughts

Back to that office door one last time. Nobody expects every door in the world to be one hundred percent theft-proof. What the people asking want to know is only whether the owner cared enough to look after it, knew which lock model had a problem, and wrote down what was done. PDPA asks your organization's website the same questions, only in legal language, and gives you just 72 hours to answer.

If your organization can't yet answer all five questions above, there's no need to feel you have been negligent all along. Most organizations start from exactly here. Get in touch and tell us what system your website runs on, who looks after it, and what channels you use to collect customer data, and we'll help work out which part of the file to start with.

Follow TumWebSME

Follow us for tips on websites and online marketing at:

• Facebook: TumWebSME รับทำเว็บไซต์ธุรกิจ

• Instagram: @tumwebsme

• TikTok: @tumwebsme

• YouTube: TumWebSME

Contact us about our services

• 088-983-9386 (Khun Ploy)

• 099-856-3198 (Khun Saennan)