Who this is for, and what the key points are
This article is written for owners or executives of companies who have just learned that customer data has been leaked — whether through hacking, an employee sending a file to the wrong person, a lost device, or a problem in a third-party provider's system.
There are 3 key points.
- The clock starts running from the moment you become aware of the incident. The data controller must notify the Office of the Personal Data Protection Committee (PDPC) without delay, within 72 hours of becoming aware of the incident as far as practicable, unless there is no risk to the rights and freedoms of individuals.
- You must assess the risk before deciding whether to notify or not, and record the reasoning.
- Do not delete or wipe systems to make the matter go away quickly. Evidence is what makes a risk assessment possible and what proves the company fulfilled its duties.
For preparing your systems for the PDPA before an incident occurs, see PDPA compliance checklist for businesses. This article focuses specifically on the period after an incident has occurred.
What is the difference between a data controller and a data processor, and who has to notify?
| Role | Who they are | Duty when data is breached |
|---|---|---|
| Data controller | The party that determines the purposes and methods of the data use, for example a company that keeps its own customers' data | Assess the risk, notify the สคส. (PDPC — Office of the Personal Data Protection Committee), notify the data subjects, and remedy the incident (Section 37 (4)) |
| Data processor | A party that works with the data on the instructions of, or on behalf of, the controller, for example a cloud service provider, a CRM system, or a payroll accounting firm | Notify the data controller of the incident that occurred, and put security measures in place (Section 40) |
The point business owners often miss is thinking that if the data sits on a service provider's system, the provider has to handle it. In fact, the duty to notify the สคส. and the data subjects still belongs to the company as the controller, even if the root cause lies with the service provider.
The Committee's notification also requires that, where a controller uses a processor, the contract must stipulate that the processor notify the controller without delay within 72 hours from the time the processor becomes aware of the incident. If your contract does not yet contain this clause, it should be added once this incident has passed.
First steps to take when you learn that data has been breached
The sequence below is the practice we recommend, based on the legal duties set out in each item.
Step 1 — Assign a responsible person and start logging the time
Appoint one coordinator, and immediately record who learned of the matter, when, and through which channel, because the time of "becoming aware of the incident" is the starting point for counting the notification deadline. The Committee's notification treats the controller as having to investigate once it receives preliminary information from anyone at all, whether verbally, in writing, or by email.
Step 2 — Stop the damage, but preserve the evidence
What you should do
- Revoke the rights of the account that was used, change passwords and API keys, and isolate the suspected devices or systems from the network.
- Back up the logs of the servers, applications, firewalls and email before the system overwrites them.
- Take screenshots, keep the relevant emails or messages, and note who has already done what to the system.
What you should not do includes installing new systems over the top, deleting files that were modified, or rushing to shut down every service without first backing up the data for forensic purposes. The Committee's notification requires the controller to prevent, stop or remedy the matter immediately and to the extent that it can when there is a high risk; preserving evidence does not conflict with this duty.
Step 3 — Contact the relevant service providers and partners
Notify your cloud, hosting or CRM provider, or your system developer, immediately, and ask them to send you the logs and an incident report in writing. Ask at least what type of data, whose data, how many people, during what period it was leaked, and whether the vulnerability has been closed yet. If you have a cyber consultancy firm, bring them in at this step. As for cyber insurance (if you have it), you should read the conditions for notifying a claim in time, because some policies require you to notify the insurer before hiring experts.
Step 4 — Assess the risk to the data subjects
Clause 12 of the Committee's notification requires the controller to consider these factors:
- The nature and type of the breach (confidentiality, integrity or availability of the data).
- The type of data involved, such as ID card numbers, financial data, health data, passwords.
- The volume, both the number of data subjects and the number of records.
- The status of the data subjects, such as children, persons with disabilities, or vulnerable persons.
- The severity of the impact that has occurred or may occur, and the effectiveness of the measures used to stop the incident.
In cases falling within "no risk" under the notification — for example, where the data cannot identify a person, or the data is in a state that cannot be used because sufficient technological measures are in place (such as appropriate encryption with no leak of the key) — the controller must be able to prove it, and may have to submit documentary evidence for the Office to consider. Concluding on your own that "there is probably no risk", without records, is therefore risky.
Step 5 — Decide on notification and notify in time
See the next section. If your assessment shows that notification is required, prepare the details required by the notification to the extent that you have them at that time. You do not have to wait until every piece of information is complete before notifying, because the notification uses the wording "to the extent that it can be done".
Step 6 — Report to the police and contact the authorities if it was a hack or an attack on the system
Accessing a computer system or computer data that has protective measures in place, without authorisation, is an offence under the Computer Crime Act (Section 5 and Section 7 of the Computer Crime Act). The company can therefore report the matter as an injured party, attaching the logs, the timeline and the expert's report. Reporting to the police is a separate matter from the duties under the PDPA; they do not substitute for each other, and the Committee's notification also states that notifying the PDPC Office does not release you from duties under other laws relating to your business.
Step 7 — Communicate with customers
See the section "How to notify customers" below.
Step 8 — Review and fix the root cause
The Committee's notification requires the controller to take the necessary and appropriate measures to stop, respond to, remedy and recover from the incident and to prevent it from recurring, including reviewing its security measures. You should write an internal incident report every time.
When must you notify the PDPC Office (สคส.) and when must you notify customers?
สคส. is the Office of the Personal Data Protection Committee.
| Situation | Legal duty |
|---|---|
| No risk of affecting a person's rights and freedoms | No need to notify the PDPC Office, but it must be possible to prove that there is no risk |
| There is a risk | Notify the PDPC Office without delay, within 72 hours of becoming aware of the incident, as far as practicable |
| There is a high risk | Notify the PDPC Office and notify the affected data subjects, together with remedial guidelines, without delay |
The source is Section 37 (4) and clauses 5 to 10 of the Committee's notification.
What must the notification to the PDPC Office contain? Clause 6 requires notification in writing or through an electronic method prescribed by the Office, stating, as far as practicable:
- Brief information about the nature and type of the breach, which may describe the number of data subjects or the number of records
- The name and contact channels of the DPO or the person the company has assigned to coordinate
- The impacts that may occur
- The measures used or to be used to prevent, stop, correct or remedy
For the submission channel in practice, check the PDPC Office website before every notification, because the Office is the one that prescribes the method.
If you notify later than 72 hours, clause 7 allows you to ask the Office to consider granting an exemption from liability, where there are necessary and unavoidable reasons, such as having to conduct a preliminary investigation or prevent or stop the incident first. You must explain the reasons and notify as soon as possible, not exceeding 15 days from becoming aware of the incident. The Office may request further clarification afterwards. This is a request for an exemption, not an automatic right, so you should always notify on schedule and add details later.
How to notify customers: what to say and what not to say
When the risk is high, Clause 10 of the notification requires the message to data subjects to contain at least brief information about the nature of the incident, contact details for the DPO or coordinator, the possible impacts on them, and remedial measures, together with recommendations on what they can do themselves, such as changing passwords or being wary of phone and email scams.
If individual contact is not possible, Clause 11 allows notification on a group basis or general notification through public media or online media, but it must not cause additional harm to data subjects.
Communication practices (not legal requirements)
- Should say confirmed facts, what type of data is involved, what the company has already done, what customers should do, and contact channels that actually respond.
- Should not say speculate about the cause or perpetrator before investigation results, downplay severity with wording such as "unlikely to have any impact" without evidence, shift blame to a service provider in a letter to customers, or promise compensation before liability is assessed.
- Make the message to customers and the notification to the PDPC (สคส.) consistent. Conflicting information creates problems later.
- Use plain language, send via channels customers trust, and be careful that the incident notification itself does not become an opportunity for scammers to imitate.
What Are the Penalties for Failing to Notify?
A data controller that fails to comply with Section 37, which includes the duty to notify an incident under subsection (4), is subject to an administrative fine of not more than three million baht under Section 83. That is the ceiling, and it is assessed according to the circumstances of each incident.
Do not confuse this with the five-million-baht ceiling found in some sources. That ceiling belongs to Section 84, which deals with sensitive data and cross-border transfers, not the duty to notify. But if the leaked data is sensitive data, such as health data, other issues may also arise.
As for a data processor that fails to comply with Section 40 without reasonable cause, it is likewise subject to an administrative fine of not more than three million baht under Section 86. In addition to fines, Section 77 also requires a controller or processor that breaches the law and causes damage to the data subject to pay compensation, even if there was no intent or negligence, unless it can prove an exception provided by law. See the overview at PDPA Law Update for Thai Businesses 2569.
Do We Also Need to Notify the NCSA?
Only companies that are Critical Information Infrastructure (CII) organizations as designated by the supervisory authority are subject to this. When a significant cyber threat occurs against their systems, Section 57 of the Cybersecurity Act B.E. 2562 requires a report to the National Cyber Security Agency (NCSA) and to the controlling or supervisory agency. This is a duty separate from the PDPA and must be carried out alongside it.
General companies that are not in the CII group do not have this duty under that Section. However, those in sectors with a dedicated regulator, such as finance or telecommunications, should additionally check the rules of that agency.
Checklist for the First 72 Hours
- Record the time the incident was discovered and its source; appoint a coordinator.
- Suspend irregular access; change passwords and keys.
- Back up logs and evidence before wiping or reinstalling systems.
- Notify service providers and processors; request a written report.
- Identify the types of data, number of data subjects, and data subject groups.
- Assess the risk according to the factors in the notification, and record the rationale.
- If there is risk, notify the PDPC (สคส.) based on the information available; if there is high risk, prepare a message to the data subjects.
- If hacked, file a police report and keep supporting documents.
- Check whether it is CII or under a specific regulator.
- Prepare an incident report and remediation plan, including amending contracts with processors.
