Ransomware Has Hit: What Three Thai Laws Require, and in What Order

Ransomware differs from other breaches in one important way. The first problem is not "who has seen our data" but "we cannot open our own data". Sales, accounting and customer files are encrypted and unusable, and everyone in the room asks the same question: how fast can we restore?

While IT restores, at least three Thai laws are engaged, each looking at the same event from a different angle. The Personal Data Protection Act sees a personal data breach. The Cybersecurity Act sees a cyber threat. The Computer-Related Crime Act sees a company that is the victim of a criminal offence.

If data is locked but not stolen, is it still a breach?

Yes. Clause 4 of the Personal Data Protection Committee's 2022 Notification on breach notification sorts breaches into three types, and the third is written precisely for data that cannot be accessed.

Many organisations assume that if forensics finds no sign of data being copied out, nobody needs to be told. This clause says that view is incomplete. Customers or staff who cannot reach the company, cannot obtain their own records, or cannot get a service are exactly the kind of impact that must be assessed.

If the investigation later shows the attacker also copied data, the same incident becomes a confidentiality breach under clause 4(1) as well. Clause 4 itself says one incident may involve more than one type. Keep both possibilities open until the facts are known.

How has the PDPC Office assessed ransomware?

The PDPC Office's Breach Risk Assessment and Notification Guide, version 1.0, has one ransomware example, number 4, and two others that show where the availability line falls. The guide is guidance, not law, but it is the regulator's own written view. It exists only in Thai, so the original is quoted.

In short: a controller's personal data was entirely encrypted by ransomware and there was no backup, so the data could not be accessed or used. Because the data identifies people, is no longer available, has no backup, and the incident may harm both the business and the individuals, it must be notified.

Side by side, the line becomes clearer. Example 3 needs no notice because the cause was an ordinary outage and the data came back on its own. In example 8 the system also came back, but the cause was an attack and the data was health data, so the Office said to notify.

If we have backups, can we skip notifying the PDPC Office?

The guide does not answer that directly. Example 4 cites "no backup" as one reason to notify, but no example says that having a backup removes the duty, and example 8 shows that a system restored later can still require notice when the data is sensitive and the cause is an attack.

So the conclusion the texts support is narrower than many hope. A backup you can restore quickly lowers severity under the clause 12 factors of the 2022 Notification, but it does not end the assessment. To stay silent, the controller must still be able to show there is no risk to people's rights and freedoms.

As for having backups before anything happens: the PDPC's 2022 Notification on security measures does not use the word "backup", but it requires measures that keep personal data available in proportion to the risk. A system that goes down with no way back is hard to defend as an appropriate measure.

What does each law require, and in what order?

The three laws do not conflict; they address different people. The PDPA applies to every data controller. The Cybersecurity Act puts reporting duties on State agencies and critical information infrastructure (CII) organisations. The Computer-Related Crime Act defines the attacker's offences.

Filing with the PDPC Office does not close the matter. The 2022 Notification says plainly that duties under other laws remain. Organisations that are CII, or that sit under a sector regulator, need to check their own reporting channel separately.

If you are a CII organisation

Section 57 sets no hour limit in the Act itself and lets the Cybersecurity Regulating Committee prescribe reporting rules. If you are unsure whether you are CII, the tests are in our CII article.

If you are neither CII nor a State agency

An ordinary private company has no reporting duty under section 57 or section 58 paragraph one. But section 58 paragraph two lets any organisation or person ask the NCSA Office for help, which matters for SMEs without an incident response team of their own.

If your service provider is hit, who notifies whom?

Ransomware does not have to strike the company's own machines; it can hit a payroll provider, an ERP vendor or a web host processing data on its behalf. The company is still the data controller and is still the one that notifies the PDPC Office.

A common gap is a vendor contract with no such clause, or one that does not say who gets told and how. If the vendor reports late, the company learns late and responds late, and it must still be able to explain when it became aware, because the PDPA's 72 hours run from that point. Check your contracts against our processor agreement guide.

Where does the Computer-Related Crime Act come in for a victim company?

The Computer-Related Crime Act does not tell victims to report to anyone. But encrypting someone else's data and knocking their systems offline falls within sections 9 and 10, each punishable by up to five years in prison, a fine of up to 100,000 baht, or both.

The practical consequence: if the company may later want to press charges or claim damages, it needs evidence of what happened. Machines wiped and reinstalled straight away may destroy the traces that prove it. Criminal procedure sits in laws outside our library, so this article does not cover how to file a complaint.

A working sequence from the moment the ransom note appears

The order below is the AIPDPA team's arrangement, with each step tied to the relevant text. The timings are practical targets, not legal deadlines, except for the PDPA's 72 hours.

1. Isolate infected machines and systems from the network and disconnect backup storage so it is not encrypted too (2022 breach Notification, clause 5(2)).
2. Write down the time you became aware; the 72-hour window under PDPA s.37(4) runs from here.
3. Preserve evidence before wiping: the ransom screen, system logs, disk images. If you are a service provider under s.26 of the Computer Crime Act, do not delete traffic data you must keep.
4. Assess whether this is availability only or also exfiltration, and whether sensitive data is involved.
5. If you are CII, report to the NCSA Office and your regulator under Cybersecurity Act s.57; if not and you need help, ask under s.58 paragraph two.
6. Notify the PDPC Office within 72 hours if there is risk, and the individuals if the risk is high.
7. Restore from backups verified to be clean, then review your measures under clause 5(5) of the 2022 Notification.

In AIPDPA, the breach register counts 72 hours from the time you record awareness, compares the incident with PDPC examples 3, 4 and 8 to show which it is closest to, and produces the letters to the PDPC Office and to individuals, with a named person confirming every decision.

The best backup is one the attacker cannot reach and that you have actually restored from in a test. The law prescribes no format, but the security measures Notification points to standards accepted in your type of business. For one set of controls that answers both the PDPC and the NCSA, see our security checklist.

Who stands behind this guide?

Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel

Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)