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.
Most 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 2026 Cost of a Data Breach Report, organisations take an average of 247 days to identify and contain a breach. Most notification regimes in this article give 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 | Only in some cases (in Indonesia: attacks that seriously disrupt a system, and incidents at banks, payment providers and vital information infrastructure) |
Who is involved | Security, legal, communications, the DPO, and a regulator | Security team |
Clock | Usually 72 hours, set by statute | Internal SLA, or a sector deadline (1 to 24 hours in Indonesia) |
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 unauthorised 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 crystallises. 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 knew, 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. Most regimes in this article accept a preliminary filing with a supplementary report to follow. Late is punished. Partial, if you follow up, rarely is.
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. Then test that the fix holds, for example with a penetration test of the same entry point.
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 ran 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 organisation understood what happened and changed something as a result.
Data Breach Notification Requirements
Most data protection laws give an organisation 72 hours from the moment it becomes aware of a breach to notify the regulator.
The EU made it the reference point when the GDPR took effect in 2018 (Article 33). Indonesia, Malaysia, the Philippines, Thailand, and Vietnam all use the same figure. 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, and in certain cases the public, such as when the breach disrupts public services or seriously affects the public interest
- Malaysia: the regulator first, then individuals within a further seven days where significant harm is likely
- 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 | Lembaga PDP (not yet formed; Komdigi supervises for now) | 3 x 24 hours | Awareness of the failure to protect the data (from 16 January 2027: when it is known with certainty, duly and reasonably, under PP 33/2026) | Yes, same 3 x 24 hours, no risk threshold |
Singapore | PDPC | 3 calendar days after assessment concludes | Completion of assessment (expected within 30 days) | Where significant harm is likely |
Malaysia | Personal Data Protection Commissioner | 72 hours | Occurrence of the breach (the guideline’s own examples count from awareness) | Within 7 days of notifying the Commissioner, where significant 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, or reasonable belief in, a breach | Where there is a real risk of serious harm, within the same 72 hours |
Thailand | PDPC | 72 hours (a delay may be excused if explained within 15 days) | Awareness | Where high risk to rights and freedoms |
Australia | OAIC | Assessment within 30 days | Awareness of reasonable grounds to suspect a breach | Where serious harm is likely |
United States | State regulators; CISA for critical infrastructure (CIRCIA, once in force) | No general federal deadline; CIRCIA will require 72 hours for critical infrastructure once its final rule takes effect | 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.
Indonesia’s implementing regulation for UU PDP, Government Regulation (PP) No. 33 of 2026, applies from 16 January 2027. It keeps the deadline of 3 x 24 hours (72 hours), counts it from when the failure to protect personal data is known with certainty, duly and reasonably, and requires the notice to include details of your data protection officer (PPDP) or a designated contact person.
Some Indonesian sectors also run shorter clocks for cyber incidents, whether or not personal data is involved. Commercial banks send OJK an initial notice within 24 hours of knowing about an incident (SEOJK 29/2022). Payment providers and other firms regulated by Bank Indonesia send it an initial notice within 1 hour of knowing (PBI 2/2024). Operators of vital information infrastructure (IIV) report to their sector CSIRT, copied to the national CSIRT at BSSN, within 1 x 24 hours of finding the incident (Perpres 82/2022). Outside those sectors, PP 71/2019 still requires any electronic system operator to report an attack that seriously disrupts its systems to law enforcement and the relevant ministry or agency at the first opportunity.
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 unauthorised 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 ran 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 head of BSSN, Indonesia’s national cyber agency, later told parliament that only 2% of the data held at the centre had been backed up.
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
Most deadlines in this article start at awareness. That is the part organisations control most and think about least.
IBM’s 2026 report puts the average time to identify and contain a breach at 247 days. Malaysia’s guideline words its deadline as 72 hours from the occurrence of the breach, so read literally, detection time comes straight out of your window. An organisation that takes months to detect is months past that deadline 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 3 in the morning 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.
If the clock is already running, Zentara’s incident response team can help you contain the breach and preserve the evidence.
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, usually from awareness, including GDPR, Indonesia, Malaysia, Thailand, and Vietnam. Australia allows 30 days for assessment and the United States has no single federal deadline. In Indonesia, banks and payment providers also have shorter cyber-incident deadlines: an initial notice to OJK within 24 hours for banks, and to Bank Indonesia within 1 hour for payment providers.
3. When does the 72-hour clock start?
Under GDPR, Indonesia, Thailand, and Vietnam, from awareness or detection. In Indonesia, from 16 January 2027, PP 33/2026 starts it when the breach is known with certainty, duly and reasonably. 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?
UU PDP says to notify the affected people and the PDP agency (lembaga PDP), which has not been formed yet. Until it is, Komdigi supervises personal data protection through its Directorate General of Digital Space Supervision. No regulation yet names a channel for breach notices, so confirm it with Komdigi before you file. Sector rules add their own reports: commercial banks send OJK an initial notice within 24 hours, payment providers send Bank Indonesia one within 1 hour, and operators of vital information infrastructure (IIV) report to their sector CSIRT, copied to the national CSIRT at BSSN, within 1 x 24 hours of finding the incident.
5. What if I do not have all the facts within 72 hours?
File on the information available. Most regulators accept a preliminary notification followed by a supplementary report. Late filing is usually 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 duty to tell individuals. Large breaches still go to the regulator in Singapore (500 or more people) and Malaysia (more than a thousand). Indonesia’s Article 46 has no explicit risk threshold, so notify and document the reasoning either way.
