PDPA after the 2024 amendments: what a Malaysian SME actually has to do

This is a practical engineering and operations guide, written by an IT company. It is not legal advice, and it does not replace advice from a Malaysian lawyer on your specific circumstances. Where the two disagree, believe the lawyer.

If you would rather we did it

This guide is written so a competent person inside your company can do the work themselves, and plenty do. We also sell it: PDPA consultation and staff training — an on-site data inventory workshop producing the register and a ranked gap list, staff training in English, Malay or Mandarin, support for the Data Protection Officer you appoint, the impact assessments the April 2026 guidelines made mandatory, a rehearsed breach route, and the technical remediation to close what the inventory finds. The service page has what each engagement delivers, what it costs you in time, and the three things we decline to do.

What actually changed, and when

Malaysia's Personal Data Protection Act has been in force since 2010, and for most of that time the practical compliance level in the SME sector was somewhere between "a privacy notice on the website" and "nothing".

The Personal Data Protection (Amendment) Act 2024 changed the calculus. It did not arrive all at once, though, and the single date most articles quote is wrong for half of what they list. The Act commenced in three tranches:

In force	What started applying
1 Jan 2025	Administrative renaming inside the Act. Nothing an ordinary company does differently.
1 Apr 2025	“Data user” became “data controller”. Biometric data became sensitive personal data. “Personal data breach” got a definition. Deceased individuals stopped being data subjects. The RM1 million penalty. Processors brought under the Security Principle. The cross-border transfer rules rewritten.
1 Jun 2025	The Data Protection Officer duty, the breach notification duty, and the data portability right.

Six changes are worth knowing:

1. A Data Protection Officer must be appointed by qualifying controllers and processors, and the appointment registered with the Commissioner.
2. Data breaches must be notified to the Commissioner within 72 hours — but only where the breach causes or is likely to cause significant harm, which is a defined test and not a judgement call. Affected individuals are told directly where that harm is likely to reach them.
3. Data processors are now directly obliged under the Security Principle. Previously the obligation sat with the data user alone.
4. “Data user” became “data controller”, aligning the vocabulary with international practice — which matters mostly because every contract, policy and privacy notice you wrote before now uses the old term.
5. Biometric data became sensitive personal data by name, and is now defined in the Act as any personal data resulting from technical processing of a person's physical, physiological or behavioural characteristics. Face templates and fingerprints are in scope by statute rather than by argument.
6. A data portability right was introduced, and cross-border transfer guidance followed in April 2025.

The maximum penalty rose to a fine of up to RM1 million and/or up to three years' imprisonment, up from RM300,000 and two years. Read what it attaches to, because it is wider than most write-ups suggest: under section 5(2) it covers a data controller contravening any of the seven Personal Data Protection Principles — not only the Security Principle — and it separately reaches a data processor that contravenes the Security Principle. So a retention failure or a notice failure carries the same maximum as a breached database.

Then, on 30 April 2026, the Commissioner issued three more guidelines: on Data Protection Impact Assessments, on Data Protection by Design, and on Automated Decision-Making and Profiling. The first of those creates work for exactly the companies that already had to appoint a DPO, and almost nobody has noticed yet.

There is a second, separate penalty that gets less attention and is easier to incur. Under section 12B(3) of the Amendment Act, a data controller who fails to notify the Commissioner of a breach commits an offence carrying a fine of up to RM250,000 and/or up to two years' imprisonment. Read the section carefully, because the drafting matters: that penalty attaches to subsection (1), the duty to notify the Commissioner. The duty in subsection (2) to notify affected individuals is not covered by the same offence provision. Both duties are real; only one of them is what 12B(3) punishes.

The fines are the headline. The operational risk is a breach becoming public because you missed a notification deadline you did not know existed.

The DPO, and who it should be

First, whether you need one at all. The Commissioner's guideline sets three thresholds, and appointment is mandatory if you cross any of them:

• personal data of more than 20,000 data subjects;
• sensitive personal data, including financial information, of more than 10,000 data subjects;
• processing that requires regular and systematic monitoring.

The first two are a headcount question and a good many SMEs are comfortably under both. The third is the one that catches people, because it is not about volume: CCTV, vehicle or staff tracking and behavioural profiling can put a thirty-person company in scope on their own. The guideline names its own examples — a retail site whose algorithm watches searches and purchases to make recommendations, wearables collecting fitness data, telecommunications networks, connected cars and home automation. It also says a loyalty programme run purely to manage accounts, rather than to study buying behaviour, probably is not caught. Work out which limb applies to you before buying anything, and be suspicious of anyone who tells you the obligation is universal — it is not.

