Whether encryption means you need not report a breach is answered by ten worked examples in the PDPC Office’s risk assessment guide: only two need no notification, since encryption helps only with confidentiality breaches. This is for DPOs and IT teams assessing breaches, and shows how the PDPC reasons. The guide is guidance, not law.
- Of the PDPC guide's 10 examples, only 2 need no notification at all: a lost encrypted USB drive and a temporary power cut.
- Encryption lowers risk only for confidentiality breaches. It does nothing when data is locked, destroyed or altered.
- Ransomware with no backup (Example 4) must be reported to the PDPC Office and to data subjects, even though the data is encrypted.
- To rely on the Clause 9 exemption, the controller must prove there is no risk and submit evidence of its security measures.
- The guide is guidance, not law. The duty comes from PDPA Section 37(4), and the data controller makes the final call.
Ask your IT team, "If all our data is encrypted, do we still have to notify the PDPC?" The most common answer is "no". That answer is half right, and the wrong half is the expensive one. The PDPC Office's own guide contains an example where every record was encrypted and the controller still had to notify both the Office and data subjects. In that case, the one who did the encrypting was the attacker.
The Office of the Personal Data Protection Committee published its "Guide on Risk Assessment and Notification of Personal Data Breaches", version 1.0, dated 15 December 2022, the same day the Committee's 2022 breach notification took effect. It contains ten worked examples, each with an answer on whom to notify and why. This article goes through all ten in the guide's own terms, then reads them against Clauses 4 and 12 of the 2022 Notification to extract rules you can apply to a real incident.
What types of personal data breach does Thai law recognise?
Clause 4 of the Notification of the Personal Data Protection Committee on Criteria and Methods for Notification of Personal Data Breaches B.E. 2565 (2022) defines three types, and a single incident can fall into more than one. The first is a confidentiality breach.
(1) a breach of the confidentiality of personal data (Confidentiality Breach), in which personal data is accessed or disclosed without authority or unlawfully, or as a result of an error, defect or accident;
The second is data altered until it is wrong: a balance changed in the billing system, a line deleted from a patient's allergy record. Nothing leaves the building, but anyone relying on that data may harm the person without knowing it.
(2) a breach of the integrity of personal data (Integrity Breach), in which personal data is altered or corrected so as to become inaccurate, incomplete or deficient, without authority or unlawfully, or as a result of an error, defect or accident;
The third is the one organisations rarely think of as a "leak" at all, because nothing leaks. The data simply cannot be used.
(3) a breach of the availability of personal data (Availability Breach), which renders personal data inaccessible, or in which personal data is destroyed, such that the personal data is not in a state of normal availability for use.
These three words unlock the rest of this article. Encryption is designed to stop people reading data. It does not stop data from being lost or altered. Classify the incident wrongly at the start and "but we encrypt" ends up being applied where it does not belong.
How did the PDPC assess its ten examples?
Below are the ten examples in the order the guide gives them, with the guide's answer for both the Office and data subjects and a short summary of its reasoning. The breach type in brackets is our own classification under Clause 4 of the 2022 Notification; it does not appear in the guide.
Low risk. Encrypted data cannot be opened, so losing the drive poses no risk to data subjects.
The data is usable and identifies people; the attack may cause damage to a large number of data subjects.
Once power returns the data is usable again, so this is not a breach likely to result in a risk to rights and freedoms.
The data identifies people, is no longer available, has no backup, and the incident may damage both the business and data subjects.
The data really did leak, initially affecting only those 10. The bank must keep checking for others and notify them too if found.
A computer-crime offence exposing key user data, with a high risk of use in unlawful transactions.
So far a software fault with no sign of a cyber attack, but with a fair impact on customers. If an attack is later found, both the Office and data subjects must be told promptly.
Patient records include health data, which is sensitive and identifies people; notify and investigate further.
Sent unencrypted, covering many people, possibly including sensitive data; the contractor could misuse it.
Many people's data was sent and could be misused later. Whether to tell data subjects may depend on volume and type of data; if it was all encrypted, the risk may be low.
Tally the answers and only Examples 1 and 3 need no notification in either direction. The other eight all go to the Office (Example 7 via the controller), and seven of those also require telling at least some data subjects; the exception is Example 7, where no data subject has been affected yet. Note also that the guide does not think in "everyone or no one" terms: in Examples 5 and 6 the Office says to notify only the people whose data actually leaked.
ตัวอย่างการประเมินความเสี่ยงของการละเมิดข้อมูลส่วนบุคคลดังกล่าว เป็นเพียงแนวทางในการประเมินความเสี่ยงเท่านั้น หลักเกณฑ์ในการพิจารณาประเมินความเสี่ยงจะต้องพิจารณาจากข้อเท็จจริงตามปัจจัยที่เกี่ยวข้องเป็นกรณี ๆ ไปDoes encryption really mean you don't have to notify?
Only for confidentiality breaches: data ends up in someone else's hands and encryption stops them from reading it. Example 1 is the model case, and the guide's reasoning reads:
ความเสี่ยงต่ำ เนื่องจากเมื่อมีการเข้ารหัสด้วยมาตรการทางเทคโนโลยีที่น่าเชื่อถือแล้ว ข้อมูลดังกล่าวไม่สามารถเปิดใช้งานได้ การที่ USB Drive สูญหายไปจึงไม่มีความเสี่ยงกับเจ้าของข้อมูลส่วนบุคคลThat reasoning tracks the exemption in Clause 9 of the 2022 Notification, which lets a controller claim exemption from notifying the Office if it can prove the breach carries no risk, including the case:
where such personal data is not in a usable state because sufficient technological measures are in place
Now set Example 4 beside Example 1. In Example 4 the data is also fully encrypted, but the attacker holds the key, so the organisation itself cannot use its own data. The guide reaches the opposite verdict, and its reasoning has nothing to do with who can read the data. It is about whether the data is still available.
การถูกโจมตีจากมัลแวร์เรียกค่าไถ่ทำให้ข้อมูลดังกล่าวไม่อยู่ในสภาพที่พร้อมใช้งาน และไม่มีข้อมูลสำรองOur analysis (the guide does not put it in one sentence) is that if the organisation in Example 4 had already encrypted its own database, the outcome would be the same. Ransomware does not need to read your data; it only needs to lock you out. What the guide points to as decisive is "no backup". Example 8 works the same way: patient records were inaccessible for 30 hours, and encryption would not have got a doctor into a record one minute sooner. The guide's reasoning rests on the sensitivity of health data, not on anyone reading it.
| Breach type | What encryption does | Examples in the guide | Better-matched control |
|---|---|---|---|
| Confidentiality | A lot, if done with reliable technology and whoever has the data lacks the key | Example 1 (no notice) · Example 9 (unencrypted, so notify) · Example 10 (encryption may exempt) | Encrypt devices and attachments, store keys separately, use BCC or one-to-one mailing |
| Integrity | Almost nothing; encrypted data can still be deleted or overwritten by anyone with write access | No direct example in the guide | Restrict edit rights, keep change history, validate critical data |
| Availability | Nothing; encrypted data can still be locked or destroyed | Example 3 (no notice) · Examples 4, 7, 8 (notify) | Backups kept apart from production and tested for restore, failover, an incident plan |
Which example is your incident closest to, and who will you probably have to notify?
Start by asking whether your incident hits confidentiality, integrity or availability, then find the closest example in the guide. Treat this table as a starting point, not a verdict. The last column lists what could make your facts different from the example.
| If your incident looks like this | Closest example | Likely outcome per the guide | Check before deciding |
|---|---|---|---|
| A device or backup is lost, but encrypted with reliable technology | 1 | No notice to the Office or data subjects | Was the key or password lost with it? Do you have enough evidence of encryption to submit under Clause 9? |
| A file or email with many people's data goes to the wrong recipient, unencrypted | 9 | Notify the Office and data subjects | Any sensitive data? Who received it? Can deletion be confirmed? |
| A group email where recipients can see each other's addresses | 10 | Notify the Office and data subjects, unless encrypted with reliable technology | How many recipients, and what the email reveals beyond addresses |
| A customer complains they received someone else's document | 5 | Notify the Office and only the people affected | Check for further victims; notify them too if found |
| Systems breached; data extracted or posted online | 2 · 6 | Notify the Office and data subjects (Example 6: only those whose data leaked) | Passwords, financial data, or anything usable for transactions? |
| Ransomware locks the data and there is no backup | 4 | Notify the Office and data subjects | Did the attacker also exfiltrate data? If so, it is a confidentiality breach too |
| Temporary outage from power or hardware, fully restored | 3 | No notice | Any sign of an attack? Is the data really complete again? |
| A vendor's bug stops customers from reaching their data | 7 | Processor tells the controller; controller notifies the Office | Keep investigating for an attack; if found, notify data subjects too |
| Health or other sensitive data is inaccessible because of an attack | 8 | Notify the Office and data subjects | How long? Did any data leave as well? |
Two situations have no matching example and deserve extra care: ransomware where you do have a backup and restore quickly, and integrity breaches. For the first, Example 4 puts weight on "no backup", but many modern ransomware attacks copy data out before locking it. If there is evidence of exfiltration, the incident becomes a confidentiality breach like Example 2. Integrity breaches have no example in the guide at all, so assess them directly against the factors in Clause 12 of the 2022 Notification.
Where do the eight factors of Clause 12 show up in the examples?
Clause 12 of the 2022 Notification lists the factors a controller "may consider" in assessing risk, and the guide's foreword says the examples were built on Clauses 4 and 12. Tracing the guide's reasoning back to those factors is the best way to learn what the Office actually weighs.
In assessing the risk of a personal data breach, as to the extent to which it is likely to have an impact on the rights and freedoms of persons, the data controller may consider the following factors:
- Nature and type of breach. The power cut in Example 3 and the ransomware in Example 4 are both availability breaches, but they end differently because in the first the data comes back when the power does.
- Type of data. In Example 8 the guide says expressly that health data is sensitive. See our sensitive personal data guide.
- Volume. Examples 9 and 10 cite "many" people as a reason, while Example 5 limits notice to the 10 people actually affected.
- Status of the data subjects, such as minors or vulnerable persons. The reasoning in Example 9 does not invoke this factor, but if the students are minors, factor (4) applies to the school's incident as well.
- Severity, and how effective your measures are. In Example 6 posted passwords create a risk of unlawful transactions; in Example 1 encryption worked well enough to make the risk low.
- Wider impact on the business or the public. In Example 4 the guide notes possible damage to the controller's business.
- The storage system and its security measures. No backup in Example 4 and unencrypted sending in Example 9 are this factor at work.
- Legal status and size of the controller. No example cites it directly, but it remains a factor the Office may weigh.
Who makes the final call on whether to notify?
The data controller, advised by its DPO. Not the guide, not software, and not the IT team alone. The duty in Section 37(4) of the Personal Data Protection Act sits with the controller, and the threshold for telling data subjects is one step higher than the threshold for telling the Office.
If the Personal Data breach is likely to result in a high risk to the rights and freedoms of the Persons, the Data Controller shall also notify the Personal Data breach and the remedial measures to the data subject without delay.
What the PDPC's ten examples give you is a shared language between IT, legal and management. When everyone can point to the same example, the argument gets much shorter. But a "no need to notify" decision must rest on reasons and evidence under Clause 9 of the 2022 Notification, and you should record who decided, when, and on which facts. If the facts change, for instance you discover the attacker also copied data out, the decision must change with them, and the 72-hour clock is still running. For managing that clock, see the first 72 hours after a data leak.
If you would rather start on prevention, encrypting portable devices, keeping backups separate from production, and limiting who can edit data are the three controls that map onto the three breach types in Clause 4. Our security measures guide lists the minimum controls, and the 72-hour notification guide has the short version of the process.
Frequently asked questions
If our data was encrypted, do we skip notifying the PDPC?
Not always. Example 1 in the PDPC guide needs no notice because the lost data cannot be opened, but Clause 9 of the 2022 Notification requires the controller to prove it and submit evidence of its measures. If the incident affects availability, such as ransomware with no backup in Example 4, encryption does nothing to lower the risk.
Is an outage that locks customers out a personal data breach?
It can be an availability breach under Clause 4(3) of the 2022 Notification. The PDPC guide's answer depends on the facts: a temporary power cut (Example 3) needs no notice, a processor's bug (Example 7) must reach the Office via the controller, and a hacked hospital (Example 8) must notify both the Office and patients.
Are the PDPC's ten examples legally binding?
No. They come from version 1.0 of a PDPC Office guide dated 15 December 2022, and the guide itself says each case must be assessed on its own facts. The binding duties come from Section 37(4) of the PDPA and the Committee's 2022 Notification.
Do we have to notify every person in the system?
Not necessarily. In Example 5 the guide says to notify only the 10 people affected, and in Example 6 only the customers whose data was posted online. You must keep checking for further victims and notify them if found.
Who should decide whether an incident is notifiable?
The duty in Section 37(4) of the PDPA belongs to the data controller. In practice the DPO advises and an executive with authority decides. Software or AI can match examples and prepare the reasoning, but should not make the decision for you.
Law and sources
- PDPC Office Guide on Breach Risk Assessment and Notification, version 1.0 (15 December 2022) — guidance, not law — Examples 1–10 · Note
- PDPC Notification on Criteria and Methods for Notification of Personal Data Breaches B.E. 2565 (2022) — Clause 4 · Clause 9 · Clause 12
- Personal Data Protection Act B.E. 2562 (2019) — Section 37 (4)
Text in the "The text" boxes is copied word for word from AIPDPA's legal knowledge base, transcribed from the Royal Gazette and official documents; every edit is checked by the system against that base, character by character. English wording is an unofficial translation; the Thai text prevails. This article is general information, not legal advice for a particular case.
Do it in the system
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)