Data Breach Notification in Thailand: The 72-Hour PDPA Rule

What Triggers Data Breach Notification in Thailand

The PDPA does not limit breaches to dramatic cyberattacks. A reportable incident arises whenever a security failure leads to loss, alteration, unlawful disclosure of, or unauthorised access to personal data. In practice, Thai regulators treat all of the following as breaches:

• External attacks — ransomware, credential stuffing, database exfiltration or compromise of a cloud environment.
• Insider incidents — an employee copying a customer list before resigning, or a manager selling contact data to a third party.
• Human error — a payroll file emailed to the wrong recipient, a misconfigured storage bucket, or a mass mailing that exposes every address.
• Loss of devices or records — an unencrypted laptop, a lost backup drive, or paper files taken from an office.
• Vendor failures — a breach at your payroll bureau, call centre, marketing agency or hosting provider.

Availability incidents count as well. Say ransomware encrypts your HR system and you cannot restore employee records. The data is effectively lost, even though nobody stole it. Each of these scenarios can therefore trigger data breach notification in Thailand.

The 72-Hour Clock: When Data Breach Notification in Thailand Is Required

Section 37(4) of the PDPA sets the core duty. A data controller must notify the Office of the Personal Data Protection Committee without delay and, where feasible, within 72 hours of becoming aware of the breach. The Committee then published detailed criteria and methods for breach reporting. These appeared in the Government Gazette on 15 December 2022. Those criteria now govern how data breach notification in Thailand operates in practice.

Two points routinely surprise foreign management teams. First, awareness is judged at organisational level. The clock starts once any responsible person inside the business knows enough to conclude that a breach has probably occurred. It does not wait for the CEO in Singapore or Tokyo to be briefed. Second, the 72 hours run continuously, so a Friday-evening discovery does not pause until Monday.

The risk test that decides whether you notify

Notification is not automatic. The controller must first assess the incident. Is it likely to create a risk to the rights and freedoms of affected individuals? The regulator expects that assessment to weigh several factors:

• nature, category and cause of the breach;
• type and volume of data involved, including any sensitive data such as health, biometric or criminal-record information;
• status of the affected individuals, with particular care for children, elderly persons, patients and other vulnerable groups;
• severity and likely consequences of the harm, from fraud and identity theft to financial loss or reputational damage; and
• effectiveness of existing safeguards, such as strong encryption, and of the remedial steps already taken.

Where the analysis shows no likely risk, you may stand down. However, you must still be able to prove how you reached that conclusion. A documented, contemporaneous risk assessment is the only credible defence if the regulator later disagrees with your judgement.

When you must also tell affected individuals

Suppose the breach is likely to create a high risk to individuals. The controller must then notify those individuals without delay, together with the remedial measures taken. Customer-facing notification carries commercial consequences, so companies often want to avoid it. Yet delaying a warranted notice compounds the original failure and hands the regulator a second, more serious ground for enforcement.

What Regulators Expect in a Breach Report

A compliant report goes well beyond a one-line disclosure. Effective data breach notification in Thailand gives the regulator a coherent account of the incident and your response. Cover the following ground:

Where the full picture is not yet available, you should file on time with what you know and supplement afterwards. Waiting for a complete forensic report before filing is the most common, and most expensive, mistake. If genuine reasons prevent notification inside 72 hours, the framework allows the controller to explain the delay. Submit that explanation promptly, rather than waiting for the regulator to ask.

Penalties for Late Data Breach Notification in Thailand

Enforcement moved from theory to reality in August 2024, when the regulator imposed its first administrative fine under the PDPA. A major online IT retailer was fined THB 7 million. A leak had exposed the data of more than 100,000 customers to a fraud syndicate. The penalty combined three failures. These were inadequate security measures, no appointed data protection officer despite large-scale processing, and late reporting of the breach. Enforcement has continued since.

Administrative fines

Breaches of the security and notification duties in Section 37 attract administrative fines of up to THB 3 million. Other failures carry their own ceilings, and the regulator has shown that it will stack findings from a single incident. A modest breach can therefore generate a materially larger penalty once related compliance gaps come to light during the investigation.

Civil claims and punitive damages

Affected individuals may claim compensation for damage caused by a breach, whether or not the controller intended the harm. Critically, the court may award punitive damages of up to twice the actual compensation. Class-style consumer actions remain uncommon in Thailand, but a large consumer or employee database creates meaningful aggregate exposure.

Criminal and personal exposure

Unlawful disclosure or use of sensitive personal data can attract criminal liability, including imprisonment. Where the offender is a company, a director or manager may also face personal liability. That risk arises if the offence flowed from their instruction or omission. For foreign executives on the boards of Thai subsidiaries, that provision turns a data incident into a personal risk.

Processors, Vendors and Cross-Border Groups

