At 2 a.m., you receive a call from the IT team reporting that someone has gained unauthorized access to the customer database. The 72-hour countdown begins. You have limited time to assess the situation, contain the damage, notify the PDPC, and inform affected data subjects. Every minute matters.
This article walks you through the 72-hour timeline in detail, including what needs to be done at each stage.
What the law requires
Section 37(4) of the PDPA requires a data controller to notify the PDPC of a personal data breach without delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals.
If the breach is likely to result in a high risk to the rights and freedoms of individuals, affected data subjects must also be notified without delay.
The 72-hour timeline: Step by step
Hours 0-4: Detection & Confirmation
Objective: Confirm whether a data breach has actually occurred.
- Review the initial indicators — Is the detected event truly a data breach, or just a general security incident? Under the PDPA, a data breach means an incident that causes personal data to be leaked, lost, accessed, used, disclosed, altered, or destroyed without authorization.
- Activate the Incident Response Team — DPO, IT Security, Legal, Communications, and relevant executives.
- Document everything — Record the time of detection, who detected it, what was found, and the actions taken. Every decision should be documented.
Key point: The 72-hour period starts when you become "aware of the incident," not when it is fully confirmed. If there are reasonable grounds to believe a breach has occurred, the clock starts immediately.
Hours 4-12: Containment & Assessment
Objective: Stop the damage from spreading and assess the scope.
- Contain the incident — Cut off unauthorized access, close the exploited vulnerability, and isolate affected systems. However, do not destroy evidence.
- Assess the scope — What data was accessed? How much? Did it include sensitive data? How many individuals were affected?
- Assess the risk — What is the level of risk to the rights and freedoms of data subjects? Consider the type of data, volume, nature of the exposure, and the likelihood of misuse.
Hours 12-24: Notification Preparation
Objective: Prepare complete notification documentation.
- Decide whether notification is required — If the breach poses a risk to the rights and freedoms of individuals, which in most cases it does, the PDPC must be notified.
- Prepare the PDPC report — Draft a report covering all required reporting points (see details below).
- Prepare data subject notifications — If the breach poses a high risk, prepare the message to affected data subjects as well.
Hours 24-48: Notification
Objective: Notify the PDPC and data subjects (if required).
- Notify the PDPC — Submit the breach report through the channels specified by the PDPC.
- Notify data subjects — Send notifications through direct and accessible channels such as email, SMS, or letter.
- Prepare for questions and complaints — Set up a team to handle calls and emails from notified data subjects.
Hours 48-72: Remediation & Follow-up
Objective: Address the root cause and prevent recurrence.
- Remediate the vulnerability — Permanently fix the vulnerability that caused the breach.
- Preserve evidence — Retain log files, forensic images, and all relevant evidence.
- Submit supplemental reports — If new information emerges that was not included in the initial notification, submit an additional report to the PDPC.
- Begin the Post-Incident Review — Analyze the cause, weaknesses, and prevention plan.
What must be reported to the PDPC
A breach notification report should cover at least these 7 key points:
- Nature of the breach — What happened, and by what means.
- Data affected — The categories of personal data involved and whether sensitive data was included.
- Number of affected data subjects — Or an initial estimate if the exact number is not yet known.
- Potential impact — What risks may arise for data subjects.
- Measures already taken — What has been done to contain the incident and mitigate the impact.
- Future preventive measures — The remediation plan to prevent recurrence.
- DPO contact information — The name and contact details of the DPO or designated contact person.
Important: If the scope cannot be fully assessed within 72 hours, report what is known first and submit additional information later. Do not wait until everything is confirmed before notifying, or you may miss the deadline.
Outline for a data subject notification template
A notification to data subjects should include the following:
- A clear subject line: State that this is a personal data breach notification.
- What happened: Briefly explain the incident in plain language.
- What data was affected: Specify the categories of the data subject’s data that were exposed.
- What the organization has already done: Measures taken to contain the incident and reduce the impact.
- What the data subject should do: Recommendations for self-protection, such as changing passwords, watching for phishing emails, and reviewing transactions.
- Contact channels: A phone number and email address for further inquiries.
- Data subject rights: Inform them of their right to file a complaint with the PDPC.
8 common mistakes in handling a data breach
Not realizing a breach has occurred
Many organizations lack effective monitoring systems, which means they discover a breach far too late—sometimes months after the incident. The later it is discovered, the greater the damage. This is the most common mistake and often the most severe in impact.
Deleting evidence during containment
In a panic, the IT team may format machines or delete log files to "clean things up," destroying evidence needed for investigation and reporting. The simple rule is: contain the incident, but do not erase the traces.
Waiting for complete information before notifying
This is a trap even well-intentioned organizations fall into. The 72-hour clock does not wait. If you wait until the assessment is fully complete, you will often miss the deadline. The correct approach is to notify based on what is known, then provide additional information later.
An Incident Response plan that has never been tested
Some organizations have a plan on paper but have never rehearsed it. When a real incident happens, confusion follows: no one knows who should do what, and communication channels are not ready. A plan that has never been tested is not much better than having no plan at all.
Inconsistent internal communication
Information becomes fragmented, executives receive different versions of events, and teams do not know the current status. This problem becomes significantly worse in organizations with multiple branches or departments.
Using language that is too difficult for data subjects to understand
Some notifications are filled with technical jargon that ordinary data subjects do not understand, or they are so vague that recipients do not know what action to take. A good notification must clearly answer 3 questions: What happened? How does it affect you? What should you do?
Forgetting to notify relevant Data Processors
A vendor processing data on your behalf may also hold information relevant to the breach. Failing to notify the processor can leave the incident scope unclear and may mean additional compromised data remains undetected.
Skipping the Post-Incident Review
Once the incident is over, some organizations simply move on. They do not analyze the root cause or improve their processes, so the same issue can happen again. Organizations that handle breaches well are usually those that have seriously learned from previous incidents.
Being prepared before an incident is better than scrambling after one
A data breach is a matter of "when," not "if." Every organization may face one. What makes the difference is the level of preparedness.
Strong preparedness requires 3 elements: a clear plan (Plan), a trained team (People), and ready-to-use tools (Platform).
PrivacyHub includes a Breach Management module designed specifically to support this 72-hour timeline—from incident logging, risk assessment with Genesis AI, and automated PDPC reporting, to data subject notifications and Post-Incident Review. Every step is recorded in an Immutable Audit Trail that can demonstrate the organization acted properly and lawfully.
Genesis AI helps automatically analyze breach risk, recommend required actions, and assist in drafting notification reports so your team can work quickly and accurately under tight time constraints.
Get prepared today at enersys.co.th/en/products/privacyhub
