The First 72 Hours of a PDPA Data Breach: A Checklist for Malaysian Organisations
Nobody reads the breach response plan until the morning they need it. By then, the questions come all at once: is this even a notifiable breach, who tells the Commissioner, what do we say to customers, and what is IT allowed to touch?
This is the checklist we would want on the table that morning, organised by the hours that follow. It covers the legal notification side of a personal data breach under the PDPA. The technical containment runs in parallel and belongs to your IT or incident response team.
The rules in one box
- Section 12B of the PDPA, in force since 1 June 2025, requires a data controller to notify the Personal Data Protection Commissioner of a personal data breach as soon as practicable, and to notify affected individuals without unnecessary delay where the breach causes or is likely to cause significant harm.
- JPDP's breach notification guideline sets 72 hours for the Commissioner, a written explanation with evidence if you are late, and seven days after that for affected individuals.
- Significant harm includes physical harm, financial loss, a negative effect on credit records, damage to or loss of property, and breaches affecting more than 1,000 people.
- Failing to notify the Commissioner is an offence carrying a fine of up to RM250,000, up to two years' imprisonment, or both. Every breach, notified or not, goes in a register kept for at least two years.
Before anything else: start the clock and the log
Sources disagree on exactly when the 72 hours legally begin, so do not spend the first morning debating it. Take the cautious reading: write down the time the breach was first suspected, and run every deadline from that moment. Then open a single incident log and record every decision, who made it and why. That log becomes your evidence if the Commissioner later asks what you did and when.
Hour 0 to 4: contain and assemble
| Task | Owner |
|---|---|
| Record the time the breach was first suspected, and open the incident log | DPO |
| Contain the technical cause without destroying evidence (isolate, do not wipe) | IT lead |
| Convene the breach team: DPO, IT, legal, communications, a senior manager with authority to decide | DPO |
| If a vendor is involved, tell them in writing to preserve evidence and report what they know | DPO / procurement |
| Stop any planned communication about the incident until the team agrees the message | Communications |
Hour 4 to 24: establish what happened, and to whom
The notification decision depends on facts you probably do not have yet. The job of the first day is to get them.
| Question | Why it matters |
|---|---|
| What personal data was involved? Names, IC numbers, financial details, health data? | Drives the significant harm assessment and what individuals must be told |
| How many people are affected, or could be? | More than 1,000 affected people is significant harm on its own |
| Was the data encrypted, and is the key safe? | Changes how likely harm actually is |
| Is the breach still happening? | An ongoing breach changes the containment and the message |
| Which processors, systems and countries are involved? | Processors must help you; overseas processing may involve other regulators |
Then run the significant harm assessment, and write the answer down with its reasons, including when the answer is no. A documented decision not to notify is defensible. An undocumented one is not.
Hour 24 to 48: decide and draft
- Make the notification decision. If the breach causes or is likely to cause significant harm, you are notifying. When in genuine doubt, the cautious course is to notify with what you know and update later.
- Draft the Commissioner notice using the details the guideline asks for: what happened, the data and people involved, the likely consequences, what you have done to contain it, and a contact point, usually the DPO.
- Draft the notice to affected individuals in plain language: what happened, what data of theirs was involved, what they should do now (for example, watch for phishing using their details), and who to contact.
- Check your other regulators. Financial institutions also answer to Bank Negara Malaysia: under its revised customer information policy (31 October 2025), breaches causing significant harm or affecting more than 1,000 customers must be notified to BNM and to affected customers as well. One incident can mean two notifications with different formats.
- Brief management and the people who will answer the phones. Customer service needs a script before customers start calling.
Hour 48 to 72: notify and record
| Task | Owner |
|---|---|
| Senior management approves the Commissioner notice | Senior manager |
| Submit the notice to the Commissioner within the 72 hours | DPO |
| If you cannot meet 72 hours, prepare the written explanation and supporting evidence for the delay | DPO / legal |
| Record the submission, its time and reference in the incident log | DPO |
| Enter the breach in the breach register | DPO |
After 72 hours: individuals, then lessons
- Notify affected individuals within seven days of notifying the Commissioner, where significant harm is likely.
- Keep the register current. Every breach, notified or not, stays on it for at least two years.
- Hold a review within a few weeks. What failed, what the response got right, and what changes: a control, a vendor contract, a procedure, training.
- Fix the processor contracts if this breach started at a vendor. JPDP's guideline expects controllers to require processors, by contract, to report breaches promptly and help with notification.
What to prepare before you ever need this
The guideline also expects a breach management and response plan, and periodic training, awareness and simulation exercises so that people have practised the response. In practice, three things make the first 72 hours manageable: a significant harm assessment method your DPO can apply quickly, notice templates already drafted, and a tabletop exercise that has run the whole sequence against the clock at least once.
Frequently asked questions
Do we have to notify the Commissioner of every breach?
No. The guideline requires notification where the breach causes or is likely to cause significant harm, which includes physical harm, financial loss, a negative effect on credit records, damage to or loss of property, or a breach affecting more than 1,000 people. Every breach should still be recorded in your register with the reasons for the decision.
What if we miss the 72 hours?
Notify anyway, as soon as you can, with a written explanation of the delay and supporting evidence, as the guideline requires. A late notification with a clear record of what you were doing is far better than none.
Who notifies: us or our IT vendor?
The duty to notify the Commissioner sits with the data controller, which is usually you. Your vendor, as a data processor, should tell you promptly and help you meet the deadline, and your contract should say so.
Is this the same as notifying BNM?
No. If you are a BNM-regulated financial institution, its customer information policy has its own breach notification duty. Map both processes together so one incident does not become two findings.