Most organisations do not fail at data breach response because they lack a plan. They fail because the clock had already been running for weeks before anyone noticed.
Notification deadlines start when you become aware of a breach. That single word governs everything that follows. An organisation that detects an intrusion in an hour has three days to assess, contain, and file. An organisation that detects it in ninety days has the same three days, but the damage is done, the data is gone, and the regulator will ask why it took so long to find out.
This guide covers what to do in the first 72 hours, what the law requires in Indonesia, Singapore, Malaysia, Vietnam, and Europe, and where most response efforts break down.
What Is Data Breach Response?
Data breach response is the sequence of actions an organisation takes from the moment it discovers that personal data has been compromised: contain the incident, assess what was exposed, notify the people and regulators who need to know, and remediate the cause.
Two clocks run at once, and they are not the same clock.
The first is technical. How fast can you isolate the affected systems, preserve the evidence, and close the entry point? That one is measured in minutes and hours, and it is governed by your monitoring and your playbooks.
The second is legal. How long until you must file with a regulator, and when did that countdown begin? That one is measured in days, and it is governed by statute.
According to IBM’s 2025 Cost of a Data Breach Report, organisations take an average of 241 days to identify and contain a breach. Every notification regime in this article gives you three. The gap between those two numbers is the whole problem.
Breach Response vs Incident Response
Breach response is a subset of incident response. Every breach is an incident. Most incidents are not breaches.
| Breach Response | Incident Response | |
| Trigger | Personal data has been compromised | Any security event: failed login spike, malware detection, misconfigured server, phishing attempt |
| Legal obligation | Statutory duties attach immediately | None by default |
| Who is involved | Security, legal, communications, the DPO, and a regulator | Security team |
| Clock | 72 hours, set by statute | Internal SLA |
| Forensic work | Same | Same |
| Consequence of getting it wrong | Regulatory penalty, public notification, enforcement action | Operational |
Data Breach Response Hour by Hour
The four phases below map to how a real incident runs and to the deadlines you are working against. The timings are not arbitrary. They are what the 72-hour rule leaves you.
Hour 0 to 1: Containment and Evidence
Isolate the affected systems from the network. Do not power them down.
That second instruction gets ignored constantly, and it destroys the investigation. Volatile memory holds running processes, live connections, and malware that never wrote itself to disk. Pull the power and it is gone. Disconnect at the switch instead: the machine stays alive, the attacker’s access is cut.
Preserve the logs before anything else touches them. Log rotation does not pause for your incident, and a 30-day retention window will overwrite the evidence of an intrusion that began 45 days ago.
Then rotate credentials. Removing the attacker’s tooling does not remove the attacker’s access. Rotate service accounts, API keys, and privileged access, and check for accounts created during the intrusion window.
Finally, check your vendors. The US Federal Trade Commission’s guidance is blunt on this: if a contractor has network access, verify what they can still reach before assuming the perimeter is closed.
Hour 1 to 24: Investigation and Scope Assessment
Take forensic images before you remediate. Rebuild a server and its state at the time of compromise is gone.
Then answer the question the law asks. Not what data was stolen, but what data was reachable. In most regimes the trigger is unauthorized access, not proven theft. If an attacker held administrator credentials on a customer database for six days, the absence of proof they copied it is not proof they did not.
Somewhere in this window, awareness crystallizes. You move from “something looks wrong” to “personal data has been compromised.” In most countries that is the moment the legal clock starts, so it needs a timestamp, a named decision-maker, and a written record. If a regulator asks when you know, the answer has to be a document.
Hour 24 to 72: Notification
Assess the breach against the thresholds that apply to you, then file. A regulator filing typically needs the nature of the breach, the categories and volume of data affected, the number of people involved, the remediation taken, and a named contact point.
File on incomplete information rather than late. Most engineering teams resist this, because they want the full picture before they report. Every regime in this article accepts a preliminary filing with a supplementary report to follow. Late is punished. Partial is not.
Notifying individuals is a different job: a communications problem with a legal deadline attached, which is why the templates have to exist before the incident. People need four things. What happened, what data of theirs was involved, what you are doing, and what they should do now. Name one spokesperson and publish one page as the source of truth.
Day 3 to 30: Remediation and Recovery
Close the root cause, not the symptom. If the entry point was a stolen credential, patching the server fixes nothing.
Restore from a clean point. The restore point must sit before initial access, not before first visible damage. In ransomware cases those dates are often weeks apart, and restoring to the day before the encryption is fired usually restores the attacker’s foothold along with the files.
Then run the post-incident review and write it down. It is the document a regulator asks for, and the evidence that your organization understood what happened and changed something as a result.
Data Breach Notification Requirements
Most data protection laws give an organization 72 hours from the moment it becomes aware of a breach to notify the regulator.
The EU set that number in 2018 under Article 33 of the GDPR. Indonesia, Malaysia, the Philippines, Thailand, and Vietnam have all since adopted it. The deadline converged. Everything underneath it did not.
Who else must be notified
- GDPR: individuals only where the breach poses a high risk to them
- Indonesia: both the regulator and the affected people, no risk filter
- Malaysia: the regulator first, then individuals within a further seven days
- Vietnam: both inside the same 72 hours, for certain data types
Data Breach Reporting Deadlines
| Jurisdiction | Regulator | Deadline to regulator | Clock starts | Notify individuals |
| Indonesia | Komdigi (Lembaga PDP not yet operational) | 3 x 24 hours | Awareness of the failure to protect | Yes, same 3 x 24 hours, no risk threshold |
| Singapore | PDPC | 3 calendar days after assessment concludes | Completion of assessment (assessment capped at 30 days) | Where significant harm is likely |
| Malaysia | Personal Data Protection Commissioner | 72 hours | Occurrence of the breach | Within 7 days of notifying the Commissioner, where significantly harm is likely |
| Vietnam | MPS A05 | 72 hours | Detection | Same 72 hours for finance, banking, biometric, and location data |
| EU / UK | Lead supervisory authority / ICO | 72 hours | Awareness | Without undue delay, where high risk |
| Philippines | NPC | 72 hours | Knowledge of reasonable belief | Yes, same 72 hours |
| Thailand | PDPC | 72 hours (extendable to 15 days with justification) | Awareness | Where high risk to rights and freedoms |
| Australia | OAIC | Assessment within 30 days | Awareness of grounds of suspect | Where serious harm is likely |
| United States | State-by-state; CIRCIA for critical infrastructure | No general federal deadline; 72 hours under CIRCIA | Varies | Varies by state |
Sources: Indonesia UU PDP Article 46, Singapore PDPC, Malaysia Department of Personal Data Protection, Vietnam Decree 356/2025/ND-CP, GDPR Article 33, ICO, OAIC.
Common Mistakes of Data Breach Response
Most of the failures below are not technical. They are decisions made under pressure by people who are trying to do the right thing, and each one is defensible in the moment. They only look wrong later, in a regulator’s file.
1. Powering down the compromised machine
The instinct is to stop the bleeding. The effect is to destroy the memory-resident evidence that tells you what the attacker did and how far they reached. Isolate the network connection instead, and leave the machine running.
2. Delaying the assessment to defer the clock
Stretching the assessment, or running an unhurried investigation that nobody formally calls a breach, looks like a way to buy time. It is the same mistake either way. Regulators expect assessment to begin as soon as practicable, and slow-walking a simple incident invites the scrutiny you were avoiding.
3. Assuming no proof of theft means no breach
The notification trigger in most regimes is unauthorized access, not confirmed exfiltration. If an attacker has reach, you have an obligation. The absence of proof they took the data is not evidence they left it.
4. Restoring from a compromised backup
The restore point must precede initial access, not first visible damage. In ransomware cases those dates are often weeks apart. Restore to the day before the encryption is fired and you usually restore the attacker’s foothold along with the files.
5. Notifying without a designated spokesperson
Several people speaking to customers, media, and the regulator produce slightly different accounts of the same incident. Those differences read as contradictions, and contradictions are what a regulator remembers.
6. Treating the deadline as the constraint
The deadline is fixed. Your detection time is not. Organisations that miss notification windows almost never miss them because the paperwork was slow.
Real-World Data Breach Response Examples
PDNS 2 (2024)
Indonesia’s Temporary National Data Centre was compromised by the Brain Cipher ransomware group. More than 200 government agencies lost access to services, immigration systems at airports failed, and the attackers demanded USD 8 million. The government confirmed that the affected data had no backup.
The incident is the clearest domestic illustration of the argument this article makes: the failure was not in the response, it was in everything that should have been in place before it. Detection, segmentation, and recoverable backups are not response measures. They are preconditions for one.
SingHealth (2018)
Attackers accessed the non-medical personal records of approximately 1.5 million patients, including the Prime Minister. The subsequent Committee of Inquiry found that staff had noticed suspicious activity but that escalation was slow and incomplete.
Singapore’s PDPC imposed a combined financial penalty of SGD 1 million on SingHealth and IHiS. The finding that mattered was not technical. It was that the people who saw the signal did not have a path to act on it fast enough.
Both incidents share the same shape. The organisations were not undone by the sophistication of the attack. They were undone by the time between compromise and comprehension.
Detection Speed Determines Response Time
Every deadline in this article starts at awareness. That is the part organisations control most and think about least.
IBM puts the average time to identify and contain a breach at 241 days. Malaysia gives you 72 hours from occurrence, so detection time comes straight out of your window. An organization detecting at the industry average there has been in violation for 238 days before it knows there is a problem.
The constraint is not how fast you can file. It is how fast you can find out.
Which changes what breach readiness means. It is not a document in a drawer. It is whether your logs go back far enough to reconstruct an intrusion that started six weeks ago, whether your monitoring covers the systems where personal data actually lives, and whether an alert at 3am on a Sunday reaches someone who can act on it.
Those are engineering questions. They get answered before the incident or not at all.
Zentara’s Managed SOC exists for continuous monitoring, threat detection tuned to the systems holding your regulated data, and a 15-minute response SLA on critical alerts. The goal is to close the distance between compromise and awareness, so that when the clock starts, you still have all 72 hours.
Talk to our team about your detection coverage.
Frequently Asked Questions
1. What are the first steps in a data breach response?
Isolate the affected systems without powering them down, since volatile memory is evidence. Preserve logs before rotating credentials. Then begin scope assessment to determine which data was reachable.
2. How long do I have to report a data breach?
Most regimes give 72 hours from awareness, including GDPR, Indonesia, Malaysia, Thailand, and Vietnam. Australia allows 30 days for assessment and the United States has no single federal deadline.
3. When does the 72-hour clock start?
Under GDPR, Indonesia, Thailand, and Vietnam, from awareness or detection. In Singapore, from the completion of the assessment that the breach is notifiable, though the assessment itself must be prompt.
4. Who do I notify of a data breach in Indonesia?
The Lembaga PDP is not yet operational. Notification currently goes to Komdigi’s Directorate General of Digital Space Supervision, with BSSN involved where the organisation operates vital information infrastructure.
5. What if I do not have all the facts within 72 hours?
File on the information available. Regulators accept preliminary notifications followed by supplementary reports. Late filing is treated more severely than incomplete filing.
6. Does a contained breach still require notification?
It depends on the regime. Singapore, Malaysia, and GDPR gate notification on a harm or risk threshold, so effective remediation can remove the obligation. Indonesia’s Article 46 has no explicit risk threshold, so notify and document the reasoning either way.
