Despite the frequency of data breaches, many Malaysian business owners remain unclear on a basic question:
What legally counts as a data breach, and what if it happens to my business?
This guide explains what a data breach is under Malaysia’s Personal Data Protection Act 2010 (PDPA), what the law requires businesses to do when one occurs, penalties involved, and how a data breach response policy can reduce your exposure proactively.
What is a data breach under Malaysian law?
A personal data breach is any event that leads or is likely to lead to the breach, loss, misuse, or unauthorised access of personal data. This was formally introduced into the PDPA framework through the 2024 amendments to the Act, which made data breach notification a mandatory legal obligation in Malaysia.
Common examples of data breaches include:
- a hacker gaining unauthorised access to a customer database,
- an employee accidentally emailing a spreadsheet of customer data to the wrong recipient,
- a lost or stolen company laptop containing unencrypted personal data,
- a misconfigured cloud storage bucket that exposes personal data publicly, and
- a ransomware attack that encrypts or exfiltrates personal data held by the business.
The common thread is that personal data ends up somewhere it should not be, or in the hands of someone who should not have access to it, whether due to malicious intent, negligence, or a technical failure.
Example: Ransomware as a data breach
Let’s use ransomware as an example – a typical attack works like this:
- An employee clicks a malicious link or attachment
- Malware spreads through the company’s network
- The attacker either encrypts business files (demanding payment for the decryption key) or exfiltrates (copies out) sensitive data before encrypting it, then
- Threatens to leak that data publicly unless a ransom is paid
From a PDPA perspective, if that encrypted or exfiltrated data includes personal data, this is a personal data breach, regardless of whether the business ultimately pays the ransom, and regardless of whether the attacker’s identity or motive is ever confirmed.
Paying a ransom does not undo the breach or remove the notification obligation. Businesses are sometimes under the mistaken impression that if they recover their data (by paying, or by restoring from backup), there is nothing left to report.
Legally, the breach already occurred the moment the data was accessed or exfiltrated without authorisation.
The PDPA Security Principle – data breach link
Data breaches are frequently the direct result of inadequate security measures, which is precisely what the PDPA’s Security Principle (Section 9) is meant to prevent.
The Security Principle requires a data controller to take practical steps to protect personal data from loss, misuse, modification unauthorised access, or destruction, having regard to the nature of the data, where it is stored, what security measures are built into the storage systems, and the reliability of personnel with access to it.
In practice, this means a breach caused by weak security is often not a single, isolated offence. A business that suffers a breach because it never enforced multi-factor authentication, never patched known software vulnerabilities, or gave broad data access to staff who did not need it, may find itself facing two separate exposures: the breach notification obligation itself, and a separate potential finding that it breached the Security Principle by failing to have adequate safeguards in the first place.
This is why data breach preparedness and data security cannot be treated as separate projects. A data breach response policy tells you what to do after something goes wrong. Proper data security practices, such as access controls, encryption, regular patching, and staff awareness training, are what reduce the chance of the breach happening at all and reduce the regulatory exposure even if one does occur.
Who is legally responsible?
Under the PDPA, a data controller (the organisation that determines how and why personal data is processed) is responsible for notifying the Personal Data Protection Commissioner (PDPC) and, in certain circumstances, the affected individuals.
This responsibility exists regardless of whether the breach was caused by the organisation itself, a third-party vendor, or an external attacker.
If your business collected the personal data and a vendor you engaged (such as a cloud provider or payroll processor) suffers a breach, you as the data controller are still responsible for notification. This is one reason a properly drafted contract (such as the Data Processing Agreement) with vendors matters.
Data controller responsibilities
If the breach causes or is likely to cause significant harm to data subjects, the data controller must notify the PDPC as soon as practicable, and in any event within 72 hours of becoming aware of the breach. If notification is delayed, a written explanation must be submitted along with supporting evidence for the delay.
Depending on the severity and nature of the breach, affected individuals will need to be notified within 7 days from notifying the PDPC.
What counts as “significant harm” is assessed on a case-by-case basis but generally includes financial loss, identity theft risk, significant scale, or physical harm to the affected individuals.
For the detailed step-by-step notification process, including what information must be included and how to submit it to the PDPC, see ELP’s step-by-step guide to handling data breach notifications.
Penalties for non-compliance
Non-compliance carries two distinct tiers of penalty, depending on what exactly went wrong:
- Failure to notify the PDPC of a data breach. A data controller who fails to comply with the mandatory breach notification requirement faces a fine of up to RM250,000 and/or imprisonment of up to 2 years. This penalty attaches specifically to the failure to report.
- Breaching the Personal Data Protection Principles more broadly. This includes the Security Principle discussed above. A breach of any of the 7 principles carries a fine of up to RM1 million and/or imprisonment of up to 3 years.
These two penalty tiers may apply together. A business that suffered a breach due to poor security and then also failed to report it in time could face exposure under both provisions.
Beyond the statutory fines, a breach also typically brings:
- regulatory investigation and enforcement action by the PDPC, and
- reputational damage that can be more costly than the fine itself.
A full breakdown of PDPA penalties across different categories of offences is available in ELP’s PDPA penalty guide.
How to reduce exposure before a breach
The most effective protection against the legal and financial consequences of a data breach is having a data breach response policy in place before you ever need it.
A properly drafted policy works alongside a broader PDPA compliance framework and typically covers:
- how to detect and classify a suspected breach internally
- who within the organisation is responsible for managing the response
- the internal escalation and decision-making process for whether the breach meets the notification threshold
- template notification letters for the PDPC and affected individuals, and
- a post-incident review process to prevent recurrence
Employee training
A policy on paper should be paired with actual staff training, since most breaches start with a single employee clicking the wrong link.
Training should ideally cover how to recognise phishing attempts, what to do (and not do) with suspicious emails, and who to alert immediately if something looks wrong.
Simulated phishing exercise
A common and effective way to test whether that training has actually sunk in is a simulated phishing exercise, where the business (or a third-party security vendor) sends staff a deliberately fake, harmless phishing email to see who clicks it. This is a widely used industry practice precisely because it tests real behaviour rather than just confirming that staff sat through a training session.
What to do following a data breach
The moment a breach is discovered tends to be stressful, and establishing a few practical steps beforehand makes a real difference in how well the situation is managed.
Do not try to hide it
The instinct to quietly contain the problem and hope it goes away is understandable, but it is also the single most damaging response available. A delayed or concealed breach that later comes to light, whether through a regulator, media, or an affected customer, is treated far more seriously than a breach that was promptly reported and properly handled. Concealment can itself constitute a separate compliance failure on top of the original breach.
Report internally immediately
Whoever discovers or suspects a breach, whether an employee, an IT contractor, or a customer complaint, should know exactly who to alert without delay. If the business has an appointed Data Protection Officer, that is the first point of contact.
If there is no DPO, the report should go to whoever is designated to handle it internally, typically an IT manager, legal or compliance manager, or a member of senior management.
Form an investigation team quickly
Depending on the size of the business, this might be a small cross-functional group covering IT (to contain and assess the technical scope), legal or compliance (to assess notification obligations and manage regulatory exposure), and a decision-maker with authority to act.
The team’s first job is to understand what happened, what data was affected, and how many people are impacted, since this determines whether the 72-hour PDPC notification clock has started.
Contain before investigating the full picture
Immediate containment (isolating affected systems, resetting compromised credentials, taking a compromised system offline) should happen before a full root-cause investigation, to stop the damage from growing while the details are still being worked out.
Document everything as you go
Timelines, decisions made, and who was informed when. This record is needed for the PDPC notification itself, and it also becomes important evidence of good faith if the response is ever scrutinised later.
None of this needs to be perfect. What regulators generally look for is whether the business acted promptly, honestly, and in good faith, not whether it handled a crisis flawlessly. A business that reports a breach quickly and transparently is in a materially better position than one that tries to manage the problem quietly and gets found out later.
Let ELP support your PDPA compliance
We help Malaysian businesses draft data breach response policies, and where a client is managing an active breach, work alongside their IT, legal and communications teams to manage the legal and regulatory side of the response. If you want to put a data breach response policy in place before you need one, book a consultation with us.
