[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-log-retention-audit-trail-thailand-en":3,"blog-post-log-retention-audit-trail-thailand-en":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"Section 3 of the Computer-Related Crime Act B.E. 2550 defines it as data about the communication of a computer system that shows its origin, source, destination, route, time, date, volume, duration, type of service, or other related details. From a systems point of view, we see it as closer to access logs and connection logs than to the content being transmitted.","8b3uers14my60pn","What does \"computer traffic data\" mean under Thai law?",{"answer":9,"id":10,"question":11},"It depends on the service it actually provides. Annex A of the 2021 Ministry of Digital Economy and Society notification lists, as one example, providers of computer network access for organizations, such as government agencies, companies or educational institutions. An organization that gives staff network access may therefore fall within scope, but the final answer should come from your legal counsel and be recorded in writing.","zpvjnorp8ydlu1x","Does an organization that does not sell internet access count as a service provider under this law?",{"answer":13,"id":14,"question":15},"An application log records how the system is behaving, such as errors or response times, and loses its value once a problem is fixed. An audit trail records who changed what, when, and from which value to which. It is evidence, so it needs longer retention and must be protected from edits by the main system's administrators. That is why we separate the two at design time.","f51rfbf4sxlt6er","How is an audit trail different from an application log?",{"answer":17,"id":18,"question":19},"Not once it is locked. Google Cloud's Cloud Logging documentation says locking a bucket is irreversible, and the bucket can be deleted only after every log entry has fulfilled its retention period. On Azure, a locked time-based retention policy cannot be deleted, and its retention period can be extended but not shortened. Test the retention settings and check that no data you should not keep is flowing in before you lock.","uuj5tkwf3lc2c63","Can a locked log bucket or immutability policy be undone later?",{"answer":21,"id":22,"question":23},"For security logs and audit trails, we recommend a separate project or subscription held by a different group of people. If an account with admin rights on the main system can also delete the logs, those logs prove little on the day the system is breached. Operational logs used for day-to-day troubleshooting can stay close to the main system.","r9nhkqy5cy6xzih","Should logs be stored in the same cloud account as the main system?",{"answer":25,"id":26,"question":27},"Section 26 and the 2021 notification say no less than 90 days, so that figure is a minimum for service providers as the Act defines them, not a ceiling. Longer retention adds storage cost, and if the logs contain personal data, it adds to the data your organization must look after. Any period beyond the minimum should have a business reason behind it and be reviewed by your DPO or PDPA counsel.","gyq5nigvwcysmuf","Can we keep logs longer than the law requires?",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"0fartd9l7mfwdt4","4in0ysidwqz16aq","How Long Must Logs Be Kept Under Thailand's Computer Crime Act?","Thai law requires service providers to keep computer traffic data for no less than 90 days. Who is in scope, and how to protect logs on Google Cloud and Azure.","\u003Cp>When you create a new log bucket on Google Cloud, one field asks how many days to keep the logs. Leave it blank and, according to Google Cloud's documentation, the default is 30 days, and logs cannot be recovered once their retention period ends. That one number sets your monthly storage cost, how far back you can investigate an incident, and how much personal data you are holding, all at once.\u003C\u002Fp>\u003Cp>Suppose a team accepts the default and plans to revisit it later. Four months on, an internal auditor asks for the audit trail from that period. The data is gone, and there is no button that brings it back.\u003C\u002Fp>\u003Cp>This article describes how we think about log retention when we design a system: separating logs by purpose, what Thai law requires as we read it in the primary text, keeping logs from being altered, and the cost and personal data that come with long retention. It is not legal advice. Whether your organization has a legal duty here is a question for your own legal counsel.\u003C\u002Fp>\u003Ch2>Three kinds of logs, kept for different reasons\u003C\u002Fh2>\u003Cp>The mistake we guard against from the start is setting one retention period for everything. Each kind of log answers a different question, for a different group of people.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Operational or debug logs\u003C\u002Fstrong> answer where the system went wrong: errors, stack traces, API response times. They are the largest by volume and lose their value fastest. Once the problem is fixed, almost nobody looks at them again.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Security logs\u003C\u002Fstrong> answer who tried to access what, and whether they succeeded or were refused: sign-ins, permission changes, connections from outside networks. They need to be kept long enough to reconstruct an incident, because the day an anomaly is noticed is not necessarily the day it happened.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Audit trails\u003C\u002Fstrong> answer who changed what, when, and from which value to which: approvals, edits to master data, configuration changes. This is evidence, so being trustworthy matters more than being fast to search.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Once these three are separated at the source, setting retention becomes much easier. Operational logs can be short-lived, while audit trails may need to be kept for as long as internal policy or a regulator requires.\u003C\u002Fp>\u003Cp>This article does not cover designing alerts from logs, which we wrote about in \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\u002Fblogs\u002Fmonitoring-alerting-what-to-page-on\">our piece on monitoring and alerts\u003C\u002Fa>, nor audit logging for AI agents, which is covered in \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\u002Fblogs\u002Fai-agent-readiness-before-system-access\">our piece on the gates before an AI agent touches production systems\u003C\u002Fa>.\u003C\u002Fp>\u003Ch2>How long the Computer Crime Act says to keep logs, and who it applies to\u003C\u002Fh2>\u003Cp>The core requirement is Section 26 of the Computer-Related Crime Act B.E. 2550 (2007), whose first paragraph was amended by the Computer-Related Crime Act (No. 2) B.E. 2560 (2017). We read the text in \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.etda.or.th\u002Fgetattachment\u002Fe3c8aef2-00ce-4c91-abea-fef02fc7f07c\u002FComputer-Crimes-Act-BE-2550-and-BE-2560.aspx\">the consolidated Thai version published by ETDA\u003C\u002Fa>, which incorporates both Acts and cites the Royal Gazette.\u003C\u002Fp>\u003Cp>The Act requires a service provider to retain computer traffic data for no less than 90 days from the date the data enters the computer system. Where necessary, an authorized official may order a particular service provider to retain it for longer than 90 days but no more than two years, as a special, case-by-case measure.\u003C\u002Fp>\u003Cp>The second paragraph requires a service provider to keep user data only as needed to identify the user, from the start of the service and for no less than 90 days after the service ends. The third paragraph says which types of service provider the first paragraph applies to, how, and from when, is set by ministerial notification in the Royal Gazette. The last paragraph states that a service provider who fails to comply with the section is liable to a fine of up to 500,000 baht.\u003C\u002Fp>\u003Cp>The word to read carefully is \"service provider\". Section 3 defines two groups. The first provides others with access to the internet, or with other means of communicating through a computer system, whether in its own name or on behalf of others. The second stores computer data for the benefit of others. Read against that definition, the Section 26 duty attaches to the service-provider role. It is not written to apply to every organization that runs computer systems.\u003C\u002Fp>\u003Cp>Which providers must keep what is set out in the \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpub.nstda.or.th\u002Fgov-dx\u002Fwp-content\u002Fuploads\u002F2021\u002F08\u002FT_0009.pdf\">Ministry of Digital Economy and Society Notification on Criteria for the Retention of Computer Traffic Data by Service Providers B.E. 2564 (2021)\u003C\u002Fa>, published in the Royal Gazette on 13 August 2021, which repealed the 2007 notification. Clause 5 divides service providers into several types, and Annex A (ภาคผนวก ก) lists examples such as internet service providers, web hosting providers, cloud providers serving end users directly, and digital service providers across many sectors.\u003C\u002Fp>\u003Cp>One example in Annex A that an organization's IT team should know is \"providers of computer network access for organizations, such as government agencies, companies or educational institutions\" (our translation). An organization that gives staff or students internet access through its network may therefore fall within scope. Whether yours does, and under which type, is a question for legal counsel to answer from how the service actually works.\u003C\u002Fp>\u003Cp>Clause 12 of the notification matches the Act: in general, no less than 90 days from the date the data enters the system. Where necessary and under the conditions it sets out, an official may order further retention of up to six consecutive months at a time, but no more than two years. Note that the law sets a minimum. It does not say how long is right for your system.\u003C\u002Fp>\u003Ch2>Logs an administrator can edit make weak evidence\u003C\u002Fh2>\u003Cp>Clause 9 of the same notification lists several requirements for secure retention. The ones closest to system design are these: logs must be kept on media or systems that preserve the integrity of the data and identify who accesses it, and system administrators must not be able to modify the stored data. The notification gives examples such as a Centralized Log Server, Data Archiving or Data Hashing.\u003C\u002Fp>\u003Cp>Even if your organization is not a service provider, the principle applies directly to audit trails. If someone with admin rights on the main system can delete or edit logs with the same account, those logs prove very little on the day you need them.\u003C\u002Fp>\u003Cp>Separating permissions matters more than choosing a tool.\u003C\u002Fp>\u003Cp>Our usual approach is to ship logs to a project or subscription separate from the main system, held by a different group of people, and then turn on the cloud provider's tamper-protection features.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>On Google Cloud, the \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdocs.cloud.google.com\u002Flogging\u002Fdocs\u002Fbuckets\">Cloud Logging buckets\u003C\u002Fa> documentation says custom retention can be set from 1 to 3650 days, and that a bucket can be locked. Locking is irreversible. Once locked, the bucket and its retention policy cannot be updated, and the bucket can only be deleted after every log entry in it has fulfilled the retention period.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>On Microsoft Azure, the \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fstorage\u002Fblobs\u002Fimmutable-storage-overview\">immutable storage for Blob Storage\u003C\u002Fa> documentation describes WORM (Write Once, Read Many) storage, where data cannot be modified or deleted for a set interval. Once a time-based retention policy is locked, it cannot be deleted. The retention period can be extended but not shortened.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Clause 11 of the notification also requires device clocks to be synchronized to an international reference time. It sounds minor, but an audit trail whose machines drift by a few minutes cannot put events in order across systems. We check time synchronization early, before connecting any system to a central log store.\u003C\u002Fp>\u003Ch2>The cost of long retention, and tiering\u003C\u002Fh2>\u003Cp>Long retention has a real cost. The Cloud Logging documentation states that, effective 1 April 2023, retention costs apply to logs kept longer than the default retention period of the _Default bucket and user-defined buckets. Check current rates on the provider's pricing page, because they change.\u003C\u002Fp>\u003Cp>On Azure, the immutable storage documentation states that there is no extra capacity charge for immutability, immutable data is priced the same as mutable data, and all blob access tiers support immutable storage. So the approach we consider is tiering by age: keep recent logs where they are quick to search, and move older logs to a tier with lower storage cost in exchange for higher access cost or slower retrieval.\u003C\u002Fp>\u003Cp>The drawback to state plainly is that an irreversible lock also stops you fixing your own mistakes. If you set retention too long, or accidentally send data you should not keep into a locked bucket, you pay to store it and hold it until the period ends. If your organization is not a service provider, and the system has a few dozen internal users with no transactions that need to be proven after the fact, a separate account with restricted delete rights may be enough, without a permanent lock.\u003C\u002Fp>\u003Ch2>Personal data hiding in logs\u003C\u002Fh2>\u003Cp>Clause 9(4) of the notification requires that traffic data identify each service user individually. At the same time, logs that identify people are another personal data set your organization holds. So we design logs to keep only what is needed, and to stop sensitive data slipping in by accident.\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>Do not log whole form payloads, such as a request body containing a national ID number, phone number or password. Log only the transaction's reference ID.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Mask data at the moment the log is written rather than cleaning it up later, because once data lands in a locked bucket it cannot be removed until the period ends.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Keep the table that maps user IDs to real people somewhere with stricter access than ordinary logs. People debugging the system see only IDs; people running a genuine investigation request access to the mapping through a defined process.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Retention periods for logs that contain personal data should also be reviewed by your DPO or PDPA counsel, because keeping data longer than necessary is a risk of its own.\u003C\u002Fp>\u003Ch2>Objections we hear often\u003C\u002Fh2>\u003Cp>The first objection is that keeping everything for as long as possible must be safest. It sounds prudent, but logs with no defined purpose are rarely found on the day they are needed, and they add both storage cost and personal data the organization is responsible for. We prefer to set a period per log type and write down the reason for each value.\u003C\u002Fp>\u003Cp>The second is that the cloud provider already keeps logs for you. That is only partly true. Azure's own documentation says that resource logs, which record data operations, are the customer's responsibility to store persistently as regulatory or other requirements demand. A provider's defaults are a starting point, not your organization's policy.\u003C\u002Fp>\u003Ch2>Where to start\u003C\u002Fh2>\u003Col>\u003Cli>\u003Cp>List the logs your systems actually produce, sort them into operational, security and audit trail, and note who uses each group.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Ask legal counsel whether your organization, or any of its services, counts as a \"service provider\" under Section 3 and the 2021 notification, and record the answer in writing.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Set retention for each group, using the legal requirement as the floor and business reasons to justify anything beyond it.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Move security logs and audit trails to a separate project or subscription, confirm the retention settings by testing, and only then lock.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Check that logs carry no unnecessary personal data, and that every machine's clock is synchronized to the same reference.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Fol>\u003Cp>If you are drafting the TOR for a new system, write the requirements for log retention and tamper protection into the first draft rather than adding them at the end.\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>Summary\u003C\u002Fh2>\u003Cp>There is no single right answer to how long a system should keep logs. The law sets a minimum for service providers as it defines them; the rest is your organization's decision about evidence, cost and personal data. If you take one thing from this article, separate the audit trail from ordinary logs and keep it where the main system's administrators cannot change it.\u003C\u002Fp>\u003Cp>If you would like to talk through log architecture on Google Cloud or Microsoft Azure, you can reach us at 088-983-9386 or contact@superdev.tech. Our office is in Bangkapi, Bangkok. We are happy to start by understanding the systems you already have, without needing complete documentation first. For questions of legal interpretation, we will always point you to your organization's legal counsel. You can find more about us at \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fen\">superdev.tech\u003C\u002Fa>.\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002F0fartd9l7mfwdt4\u002Fcover_cover_5w2jpok02b.webp","September 30, 2026","2026-09-30 06:21:42.538Z",116,"Enterprise","enterprise","log-retention-audit-trail-thailand","\u002Fblogs\u002Flog-retention-audit-trail-thailand",10,false,0,"",[47,48,49,50,51,52],"log retention","audit trail","computer traffic data","Thailand Computer-Related Crime Act","immutable storage","PDPA"]