Also note who this applies to. Section 12A(2) puts the same appointment duty on a data processor, so a company that only ever handles other people's data can be in scope on its own account.

If you conclude you are below all three, write down why. The guideline invites you to keep a record of the reasons for not appointing, and that record is the entire difference between a considered decision and an omission you have to reconstruct under questioning two years later. It is half a page. Do it on the day you decide.

If you are in scope, the appointment is registered through the Commissioner's system at daftar.pdp.gov.my within 21 days, and any later change of officer or contact details within 14 days. Four mechanics that are easy to miss:

• A dedicated business email address for the DPO, separate from that person's normal work address, monitored at all times. Not a personal mailbox with a forwarding rule.
• Published contact details — on the website and your other official channels, in the privacy notice, and in your security policies. Three places, not one.
• An interim officer to watch that mailbox the moment the DPO leaves, before a replacement is appointed.
• Protection from dismissal for performing the role in good faith, and direct reporting access to senior management. A DPO who reports to the person whose project they have to question is not independent, and the guideline says so.

Where the officer is external, the guideline recommends a contract term of at least two years for stability, with the duties described clearly and a named lead contact on the provider's side.

Appointing one does not move your liability, either: the organisation remains responsible for compliance, and the DPO is not personally on the hook for the company's failures.

Then two misconceptions do most of the remaining damage.

“We need to hire someone.” Usually not. The DPO can be an existing employee, provided they have the authority to act and the time to do it. What they cannot be is someone with an unmanaged conflict — the person who owns the marketing database should not be the person who decides whether the marketing database is compliant.

“It has to be the IT manager.” Often the worst available choice. Most PDPA exposure is not technical. It is a signed consent form that does not cover what you are doing with the data, a retention period nobody set, a WhatsApp group where identity-card photographs get forwarded. That is an operations and process problem. The IT manager should advise the DPO, not be them.

Our recommendation for a typical SME is that the DPO sits in operations, finance or HR with genuine executive backing, and that the technical controls are supplied by IT and documented by the DPO. The appointment goes to the Commissioner, the name goes in the privacy notice, and the person gets a defined and protected block of time — because a DPO with no calendar time is a name on a form.

The 72-hour clock

The failure mode is not malice. It is that the clock starts before anyone realises there is a clock.

A staff member emails a customer list to the wrong recipient on a Friday afternoon. They notice on Monday and mention it to their supervisor on Tuesday. By the time anyone senior hears the word "breach", the 72 hours are gone and the first thing the Commissioner learns about your company is that you were late.

That reading is the safe one, and it is the guideline's own rule: notification is due no later than 72 hours from the occurrence of the breach. Confusingly, every worked example in the same guideline computes the clock from the moment the company was told, detected the incident or confirmed it — the lost USB key from when the loss is reported, the compromised network from when the inspection confirms it. The notification form asks the same way. So the drafting points two directions. Plan against occurrence, because the gap between the two readings is precisely the weekend nobody noticed.

Not every breach is notifiable

This is the half most write-ups leave out, and it cuts both ways — it saves you notifications you do not owe, and it removes the excuse for the ones you do. The guideline's own words: not all personal data breaches are notifiable to the Commissioner. You notify only where the breach causes or is likely to cause significant harm, which is defined rather than left to judgement. Any one of these is enough:

• the data may cause physical harm, financial loss, a negative effect on credit records, or damage to or loss of property;
• it may be misused for illegal purposes;
• it consists of sensitive personal data — health, biometrics, religion, political opinions, offences;
• combined with other information it could enable identity fraud; or
• it is of significant scale, which the guideline defines as more than 1,000 affected data subjects.

Work the examples and the shape becomes clear. Medical records reached by an outsider is notifiable at any number, because sensitive data is its own limb. An account statement emailed to the wrong customer is notifiable, because it is financial information. The email addresses of 200 employees on a stolen encrypted laptop is not. Encryption that genuinely renders the data meaningless can also remove the duty to tell the individuals — while still leaving the duty to tell the Commissioner.

One trap in the arithmetic: the same test governs telling the affected individuals, except that the 1,000 limb does not apply there. A breach can be notifiable to the Commissioner purely on scale and still not require you to contact anybody.

Getting the first 72 hours right

Three things prevent the failure above, and none of them is expensive:

• A named internal route. One email address or one person, published internally, where "I think I did something bad with data" goes. Not the helpdesk queue. Not a form.
• A no-blame rule that is genuinely honoured. The rate-limiting factor on breach response is a junior employee's willingness to admit a mistake within hours. Punish the first one publicly and you will not hear about the second.
• A pre-written notification. A template with the facts the Commissioner expects, drafted while calm, so the first 72 hours are spent investigating rather than composing.

Notify with what you know. An initial notification followed by an update is the expected shape; silence while you assemble a complete picture is not. Anything you could not establish in time may follow in phases, within 30 days of the first notification. Where the breach is likely to cause significant harm, the affected individuals must be told within 7 days of your notifying the Commissioner — so the 72 hours buys you an investigation window, not a decision window.

Four mechanics that decide whether a well-intentioned response actually lands:

• Your notification does not count until it is acknowledged. The Commissioner issues a confirmation notice on receipt, and the guideline says the notification "will not be considered submitted" without it. A form sent at hour 71 and never confirmed is not a notification.
• Three ways to file: the form on the Department's site, the Annex B form emailed to dbnpdp@pdp.gov.my, or hard copy. Know which one you will use before you need it.
• Being late now has an evidence burden. Miss the 72 hours and you must submit a written notice explaining the delay, supported by the incident timeline, internal communications and any technical or external factors. Improvised afterwards, that document is a confession; assembled as you go, it is a defence.
• Somebody must be the contact point. Where a DPO is mandatory, the DPO takes it. Where one is not, the guideline still expects you to designate a named representative senior enough to answer for the company.

Two duties run alongside and are easy to forget in the moment. The Commissioner is not the only regulator with a clock: criminal activity goes to the police, regulated sectors have their own notifications to Bank Negara, the Securities Commission or the MCMC, and an organisation designated as National Critical Information Infrastructure notifies NACSA under the Cyber Security Act 2024. And separately, the Commissioner expects a written breach management and response plan — identification and escalation, named roles, containment, the decision on whether to notify, the communications plan, and a post-incident review — kept current with periodic training and simulation exercises. The tabletop drill is not a nice-to-have someone invented; it is in the guideline.

The impact assessment nobody has heard of yet

On 30 April 2026 the Commissioner issued three guidelines at once: on Data Protection Impact Assessments, on Data Protection by Design, and on Automated Decision-Making and Profiling. They arrived quietly, most published commentary predates them, and the first of the three creates real work.

A DPIA is a written assessment of what a planned use of personal data could do to the people in it, carried out before you start. It is not a document about your company; it is a document about them.

The test runs in two tiers. First the numbers, and if you cross either one a DPIA is mandatory:

• processing expected to involve more than 20,000 data subjects; or
• sensitive personal data, including financial information, of more than 10,000 data subjects.

Those are the same two figures that make a DPO mandatory, which is the practical headline: if you needed a DPO, you now need impact assessments too. The two obligations arrive on the same companies, a year apart, and nobody sent a reminder.

Below the numbers, your DPO has to judge it against qualitative factors — the guideline's list is explicitly not exhaustive, but includes a significant effect on someone's legal status, finances, health, reputation or access to services; systematic monitoring such as facial recognition or geolocation; innovative technology including AI; restrictions on data subject rights; children's or vulnerable persons' data; and high-risk automated decisions.

And one trigger overrides the arithmetic entirely. Automated decision-making or profiling requires a DPIA regardless of scale — the guideline says "regardless of the nature or extent of its intended use". A recommendation engine on a small e-commerce site is in scope. So is an algorithm that screens job applicants. So is anything where a model, rather than a person, decides something about somebody.

What that means in practice for a smaller company:

• Senior management owns it. Not the DPO, not IT. The DPO advises, identifies when one is needed and builds the template; the ultimate responsibility for the assessment and for what is decided afterwards sits with management. Where the residual risk comes out High, it is reported to them by name.
• It has a shelf life. A completed DPIA is valid for two years, then must be redone — and monitored in between, whenever the purpose changes or a new vulnerability turns up in the technology.
• The paperwork outlives the project. Records are kept for at least two years after the processing stops. The guideline's own example: a five-year processing operation means about seven years of retention.
• Your processors have to help. The duty is the controller's, but the processor is expected to give reasonable assistance, and the controller is told to put that in the contract.

The other two guidelines are lighter. Data Protection by Design is voluntary best practice, organised as a checklist against each of the seven principles — build the protection into the system at the start rather than bolting a policy on at the end, which is an argument this guide has been making since well before the Commissioner made it official.

Automated Decision-Making and Profiling is where anyone deploying AI should look. It requires nothing exotic, but it does require that your privacy notice says automated decisions are being made, what kinds, why and with what consequences; that a mechanism to withdraw consent exists and is described; that sensitive personal data in an automated process has explicit consent behind it; that the people involved are trained; and that AI is never the sole factor in a decision about a person — a competent human reviewer stays in the loop.

