Administrative fines by Thailand's Personal Data Protection Committee, as reported by the press, point to duties not performed rather than hacking technique. This article turns the duties under sections 41(2), 37(1) and 37(4) into evidence an IT team can prepare.
News about data leaks usually follows the same order: who was breached, what data got out, and how many people were harmed. But when the Personal Data Protection Committee Office (known in Thai as สคส.) issues an administrative fine order, what appears in the order is not hacking technique. It is a list of duties the organization did not perform.
This article is written from the viewpoint of a team that designs and delivers systems, and it is not legal advice. We read the fine orders as the press reported them, then translate the duties cited into evidence a system must be able to show when asked, so that IT teams know what a regulator looks for before an incident happens.
The orders we could read, and the limits of the information
The sources we could open are press reports. We did not open the PDPC's orders themselves.
The first case the press reported was a fine of 7 million baht on a large private company. Thairath reported on 21 August 2567 (2024) that the acting Minister of Digital Economy and Society made the announcement. The company fined was an unnamed online retailer, the data of more than one hundred thousand customers leaked to call-center scam gangs, and the report states it was the first administrative fine order against a large private company since the PDPA came into force (see the Thairath report). An article by Thai PBS drawing lessons from the same order lists three allegations (see the Thai PBS article).
Not appointing a data protection officer (DPO) although required to, under section 41(2).
Not having appropriate security measures, under section 37(1).
Being late in notifying the breach, under section 37(4).
Thairath further reported that the order required the company to improve its security measures, train staff, update measures to keep pace with technology, and report its corrective measures to the PDPC within 7 days of receiving the order. The report does not break the fine down by allegation and does not state the date of the order, only the date of the announcement.
Another report, by Thansettakij dated 1 August 2568 (2025), summarized that in fiscal year 2568 the PDPC issued administrative fine orders in 5 cases comprising 8 orders, and since the PDPA came into force a total of 6 cases and 9 orders, with fines totalling more than 21.5 million baht. Those fined included government agencies, private companies acting as controllers and processors, and an individual acting as a processor (see the Thansettakij report).
A caution about the numbers: the total in the report is cumulative. We did not find a figure for fiscal year 2568 alone stated directly, so we do not report one. Our search also found some outlets headlining the total as 21 million baht, which is probably rounded. If you will cite figures in an official document, use the PDPC's own announcement.
The reasons reported are not hacking technique
Thansettakij summarized the reasons for the orders in fiscal year 2568 in several points, which we can restate as follows.
Insufficient security measures, such as weak passwords, no risk assessment, and no periodic review of measures.
A government agency's web application was breached, leaking the data of more than 200,000 people, which was then offered for sale on the dark web.
A government agency had no data processing agreement with the system developer.
A system developer did not build security measures into the design and had no access control.
A hospital did not supervise a document-destruction contractor, so medical records leaked; the contractor kept documents at home and did not report the incident.
Failure to notify the PDPC of a breach and failure to appoint a DPO despite processing a large volume of data.
What stands out is that most of these are not questions of how the breach was done. They are questions of whether the organization performed its duties. Was there a risk assessment? A contract with the developer? Access control? Notification? This observation is our own opinion from reading the reports, not a conclusion of the PDPC.
From duties to evidence the system must show
We translate the duties cited into evidence an IT team can prepare. Each item is something an auditor or the legal team may ask to see. We do not claim the PDPC defined this list, and the list is not complete for every case.
Security measures (section 37(1)). Evidence an IT team can prepare: a dated risk assessment report; a list of systems holding personal data with their owners; the password and multi-factor authentication policy as actually configured; a list of people with administrator rights and the date of the last review; and records of periodic reviews of the measures. The report's wording about weak passwords, no risk assessment and no review of measures matches the first three items directly. We wrote about periodic access reviews in our article on managing access when the development team changes, and about sequencing security investment in our article on Zero Trust.
Breach notification (section 37(4)). Evidence an IT team can prepare: a written procedure saying who decides whether an event is a personal data breach, who notifies whom, and through which channel; and the detection that lets the organization know an incident happened. Without alerts, an organization may learn late because nothing told it, which we covered in our article on what alerts should wake someone up. The Thai PBS analysis we read explains that notification is required within 72 hours of becoming aware of the incident. We did not check that against the section itself, so we ask the legal team to confirm the figure.
Agreements with processors and system developers. The evidence is a signed contract or data processing agreement with each developer and service provider, stating what data they can access, what they may do with it, and within how many hours they must report an incident. That number can be agreed between the parties. This matches the case in the report of a government agency with no agreement with its system developer. The clauses that belong in a contract are covered in our article on conditions in a TOR, and maintenance contracts in our article on what to check before signing an annual maintenance contract.
Access control and traces. The evidence is logs showing who accessed personal data and when, kept for the agreed period, with personal data kept out of the logs as far as practical, as we wrote in our article on log retention. When an incident occurs, the logs are what answer what leaked and who accessed it.
Supervising contractors who touch data. The hospital case in the report shows that a contractor who is not an IT developer can also be a point of risk. The evidence is a list of every contractor who touches the data, the agreements with them, and how the organization checks they comply.
System developers are cited in the reports too
The item we would like development teams to read in particular is that, in the Thansettakij report, there is a system developer that did not build security measures into the design and had no access control. We do not know the details of that case, whether the developer was penalized, in what capacity, or by how much, and the report does not say. But the statement shows us that the developer side is not outside the matter.
From a developer's viewpoint, we think demonstrable security should be part of what is delivered, not an extra. For example, role-based permissions from the first release, logging of access to personal data, and documentation telling the client what the system does with the data. When the client is asked, their answer depends on what the developer delivered. We wrote about how a client can check this work before accepting delivery in our article on procuring a penetration test.
Test data and forgotten copies
All the evidence above concerns production systems, but personal data often leaks from places nobody counts as a system, such as a test database copied from the real one, an export file on one person's machine, or an old backup. We wrote about this separately in our article on real data versus test environments. If your risk assessment does not include these places, the assessment covers less than where the data actually is.
Limits we should state plainly
If your organization processes no personal data of customers or employees at all, which is very rare, the list of evidence above may not apply. But almost every organization with employees and customers already processes personal data. For a small organization with one system, a one-page document in place of a full report is a start, as long as it is dated and has an owner.
Also, the evidence list we propose is not criteria announced by the PDPC. It is meant to help IT teams prepare and does not guarantee an organization will pass an inspection. Whether your organization must appoint a DPO, whom you must notify of what, and which measures are sufficient are matters for your data protection officer and legal counsel to assess from your own facts.
Finally, we know only what the press reported, we do not know the details of the unnamed cases, and the number of orders may have changed since the latest report we read, dated 1 August 2568.
Objections we often hear
A common objection is that we are a small organization and unlikely to be inspected. There is something to this judging from the news, since the cases disclosed tend to involve large volumes of data: the reported figures are one hundred thousand and two hundred thousand people. But we have no data showing that small organizations are safe, and the hospital and contractor case in the report did not turn on data volume alone. Another reason we think evidence should be prepared is that enterprise customers already ask for it in vendor questionnaires, without waiting for the PDPC.
Another objection is that we hired an external developer to look after it, so responsibility is theirs. That depends on the contract and each party's role under the law, which we do not rule on. But the reports we read include both a body penalized for having no agreement with its developer and a developer cited over design. Each side has something it must be able to show. Passing the responsibility to the other is not evidence.
Where to start
List the systems, files and contractors that touch personal data, with owners as named people. Start by asking every department, not only IT.
Complete one risk assessment, dated, covering the systems on the list, even a short one.
Check whether you have an agreement with every developer and service provider. If not, prioritize and start with those who touch the most data.
Write a one-page notification procedure naming who decides, who notifies and through what channel, then rehearse it once with a made-up incident.
Have your data protection officer and legal team review the set of documents with a list of gaps, and set a date for the next review.
Summary
The PDPC fine orders as we read them point to duties not performed and not provable, not to the attacker's technique. If you take one thing from this article, ask your team: if someone asked tomorrow for evidence that we have security measures, what documents could we put on the table? The ones you cannot produce are what to do first.
If you would like to talk through the details of a project, you can reach us at 088-983-9386 or [email protected]. Our office is in Bang Kapi, Bangkok. For organizations still drafting a scope of work, we are glad to arrange a conversation to understand the problem first, without needing complete documents. And if we find that the problem is not yet at the point of needing a new system, we will say so plainly, because starting a project at the wrong time costs more than waiting another quarter.
FAQ: Frequently Asked Questions about This Article
A collection of questions and answers to help you better understand the content of this article.
Tags: