A retention schedule an auditor will accept is a table that states, for every dataset, how long it is kept, what event starts the period, which law or reason justifies it, and who deletes it and how. It is written for DPOs, HR and finance teams under Thailand's PDPA sections 23(3) and 37(3), and walks through the TDPG method, the required columns and the evidence to keep.
- PDPA section 23(3) requires you to tell people the retention period when you collect their data, or an expected period if no exact one can be set.
- Section 37(3) requires a system that deletes data when the period ends; clause 9 of the 2024 erasure notification applies its deletion rules to that system.
- TDPG (guidance, not law) sets an order: a statutory period first, then limitation periods for claims, and deletion of everything else.
- An auditable row needs a trigger, a period, a justification, an end-of-period action and a named owner.
- Backups that cannot be purged at once must be put beyond use until they are overwritten, under clause 4 of the 2024 notification.
Almost every Thai privacy policy promises that the company will keep personal data “only as long as necessary”. The sentence is correct and useless in an audit. Ask how long rejected job applications are kept, or how many days of shop CCTV footage are retained, and three people in the same company will give three answers.
A retention schedule closes that gap. This article covers the provisions that require one, the method TDPG 4.0 uses to set each period, the columns every row needs, and how deletion at the end of the period must work under the 2024 erasure notification. If your RoPA is done, you are halfway there: its retention column holds the same numbers.
Does Thai law actually require a retention schedule?
The PDPA never uses the word “schedule”, but three provisions only work if you have one. The first is section 23(3), which makes the retention period part of the notice given at collection.
(3) the Personal Data to be collected and the period for which the Personal Data will be retained. If it is not possible to specify the retention period, the expected data retention period according the data retention standard shall be specified;
The second is section 39(4), which puts “the retention period of the Personal Data” into the record of processing. The third, and the one with teeth, is section 37(3). It does not ask for a number on paper; it asks for a system that checks and deletes.
(3) put in place the examination system for erasure or destruction of the Personal Data when the retention period ends, or when the Personal Data is irrelevant or beyond the purpose necessary for which it has been collected, or when the data subject has request to do so, or when the data subject withdraws consent
Section 37(3) speaks of data whose “retention period ends”. A period can only end if someone set it. Without a schedule, the examination system has nothing to examine, which makes the schedule the starting point for the whole duty.
How do you decide how many years to keep something?
TDPG 4.0, an industry guideline rather than law, sets out a sequence in its section G7. Following it means every number in the schedule comes with a reason instead of a hunch.
G7.1 If a legally specified period clearly states how long the data must be retained, it must be retained for that period.
Step one is to look for a sector or record-keeping law. TDPG lists several examples; the table below reproduces them as TDPG summarises them. Check each against the source statute before relying on it, because those statutes are not in our verified corpus.
| Law cited by TDPG | Records | Period as TDPG summarises it |
|---|---|---|
| Accounting Act B.E. 2543 (2000) | Accounts and supporting documents | At least 5 years from closing the accounts (up to 7 if the Director-General so announces) |
| Revenue Code | Tax reports, tax invoices and supporting documents | At least 5 years from filing or reporting, or 2 more years after the business ceases |
| Labour Protection Act B.E. 2541 (1998) | Employee register | At least 2 years after each employee leaves |
| Labour Protection Act B.E. 2541 (1998) | Wage and overtime payment records | At least 2 years from payment, and until any dispute is finally decided |
| Anti-Money Laundering Act B.E. 2542 (1999) | Customer identification at financial institutions | 5 years after the account closes or the relationship ends |
| Digital Economy Ministry notification on computer traffic data, 2021 | Service providers' traffic data | At least 90 days from entering the system |
Most of what a company holds has no statutory period: applications from candidates who were not hired, lapsed customer lists, chat histories. Step two asks whether you need the data to bring or defend a legal claim.
G7.2 If there is no law or criteria that clearly specifies the retention period for data, you should consider whether it is necessary to retain the data for use in establishing a legal claim, complying with or exercising a legal claim, or defending against a legal claim that may arise in the future. However, data not related to such a claim should be deleted or destroyed in any case, and only the necessary basic data, such as name, address, and telephone number, may be retained.
This is where limitation periods come in. The PDPA's own limitation rule sits in section 78, and TDPG G7.3 uses it to justify keeping evidence of consent for a while after processing stops.
The claim for compensation from the wrongful act against the Personal Data under this Act shall be barred by prescription after the lapse of three years from the date that the injured person know of the damages and the identity of the Data Controller or the Data Processor who is to be liable, or after ten years from the date of which the wrongful act against the Personal Data took place.
Note the last sentence of G7.2. A limitation period justifies keeping what you would need to prove or defend the claim. It is not a licence to keep the whole file for ten years.
The same kind of data can carry different periods
TDPG G7.4 uses CCTV to make the point. A bank filming its ATMs may need several weeks of footage, because fraud often surfaces only when the customer reads a statement. A restaurant can keep far less, since incidents on its premises are known at once, unless the matter has been reported to the police, in which case the footage stays until they collect it.
G7.5 adds a case people forget: when a customer opts out of marketing, you may keep just enough to make sure you never contact them again. Good schedules are organised by purpose, not by system or folder.
What columns does each row need to pass an audit?
Five. TDPG G8.1 states the principle that each period must be explainable and tied to a legal basis.
G8.1 Storage Criteria & Justification, whereby you must determine the type of personal data and the retention period necessary and appropriate for the purpose of processing that personal data, and must be able to give reasons explaining the necessity, as well as disclose the criteria and lawful basis used to determine such retention period [21].
TDPG's sample HR schedule in G9.3 has columns for activity, trigger, period, action on expiry, source of necessity and data owner. In practice each column should answer one question.
- Trigger. Which event starts the period: end of contract, last day of employment, end of the financial year. Not “date of collection” on every row.
- Period. A number and a unit: 90 days, 2 years, 10 years. Not “as necessary”.
- Justification. The statute and section, or the limitation period relied on. If it is a business decision, say so and give the reason.
- Action at expiry. Delete, destroy, anonymise or review. A review must end in one of at most two outcomes.
- Owner. The role that approves deletion, not a whole department.
Retention Trigger: the event or condition that determines when the retention period of personal data begins to run, which in principle is counted from when there is a need to retain the personal data, such as the end of a contract, the end of employment, the end of the fiscal year, and so on.
The trigger is where most schedules fail. “Employment contracts: 10 years” means little until you know whether the ten years start at signature or at departure. The gap can be decades for a long-serving employee, and an automated deletion job cannot be configured at all.
| Data / purpose | Trigger | Period | Justification | At expiry | Owner |
|---|---|---|---|---|---|
| Accounting records naming customers | Accounts closed | 5 years | Accounting Act, as summarised in TDPG | Destroy | Finance manager |
| Employee register | Employee leaves | 2 years | Labour Protection Act, as summarised in TDPG | Review | Head of HR |
| Evidence of marketing consent | Consent withdrawn or no longer used | PDPA section 78 limitation | TDPG G7.3 | Delete; keep suppression list | DPO |
| Shop-front CCTV | Date recorded | A set number of days based on the shop's risk | TDPG G7.4 | Overwrite unless an incident is open | Branch manager |
What does the 2024 erasure notification require when the period ends?
The PDPC notification on deletion, destruction and anonymisation took effect on 12 November 2024. Most readers focus on the parts about data subject requests, but clause 9 brings scheduled deletion under the same rules.
In addition to acting upon the exercise of the right by a data subject under Section 33 paragraph one of the Personal Data Protection Act B.E. 2562 (2019), the data controller also has a duty to establish an examination system for the deletion or destruction of personal data under Section 37 (3); and for this purpose, Clause 3 paragraph two and paragraph three, Clause 4, Clause 5, and Clause 6 of this Notification shall apply mutatis mutandis.
In practice this means scheduled deletion must reach copies and backups (clause 3 paragraph two), and if you anonymise instead of deleting, you must meet clause 6: strip every direct identifier first, then reduce the risk of identification from indirect identifiers to a sufficiently low level.
Every IT team runs into the same wall: backup tapes and snapshots that cannot be purged record by record. Clause 4 addresses this, and clause 9 extends it to scheduled deletion.
if such action cannot be carried out within the period prescribed in Clause 3 — for example, in the case of personal data in electronic form which remains temporarily stored while awaiting being overwritten or replaced by other data (to be overwritten by other data) for technical reasons — the data controller must place such personal data in a form in which the collection, use, or disclosure of such personal data is difficult, until the action under Clause 3 has been completed
Add a backup note to the schedule: the rotation cycle, who can reach expired data while it waits to be overwritten, and a rule that expired records are never restored into live systems. Clause 4(1) to (5) sets five conditions, from having no intention of accessing the data again to deleting it as soon as that becomes possible.
How does the schedule help when someone asks for erasure early?
A well-built schedule becomes a ready-made answer to section 33 requests. Section 33 paragraph two lists the cases where you may keep data despite a request, and the justification column of your schedule maps onto those exceptions.
Paragraph one shall not apply to the extent that such Personal Data retention is necessary for the purpose of freedom of expression, the purpose under section 24 (1) or (4) or section 26(5) (a) or (b), the purpose of establishment, compliance or exercise of legal claims, or defense of legal claims, or the purpose for compliance with the law.
A row justified by accounting law answers “compliance with the law”. A row justified by a limitation period answers “defence of legal claims”. A row justified by “might be useful” matches no exception at all. When you refuse, clause 8 paragraph three of the 2024 notification requires you to give reasons, and section 39(7) requires you to record the refusal. The full workflow is in answering data subject requests on time.
The employee register is still within the period TDPG says labour law requires, so the compliance exception applies. Emergency contacts have no reason to survive; TDPG G7.5 uses exactly this example.
Marketing is not a section 33 paragraph two exception. Keep only enough to suppress future contact, as TDPG G7.5 allows.
Tax records are within the Revenue Code period as TDPG summarises it, so the compliance exception applies. Give reasons under clause 8 paragraph three and log the refusal.
No statute sets a period. If your schedule sets a short one and there is no dispute, nothing justifies keeping it.
What will an auditor ask to see besides the schedule?
A schedule only proves intent. Section 37(3) speaks of an examination system, so auditors usually ask for evidence that it runs. Keep this set ready.
- The current schedule with approval date, approver and review cycle; TDPG G9.6 suggests senior management approves the policy
- Deletion logs for each cycle: what was deleted, from which system, how many records, approved by whom
- Destruction certificates from any shredding or disk-destruction vendor
- The backup note required by clause 4 of the 2024 notification
- A privacy notice whose stated periods match the schedule
Frequently asked questions
Is “retained as required by law” enough in a privacy notice?
Section 23(3) requires the retention period, or an expected period if an exact one cannot be set. A bare reference to “the law” gives neither a number nor a statute. State a period, or at least name the law it follows.
Can we just keep everything for ten years to be safe?
No. Section 37(3) requires deletion of data beyond what the purpose needs, and TDPG G7.2 says data unrelated to a potential claim should be deleted. Over-retention also makes any breach larger.
Is TDPG binding?
No. TDPG 4.0 is an industry guideline. It is a useful reference standard but does not bind like the Act or PDPC notifications. Verify the statutory periods it summarises against the source laws.
Do backups have to be purged the day the period ends?
Clause 3 paragraph two of the 2024 notification extends deletion to copies and backups. Where that is technically impossible at once, clause 4 requires the data to be put beyond practical use until it can be deleted, and clause 9 applies this to scheduled deletion.
Can we anonymise instead of deleting?
Yes, if you meet clause 6 of the 2024 notification: remove all direct identifiers and reduce indirect identifiability to a sufficiently low level. For requests based on unlawful processing under section 33(4), clause 7 allows deletion or destruction only.
Who should own the schedule?
TDPG G9.2 suggests an information asset owner for each dataset who approves deletion, plus a separate compliance checker. The DPO coordinates; the head of each function explains why each row exists.
Law and sources
- Personal Data Protection Act B.E. 2562 (2019) — Section 23 (3) · Section 33, para. 2 · Section 37 (3) · Section 39 (4) · Section 78, para. 2
- PDPC Notification on Criteria for Deletion, Destruction or Anonymisation of Personal Data B.E. 2567 (2024) — Clause 3 · Clause 4 · Clause 9
- TDPG 4.0 (Thailand Data Protection Guidelines) — guidance, not law — G7 · G7.1–G7.6 · G8.1 · G9.3
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)