One thing to be careful about, because a good deal of published commentary gets it wrong: Malaysia has not granted a right to refuse automated decisions or a right to demand human review. Those appeared in the 2025 public consultation and are not in the final guideline, which rests on the existing Notice and Choice Principle and the existing right to withdraw consent. Do not build a process around a right that was not enacted, and treat any summary that claims otherwise as written from the draft.

If you process data for someone else

This is the change most likely to catch a Malaysian services business by surprise.

If you hold or handle personal data on behalf of a client — a payroll bureau, a marketing agency with their customer list, a logistics provider with consignee details, an IT firm with a copy of the production database — you are a data processor, and the Security Principle now applies to you directly. Not through your client's contract. To you.

Which means: appropriate technical and organisational measures, documented; a defined retention and deletion practice, actually performed; a Data Protection Officer of your own if you cross the thresholds, because section 12A(2) puts that duty on processors in their own right; and a route by which your client learns about a breach in time to meet their 72 hours, which is materially shorter than yours.

Be precise about which obligations reach you, though, because the two halves are often run together. The Security Principle applies to a processor directly, by statute — that is the change, and the RM1 million maximum comes with it. The breach notification duty in section 12B does not. The guideline says so plainly: mandatory notification "does not directly apply to data processor". Instead the controller is required to impose it on you by contract, along with an obligation to give them all reasonable assistance in meeting their own deadline. So your exposure on breach reporting is commercial rather than criminal — which is not the same as small, because it is the clause your client will read out when they are late and looking for the reason.

We hold that obligation ourselves, on every zynAIR tenant we operate. It is a large part of why database copies for development are sanitised as a matter of course rather than on request.

Sending data out of Malaysia

Almost every company sends personal data abroad, usually without framing it that way. Google Workspace or Microsoft 365. A CRM hosted in Singapore. A marketing platform in the United States. An AI assistant whose model runs in someone else's data centre.

The rules here were rewritten on 1 April 2025 and explained by the Commissioner's Cross Border Personal Data Transfer Guidelines on 29 April 2025. Two structural changes matter.

First, the whitelist is gone. There used to be a mechanism for the Minister to name approved destination countries. It was deleted, and in its place the data controller itself decides whether a destination has a law substantially similar to the PDPA, or otherwise gives protection at least equivalent to it. That decision is made through a Transfer Impact Assessment, and the assessment is valid for three years before it must be redone.

Second, the alternative routes were trimmed. The old "necessary in the public interest as determined by the Minister" limb was removed. What survives, and what most SMEs will actually rely on, is the due-diligence route: you may transfer where you have taken all reasonable precautions and exercised all due diligence to ensure the data will not be handled abroad in a way that would breach the Act here. In practice that means contractual protection clauses, binding corporate rules within a group, or a recognised certification — plus the ordinary alternatives of explicit consent, contractual necessity and legal proceedings.

You are also expected to keep records of your transfers and of who receives the data.

The practical first step is duller than any of the legal analysis: most companies cannot list where their personal data currently goes. Until that list exists there is nothing to assess.

Where a transfer turns out to be difficult to justify — or simply undesirable — there are two ordinary engineering answers, and we build both: storage that stays in your building, and AI models that run on your own hardware. Neither is a compliance product. Both remove a transfer from the list, which is better than documenting one.

The obligation that comes before all of them

Everything above assumes you are lawfully processing personal data in the first place. For some companies that assumption needs checking, and it has been true since 2013 rather than since 2024 — which is exactly why it gets missed.

Malaysia requires data controllers in specified sectors to hold a Certificate of Registration from the Commissioner, and to renew it. The classes are sectoral, not size-based: communications; banking and financial institutions; insurance; health; tourism and hospitality; transportation; education; direct selling; services, meaning legal, audit, accountancy, engineering and architecture practices; real estate; and utilities, pawnbrokers and moneylenders.

Two things follow. Continuing to process personal data after a certificate has expired is an offence in itself, separate from anything else in this guide. And an IT or software company is generally not in a listed class — but a good many of its clients are. A school is in education. A clinic is in health. A logistics firm is in transportation. An engineering consultancy is in services.

Whether a particular company falls inside a class is a question of construction, and it is a lawyer's answer rather than ours. What a data inventory can do is surface the question, early, while it is cheap. We name it and hand it over; we do not decide it.

The one artefact that makes all of it tractable

If a company does exactly one thing after reading this, it should be a data inventory. Every other obligation is downstream of it.

One row per collection of personal data, with seven columns:

