Data breach notification Malaysia: the 72-hour rule and how to notify

The law: section 12B and the breach notification guideline

Mandatory breach notification arrived with the PDPA amendment 2024. New section 12B of the Personal Data Protection Act 2010 says that where a data controller has reason to believe a personal data breach has occurred, it must notify the Commissioner as soon as practicable, in the manner and form the Commissioner decides. Where the breach causes or is likely to cause significant harm to data subjects, the controller must also notify them without unnecessary delay. Section 12B came into force on 1 June 2025.

A personal data breach is defined in the Act as any breach of personal data, loss of personal data, misuse of personal data, or unauthorised access to personal data. That covers far more than hacking: a misdirected payroll email, a lost laptop, a public cloud folder, or an employee browsing customer records without a reason are all breaches.

The Commissioner’s Guideline on Data Breach Notification, issued in February 2025, fills in the thresholds, timelines, content and method. Failing to notify the Commissioner under section 12B(1) is an offence with a fine of up to RM250,000, imprisonment of up to 2 years, or both.

When you must notify: significant harm and significant scale

Not every breach goes to the Commissioner. Under the guideline, you notify the Commissioner if the breach:

• causes or is likely to cause significant harm, or
• is of significant scale, meaning it affects more than 1,000 data subjects.

A breach causes significant harm where there is a risk that the compromised data:

1. could result in physical harm, financial loss, a negative effect on credit records, or damage to or loss of property;
2. could be misused for illegal purposes;
3. consists of sensitive personal data (health, religious beliefs, offences, biometric data and the other sensitive categories); or
4. could, combined with other personal information, enable identity fraud.

Scale on its own triggers only the Commissioner notice. Telling individuals depends on significant harm. So a leak of 5,000 newsletter email addresses with nothing else may need a Commissioner notice but not individual notices, while a leak of 50 IC numbers with bank details needs both.

If you decide a breach is below both thresholds, write down why. That reasoning goes in the breach register.

The 72-hour clock to the Commissioner

Notify the Commissioner as soon as practicable and no later than 72 hours. The guideline speaks of 72 hours from the breach, and clarifies that the period runs from when the controller discovers it, whether it detects it itself or is told about it, for example by a processor, a customer or a researcher. On being alerted to a security incident, run a quick preliminary investigation to confirm whether personal data is involved, but do not let that investigation eat the 72 hours.

The 72 hours are calendar hours, not working hours. A breach confirmed on Friday at 6pm is due by Monday at 6pm.

What the notice should cover, as far as known: when and how the breach was detected, its nature and suspected cause, the types of personal data, the number of data subjects and records, the systems affected, likely consequences, a timeline, containment and recovery steps, measures for affected people, and the DPO’s or a contact person’s details. If some facts are not yet available, submit what you have and provide the rest in phases, no later than 30 days after the first notice.

Submit through the notification form on the Department of Personal Data Protection (JPDP) website, or as the guideline’s form by email or hard copy. The notice counts as submitted once the Commissioner issues a confirmation. If you miss 72 hours, you must explain the delay in writing, with supporting evidence.

Notifying data subjects within 7 days

Where the breach causes or is likely to cause significant harm, tell the affected individuals without unnecessary delay and no later than 7 days after the initial notice to the Commissioner. Treat 7 days as an outer limit: if people need to change passwords or call their bank, they need to know quickly.

The notice should explain, in plain language, what happened, the likely consequences, what you have done or will do, what they can do to protect themselves, and who to contact. Send it directly, by email, SMS, app message or letter, as a message of its own rather than a line in a newsletter. Use the language your customers or staff actually read; for most Malaysian audiences that means BM and English.

The guideline allows alternatives in limited cases. Where direct notice would need disproportionate effort, a public statement or similarly effective method can replace it. Where technical or organisational measures make harm unlikely, for example the data was strongly encrypted and the key was not exposed, the duty to tell individuals may not arise. Record the reasoning if you rely on either.

Building a breach response plan

The guideline expects controllers to have breach management and response plans, to train staff on them periodically, and to run simulation exercises. A workable plan covers:

1. Detect and report. One channel for staff to report a suspected breach, with the time of discovery logged.
2. Contain and preserve. Isolate affected systems, revoke access, recall emails, and keep logs and evidence. Deleting evidence “to be safe” makes the investigation impossible.
3. Assess. What data, how many people, how sensitive, and the significant-harm and 1,000-person tests.
4. Decide and notify. Who decides (the controller, advised by the DPO and legal), who files the Commissioner notice, who signs off individual notices.
5. Other notifications. Sector regulators, the police, insurers and, for national critical information infrastructure, the cyber security regime may have their own reporting rules. List them in the plan.
6. Recover and learn. Fix the cause, review the response, update the plan.

Name the people and their deputies. A plan that depends on one person who is on leave fails on day one. The Breach Notification lesson steps through this sequence with worked timings.

When a processor has the breach

The notification duty sits with the data controller, not the processor. But many breaches happen at vendors: a payroll bureau, a cloud host, a marketing agency. Your 72 hours can start when the processor tells you, so the contract has to make the processor tell you fast.

The guideline expects controllers to contractually require processors to notify them promptly of any breach and to give all reasonable and necessary assistance. Set a short notice period in the contract (24 hours, for example), name the contact points, and require cooperation with investigations. Since April 2025 processors are also directly bound by the PDPA Security Principle, so they carry their own exposure. See Processors, Contracts and Transfers.

Record keeping: the breach register

Keep a register of every personal data breach, including those you decided not to notify, for at least 2 years. The Commissioner can ask to see it.

For each breach, record at least: date and time of discovery and of the breach if known; how it was found; what happened; the data and number of people affected; the harm assessment and the reason for notifying or not; times of the Commissioner and individual notices and the confirmation reference; containment and remedial steps; and lessons learned.

Timestamps matter most. Without the time of awareness, nobody can prove the 72-hour and 7-day deadlines were met.

Practise before it happens

Most notification failures come from people who have never done it: they wait for complete facts, argue about who decides, or lose the evidence. The fix is rehearsal. The WorkQuest2U Breach Tabletop Drill plays a ransomware attack on HR files hour by hour, with legal, IT, communications and the board, in a 3D scene, so your team practises the 72-hour decision before a real incident. Pair it with Security, Retention and Disposal to reduce the breaches in the first place.