90-Day Logs vs the Right to Erasure: When Thailand's Computer Crime Act and the PDPA Pull Apart

Picture this: you run an online platform where customers log in. On Monday morning a customer closes their account and emails support: "Delete all my data under PDPA Section 33." Support forwards it to IT. IT replies in one line: "We can't delete logs. The Computer Crime Act makes us keep them for 90 days." Three weeks later, the ticket is still open.

Both sides are half right, and you can get it wrong in either direction. Delete everything, and you may destroy data a service provider is obliged to keep under Section 26 of the Computer-Related Crime Act B.E. 2550 (2007), which carries a fine of up to 500,000 baht. Refuse the whole request on the strength of that Act, and data that has nothing to do with logs stays in your systems longer than the Personal Data Protection Act B.E. 2562 (2019) allows.

So the right answer is neither "delete" nor "refuse". It is to split the customer's data into pieces and ask, for each piece: which law says keep it, until when, and which system deletes it when that date arrives.

The customer wants erasure, the Computer Crime Act says retain. Who wins?

Traffic data that a service provider must keep under Section 26 beats the erasure request, but only for that data and only for the period the law requires. The reason sits inside the PDPA itself: Section 33 paragraph two disapplies the right to erasure where retention is needed "for compliance with the law".

Look at the words "to the extent that". The Section 33 exception attaches to the purpose of retention, not to the person. A single request from a single customer can therefore produce two piles: data you must erase now, and data you may keep for the time being. When the legal reason to keep a pile expires, so does the exception.

On the other side, Section 26 of the Computer-Related Crime Act says "not less than" ninety days. That figure is a floor, not a ceiling. The Act never says when to delete. The PDPA does, in Section 37(3).

What counts as "traffic data", and is your business a "service provider"?

Traffic data describes a communication, not its content: where it came from, where it went, when, for how long and over which service. Section 3 of the Computer-Related Crime Act defines it as

In real systems this data tends to live in web server, firewall, VPN and authentication logs: source IP, connection time, destination, type of service. A customer's name, delivery address, purchase history or marketing segment is not traffic data under Section 3, even when it sits in the same database. That line is the whole game when you answer an erasure request.

The next question is whether you are a service provider at all. Section 3 recognises two kinds.

The definition is broad, but the Section 26 retention duty does not fall on everyone automatically. Section 26 paragraph three leaves it to a Ministerial notification in the Government Gazette to set which types of service provider the duty applies to, how and from when. That notification is not in the legal corpus this article draws on, so before you conclude that your organisation must keep traffic data, read it against the services you offer to outsiders. Section 26 paragraph two, on data that identifies the user, runs on a different clock.

How far does the PDPA let you refuse an erasure request?

Only for data whose retention is still needed to comply with the law, and you must tell the requester why. Everything else has to go within the timeframe set by the 2024 Notification, with no room to negotiate.

PDPA Section 33 paragraph one grants the right to erasure on four grounds. After an account closure the usual ones are (1) the data is no longer necessary for its purpose, and (2) consent is withdrawn and the controller has no other legal ground to keep the data. Once a ground applies and no paragraph-two exception does, the PDPC's Notification on Criteria for the Deletion or Destruction of Personal Data B.E. 2567 (2024) sets a firm deadline.

The same Notification closes the gap organisations forget most often: backups. Clause 3 paragraph two extends erasure to copies and backups and requires that nobody can recover the data by reasonably foreseeable means. If your backup system cannot delete one person's records straight away, Clause 4 requires you to make that data hard to collect, use or disclose, bar anyone from using it to make decisions about the person, and delete it as soon as you can.

For the pile you cannot erase yet because the retention duty is still running, silence is not an option. Clause 8 paragraph three of the 2024 Notification imposes a duty to explain.

The collision map: which law says keep, which says delete, for each kind of data?

The table splits a typical customer account into six pieces. Every period comes from the texts. Where a text sets no number of days, we say so rather than invent one.

Row five turns the problem inside out. A log kept to protect personal data becomes personal data itself: a line recording which employee opened which customer's file, and when, carries both names. The 2022 Notification requires such audit trails but sets no retention period, so the period is a business decision you must be able to justify.