Column	The question it answers
What	Which data — name, IC number, address, photograph, payroll, health
Whose	Customers, employees, applicants, suppliers, visitors
Why	The purpose it was collected for, in one sentence
Where	The system it lives in, and the country that system sits in
Who	Who inside the company can reach it, and which third parties receive it
How long	The retention period — and “forever” is an answer that needs defending
Basis	Consent, contract, or another lawful basis

Building it takes a competent person two to five days in a typical SME, and it is uncomfortable — every inventory turns up a spreadsheet on somebody's laptop, a WhatsApp group with scanned identity cards in it, and a former employee's account that still has access.

That discomfort is the deliverable. You cannot secure, notify about, delete or justify data you have not written down.

And a second register, for breaches

The inventory is the one everybody eventually hears about. This one is required by the breach guideline and almost nobody keeps it: a register of personal data breaches, retained for at least two years from the date of notification.

The detail that makes it worth building properly is what has to go in it. Not only the breaches you reported — "including those that did not meet the notification criteria". Every incident, recorded with the date and time you became aware, the root-cause analysis, the data types, the estimated number of people and records, the system that allowed it, the likely consequences, the chronology, what you did to contain it, and — the important column — the justification for not notifying, where you did not.

Read that alongside the significant-harm test above and the design becomes obvious. The law lets you decide that a breach was not notifiable. This register is where you prove the decision was made deliberately, on the day, against the criteria, rather than reconstructed under questioning eighteen months later. The Commissioner can ask for it at any time.

Training, and why the reception desk matters most

Breaches in small companies are overwhelmingly ordinary: the wrong attachment, the reused password, the visitor book with a photocopy of every visitor's identity card, the WhatsApp forward.

So the training that pays is not a legal seminar for managers. It is one short, focused session for the people who actually touch personal data all day — reception, HR, sales, delivery, customer service — covering four things:

1. What counts as personal data here, using this company's own examples.
2. What you may and may not do with it, in the four situations that come up weekly.
3. Who to tell, immediately, when something goes wrong — by name.
4. Why nobody is in trouble for reporting it in the first hour.

We deliver that session in English, Malay or Mandarin, on site, using the company's own systems as the worked examples. A generic slide deck about the GDPR does not change behaviour at a reception desk in Batu Pahat.

Training the appointed officer is a separate question, and the Commissioner has since said more about it. Guidelines issued in July 2025 set out what a DPO is expected to know, across six competency areas and two tiers — a Fundamental tier every DPO should meet, and an Advanced tier that is explicitly not required of everyone. The useful part for a smaller company is how the Fundamental tier may be satisfied: through the officer's own expertise, through an internal team, or by engaging outside experts for specific areas — provided the appointed DPO keeps oversight of all six. That is the arrangement most Malaysian SMEs can actually staff, and it is now the Commissioner's own description rather than a workaround.

A related guideline sets standards for organisations that train DPOs, and sketches a framework under which the Commissioner may formally recognise providers — applications, assessment, audits, fees, revocation. It is prospective: no such recognition is being granted yet. Treat anyone claiming an officially recognised PDPA certification today with the scepticism that deserves.

What we do

The engagements are described in full on the PDPA consultation and training page:

• Data inventory workshop. On site, producing the register above and a written gap list — and flagging whether you sit in a registrable class.
• DPO support. Helping the appointed person do the job — templates, the registration, the review cadence — rather than doing it for them, which does not survive our leaving. Where you are below the thresholds, the deliverable is the written record of why.
• Impact assessments. The DPIA the April 2026 guideline made mandatory above the same thresholds, using the Commissioner's own method, with the residual-risk report management has to sign and a diary date two years out.
• Breach response readiness. The internal route, the pre-written notification, the two-year breach register, and a tabletop exercise so the first time is not the real time.
• Technical remediation. Access control, retention and deletion actually implemented in the systems, including inside Odoo.
• Cross-border transfer review. Where the data goes, then a Transfer Impact Assessment against each destination, good for three years.
• Staff training. On site, in the language the team works in.

Where the question is legal rather than operational, we will say so and stop. See what each engagement delivers, or start with the inventory.

One last reason not to treat any of this as a project with an end. In August 2025 the Commissioner put out a consultation paper proposing amendments to the Personal Data Protection Regulations 2013: consent obtained before processing rather than alongside it, specific safeguards for minors, mandatory contracts between controllers and processors, compulsory breach management, and inspection powers extended to processors. Those are proposals — not gazetted, and not law as this is written. But the direction is unmistakable, and a register written once and filed is wrong within months anyway.

Questions