Most breaches in Thailand originate outside the controller’s own systems. Payroll bureaus, cloud hosts, marketing agencies, logistics partners and offshore shared-service centres all handle personal data on their clients’ behalf. Under the PDPA, a data processor that suffers a breach must notify its controller. Yet the controller remains responsible for data breach notification in Thailand, and answerable to both the regulator and the individuals concerned.

That allocation has practical consequences for how you contract. Effective data processing agreements should therefore specify:

• a processor notification deadline measured in hours, not days, so you retain usable time inside your own window;
• an obligation to preserve logs and forensic evidence, and to grant the controller access to them;
• audit and inspection rights, plus a duty to co-operate with regulator enquiries;
• clear indemnities and liability caps that reflect the true value of the data at stake; and
• controls over sub-processors and any onward transfer of data outside Thailand.

Multinational groups face an additional complication. A single incident at a regional platform can trigger Thai, European and other Asian duties at once. Each regime has its own clock and threshold. Global playbooks written around the GDPR do not automatically satisfy Thai requirements. The local entity still needs a Thai-law assessment on the record. The same applies to data subject access requests, which spike sharply after a publicised incident.

Why 2026 Raises the Bar for Thai Compliance Programmes

Thai regulators are steadily shifting from awareness-building to verifiable accountability. In July 2026 the regulator presented draft guidance on records of processing activities. That register documents what data an organisation holds, why it holds it, who it shares data with, and where the data travels. The draft treats those records as the backbone of accountability rather than an administrative formality. It links them to privacy notices, retention schedules, vendor contracts, impact assessments and breach response. It sits alongside the emerging PDPA certification framework as evidence of the same regulatory direction.

The practical link to breach response is direct. When an incident occurs, the first questions never change. What data sat in the affected system? Whose data was it? Which vendors touched it? Did any of it leave Thailand? Organisations with accurate processing records answer those questions in hours. Organisations without them spend the entire 72-hour window simply trying to establish the facts. They then file a vague report, and a weak filing invites the regulator to look harder at everything else.

A Practical 72-Hour Response Plan

Speed depends on preparation. The sequence below reflects what works when a real incident lands on a Thai management team. Data breach notification in Thailand then becomes an immediate deadline.

Hours 0–6: contain and convene

• Isolate affected systems, preserve logs, and stop the loss before it widens.
• Convene the incident team: legal, IT security, HR, communications and the data protection officer.
• Record the exact time and manner of discovery. This timestamp defines your deadline.
• Engage external counsel early so that the investigation can proceed under legal direction.

Hours 6–36: scope and assess

• Identify the categories and volume of records affected, and flag any sensitive data.
• Document the risk assessment against the regulator’s criteria, and reach a reasoned conclusion on both thresholds.
• Check contracts with affected enterprise customers for separate notification deadlines, which are often shorter than 72 hours.
• Assess whether other regimes apply, including financial-sector, telecoms or foreign data protection rules.

Hours 36–72: notify and communicate

• File the regulator notification, supported by the documentation you have assembled.
• Prepare individual notices where the high-risk threshold is met, with clear guidance on protective steps.
• Brief customer-facing teams so that responses stay consistent and legally accurate.
• Log every decision and its rationale, because the file itself becomes your evidence of good faith.

After day three

• Complete the forensic investigation and supplement the regulator filing.
• Remediate the root cause and update security controls, contracts and processing records.
• Run a post-incident review and revise the response plan accordingly.

Where Foreign-Invested Businesses Get Caught Out

Several patterns recur among international companies that face data breach notification in Thailand for the first time. Recognising them early is usually far cheaper than remediating them after an incident.

• No local decision-maker. The Thai entity waits for regional headquarters to approve a filing, and the deadline passes while approvals circulate.
• Assuming group policies suffice. A GDPR playbook does not map cleanly onto Thai thresholds, forms or expectations.
• No appointed data protection officer. Businesses processing large volumes of personal data may be required to appoint one. Its absence is now a documented enforcement trigger.
• Unmapped shadow systems. Marketing databases, recruitment spreadsheets and messaging-app customer lists rarely appear in the official data inventory, yet they leak.
• Weak vendor terms. Standard supplier agreements often contain no breach-notification clause at all, leaving the controller dependent on goodwill.
• Silence as strategy. Deciding not to report in the hope that nobody notices converts a manageable incident into an aggravated one.

Foreign directors should also confirm that their Thai entity, not just the group, holds the documentation. Regulators examine the local company, and a policy stored on a global intranet in another language rarely satisfies that inspection.

Data Breach Notification in Thailand: FAQs

Vendors, cross-border groups and legal support

Conclusion

Data breach notification in Thailand rewards organisations that prepare, and it punishes those that improvise. The duties themselves are compact. Assess the risk, report inside 72 hours, and warn individuals where the risk is high. Meeting them under pressure demands more. You need an accurate data map, contracts that force vendors to speak quickly, a local decision-maker and a documented assessment process. Companies that build those foundations before an incident treat a breach as a managed legal event. Companies that do not usually discover, too late, that the regulator’s questions are far easier to answer in advance.