Once 90 days have passed, must the logs be deleted immediately?

Not necessarily on day 91, but you need an end date that you have declared, and you must actually delete when it arrives. PDPA Section 37(3) does not wait for someone to ask. It requires a system that deletes on its own when the retention period ends.

You may keep logs longer than 90 days if you have a purpose and a legal basis you can explain, such as investigating security incidents. Here is the point legal teams tend to miss: unless another law or an official's order requires more than the minimum, the extra time is hard to defend as retention "for compliance with the law". And the Section 33 paragraph-two exceptions mention Section 24(1) and (4) but not Section 24(5), legitimate interests. An erasure request that lands during that extra window has to be assessed afresh.

This is where many systems go wrong. Logs are set to never expire because disk space is cheap and nobody asks why they are kept. Logs held past their period without a reason are personal data beyond what is necessary under Section 37(3), and if a breach ever happens, they are a large pile of data that should not have existed in the first place.

How do you design log retention that satisfies both laws?

Separate storage by legal reason, not by system convenience. Once every store has its own governing rule, answering an erasure request stops being a meeting-room argument and becomes a lookup.

1. Keep traffic logs apart from the profile database. Use a separate store and refer to customers by user ID, not by name or email. When the profile is erased, the logs still do their Section 26 job without dragging profile data along.
2. Label every store with its legal reason, for example "CCA s.26 para. 1, minimum 90 days" or "PDPA s.24(3), contract". That label is what your team uses to decide what can be deleted and when.
3. Restrict access to logs to the people who need them, in line with the least-privilege principle in Clause 4(6)(a) of the 2022 Security Measures Notification, and record who looks.
4. Delete on a rolling window counted from the day each record entered the system, because Section 26 paragraph one counts from that day, not from account closure.
5. Give user-identification data its own clock. It runs for 90 days from the end of the service under Section 26 paragraph two. When a customer closes the account, cut the profile down to the identifying minimum and schedule its deletion that day.
6. Use a legal hold for data an official has ordered you to keep beyond 90 days. The hold must cite the order, carry an expiry date and never spread to other data.
7. Reach the backups. Rotate backup sets so old data is overwritten, and in the meantime make sure the backup copy cannot be pulled back into use for that customer, following the criteria in Clause 4 of the 2024 Erasure Notification.
8. Write the retention period into your record of processing. Section 39(4) requires the retention period to be recorded. Log retention belongs there too, not only in a server config file.

Another way to shrink the problem is to stop collecting IP addresses where you do not need them. Clause 6(2) of the 2024 Erasure Notification names the IP address as an example of an indirect identifier, so every place that stores IPs is another place you must purge on schedule. Consent records for cookies are a good example: the AIPDPA cookie banner keeps its consent log without IP addresses.

How should you answer an erasure request, step by step?

The sequence below works for erasure requests that touch traffic data. Steps fixed by law cite the provision; steps that are our recommendation say so.

1. Day 0
   Log the request and its date of receipt. The 90-day deadline in Clause 3 of the 2024 Erasure Notification runs from today.2024 Erasure Notification, cl. 3
2. First week (recommended)
   Verify the requester, then sort their data using the collision map: what must be erased and what is still under a legal retention duty.PDPA s.33
3. Without delay
   Erase or anonymise profile and marketing data, including copies and backups.2024 Erasure Notification, cl. 3 para. 2
4. Before day 90
   Tell the requester what has been erased and what cannot be yet, with the reasons, the provision relied on and the deletion date.2024 Erasure Notification, cl. 8
5. When the log period ends
   The system deletes the logs and the user-identification data on its regular cycle and records the disposal as evidence.PDPA s.37(3)

If the requester disputes your reasons, Section 33 paragraph four lets the data subject complain to the Expert Committee, which can order the controller to act. A reply that cites the exact provision and gives a firm deletion date is your best evidence at that stage. This is the part AIPDPA turns into a routine: a request portal with a deadline clock, retention rules, and disposal logs tied to your Section 39 record. See the demo account.

Common mistakes, and the provision each one runs into

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)