The 72-Hour Clock: What Happens When Your Firm Has a Data Breach Under Thailand's PDPA

A staff member sends a client’s financial statements to the wrong recipient by email. A laptop containing case files is left in a taxi. A shared drive link intended for one client is accidentally left accessible to anyone with the link. None of these incidents involve malicious intent, and none of them are hypothetical for a professional services firm handling client data every day. What matters under Thailand’s Personal Data Protection Act is not whether the exposure was deliberate. What matters is what the firm does in the hours immediately after it becomes aware.

The Personal Data Protection Committee has spent the past two years moving from an education-first posture to active enforcement. A recent wave of PDPC decisions imposed fines totalling THB 21.5 million across five cases, citing failure to report data breaches and inadequate security measures. The pattern in these decisions is instructive: the absence of a functioning Data Protection Officer role, or a DPO function that exists on paper but was not actually engaged when the incident occurred, was treated as a serious aggravating factor rather than a minor procedural gap. For a boutique law or accounting firm, this signals that the PDPC is looking past the privacy policy on the website and asking whether the firm’s internal process actually worked when it mattered.

What the 72-Hour Obligation Actually Requires

Under the PDPA, a data controller must notify the PDPC without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to the rights and freedoms of data subjects. The clock starts at awareness, not at confirmation. A firm does not get 72 hours from the point it has fully investigated what happened, identified every affected record, and drafted a complete report. The clock starts from the moment someone at the firm reasonably suspects that a breach involving personal data has occurred.

This distinction is where most boutique firms are exposed. A firm without a pre-built response process spends the first hours after discovering a potential incident deciding who is responsible for what: who assesses the scope, who decides whether the incident meets the reporting threshold, who drafts the notification, and who actually submits it to the PDPC. If those decisions are being made for the first time during an active incident, a meaningful portion of the 72-hour window is consumed before any substantive work on the notification itself has begun.

The notification threshold itself requires judgment. Not every incident triggers the 72-hour obligation; only breaches likely to result in a risk to data subjects’ rights and freedoms require notification to the PDPC, and breaches posing a high risk require notification to the affected data subjects as well. A firm needs a documented way to make this assessment quickly, because the assessment itself is part of what consumes the clock.

Controller and Processor: A Distinction Most Firms Have Not Mapped

A professional services firm frequently occupies two different roles under the PDPA simultaneously, and the obligations differ depending on which role applies to a given dataset. For its own staff records, prospect data, and marketing lists, the firm is typically a Data Controller, directly responsible for determining how that data is processed and directly obligated to notify the PDPC in the event of a breach. For client data held and processed on behalf of the client, such as financial records prepared for a client’s own regulatory filings, the firm may be acting as a Data Processor, with a narrower but still real obligation: notifying the controller, meaning the client, without undue delay so the client can meet its own notification obligations.

Most boutique firms have never formally mapped which category applies to which category of data they hold. This matters in practice because the response process differs. A breach involving the firm’s own staff data requires the firm to run its own PDPC notification process. A breach involving client data held as a processor requires the firm to notify the affected client promptly and support the client’s own response, which is a different workflow with a different set of stakeholders and a tighter internal deadline, since the client’s own 72-hour clock is often running in parallel.

Four Elements an Incident Response Plan Needs Before an Incident Happens

An effective response to a data breach does not start with drafting a notification. It starts with four elements that need to already exist before any incident occurs.

A designated point of contact. One person, or a small defined group, needs clear authority to be notified the moment any staff member suspects a data incident, and clear authority to activate the firm’s response process without needing to seek approval first. Ambiguity about who owns this decision is the single most common reason firms lose time in the opening hours.

A data inventory that shows what could have been exposed. When an incident is discovered, the first substantive question is scope: what categories of personal data were involved, how many individuals are potentially affected, and how sensitive is the data. A firm that can answer this by consulting a maintained inventory of what data lives where answers this in minutes. A firm that has to reconstruct the answer by asking staff to recall what was in a particular folder or email thread loses hours, sometimes days.

A notification template. The PDPC notification requires specific information: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed to address the breach. Drafting this from a blank page during an active incident is slower and more error-prone than adapting a pre-built template that already has the structure in place.

A log of what happened and when. From the moment of discovery, a firm needs a running, timestamped record of what was found, what actions were taken, and what decisions were made. This log serves two purposes: it is the raw material for the PDPC notification itself, and it is the evidence the firm can point to later if its response process is ever questioned.

Why Data Footprint Matters to Response Speed

The single largest factor in how quickly a firm can assess breach scope is how contained its client data footprint already is. A firm whose client data lives across email inboxes, personal cloud storage, messaging apps, and a handful of shared drives cannot answer the scope question quickly, because answering it requires searching across every one of those locations and hoping nothing was missed. A firm whose client data lives in a small number of governed systems, where every document and communication is associated with a specific matter and client, can answer the same question by querying one system.

This is not a new argument for consolidating tools; it is a direct, practical consequence of the enforcement environment the PDPC has created. The 72-hour clock does not adjust for a firm’s data being scattered. A firm that has already reduced shadow IT and consolidated client data into a governed system is not just reducing its general compliance risk. It is materially faster at the exact task that determines whether it meets a hard regulatory deadline.

The Client Relationship Dimension

A breach involving client data is also a trust event, independent of the regulatory notification requirement. A client who learns that their financial records or contract details were exposed will judge the firm not only by whether a breach occurred but by how quickly and professionally the firm responded. A firm that can tell a client, within hours, exactly what was affected, what has been done, and what the client needs to know, is demonstrating the kind of operational competence that retains a client relationship through a difficult moment. A firm that takes days to determine the scope of its own incident is demonstrating the opposite, regardless of whether the underlying breach was serious.

This is a reason to build incident response capability proactively rather than treating it as a purely defensive compliance cost. The firms that have this capability in place are better positioned not only to meet the PDPC’s deadline but to preserve the client relationships that a breach puts at risk.

FirmFlow and Breach Scope Assessment

FirmFlow’s centralized matter record means that if an incident occurs, a firm can answer the two hardest opening questions immediately: what data was potentially affected, and who does it belong to. Because client documents, correspondence, and personal data are held within a structured matter record rather than scattered across email threads and personal drives, a firm can query exactly what was accessible to a compromised account or exposed link, and exactly which clients and matters that data relates to.

That answer, available in minutes rather than days, is the difference between a contained 72-hour notification, backed by an accurate scope assessment and a clear account of remedial steps, and a scramble that either misses the deadline or files a notification built on an incomplete understanding of what actually happened. The PDPC’s enforcement pattern makes clear that the difference between those two outcomes is not a technicality. It is the difference between a firm that demonstrated it had a functioning data protection process and one that did not.

The 72-hour clock is not going away, and the PDPC’s enforcement posture suggests it is only becoming more consequential. The time to build the response capability that makes that deadline achievable is now, while there is no active incident, not during the first hour after discovering one.