PDPA Malaysia for Developers: What to Actually Build

PDPA Malaysia for Developers: What to Actually Build

This is technical guidance for builders, not legal advice. The legal framework is the Personal Data Protection Act 2010 (Act 709), as amended by the Personal Data Protection (Amendment) Act 2024, together with the Commissioner's regulations, circulars, guidelines, and applicable codes of practice. When in doubt, ask a qualified Malaysian lawyer. This article tells you what to build and what engineering questions to ask; it does not determine whether your organisation is legally compliant.

For years, Malaysia's PDPA was background noise for many developers: a consent checkbox, a privacy notice nobody read, and privacy controls that were often treated as documentation rather than engineering.

That is no longer a safe assumption.

The Personal Data Protection (Amendment) Act 2024 introduced significant changes that came into force in stages during 2025. Among them are mandatory data breach notification for qualifying breaches, conditional Data Protection Officer (DPO) appointments, direct security obligations for data processors, a new right to data portability, stronger cross-border transfer requirements, expanded sensitive personal data to include biometric data, and increased penalties for certain offences. Source: Personal Data Protection (Amendment) Act 2024, Act A1727

The important point for developers is not the legal vocabulary. It is the architecture underneath it.

If your application stores names, email addresses, phone numbers, identity numbers, locations, photographs, device identifiers, KYC documents, support conversations, or other information that can identify a person, privacy is already an engineering concern.

This article translates the amended PDPA framework into practical engineering work: what to inventory, what to log, what to retain, what to delete, how to structure access, how to evaluate vendors, how to handle overseas infrastructure, and how to prepare for a notifiable data breach.

The failure modes are Malaysian and concrete — leaked customer schemas with location and KYC data, RM28.67M lost to QR scams, and usernames becoming identity.

The 60-second mental model

The PDPA regulates the processing of personal data in connection with commercial transactions. The Act applies to persons who process, or have control over or authorise the processing of, personal data in connection with commercial transactions, subject to its scope and exclusions. It generally does not apply to the Federal Government or State Governments.

Source: Personal Data Protection Act 2010 — Application and Non-Application of the Act

If your application handles names, emails, phone numbers, IC numbers, locations, photos, device IDs, account identifiers, or other information that can identify an individual, you should start by asking:

1. What personal data do we hold?
2. Why are we processing it?
3. Where is it stored?
4. Who can access it?
5. Who receives it?
6. How long do we retain it?
7. What happens when someone asks for access or correction?
8. What happens if the data is breached?
9. Does any data leave Malaysia?
10. Which vendors and processors can access it?

Seven Personal Data Protection Principles remain the basic structure:

1. General Principle — processing must comply with the requirements of the Act, including the consent requirement and applicable statutory exceptions.
2. Notice and Choice — provide the required notice about what is collected, why it is processed, and other prescribed information.
3. Disclosure Principle — do not disclose personal data outside the permitted purposes and circumstances.
4. Security Principle — take practical steps to protect personal data against loss, misuse, modification, unauthorised or accidental access, disclosure, alteration, or destruction.
5. Retention Principle — do not retain personal data longer than necessary for the purpose for which it was processed.
6. Data Integrity Principle — take reasonable steps to ensure personal data is accurate, complete, not misleading, and up to date.
7. Access Principle — provide the applicable rights of access and correction.

Source: Personal Data Protection Act 2010 (Act 709)

The amendments do not turn the PDPA into GDPR. Developers should resist importing GDPR concepts wholesale into a Malaysian implementation.

Everything below is those principles translated into engineering work.

What changed in 2024–2025 — and why developers care

1. Data breach notification became mandatory for qualifying breaches

The amended PDPA introduced a statutory data breach notification framework.

The important qualifier is qualifying breach.

Not every personal data breach is automatically notifiable to the Commissioner. The Commissioner's Data Breach Notification Guideline (DBN) states that a data controller is required to notify the Commissioner when a personal data breach causes or is likely to cause significant harm.

The guideline identifies significant harm where compromised personal data may:

• result in physical harm, financial loss, negative effects on credit records, or damage to or loss of property;
• be misused for illegal purposes;
• consist of sensitive personal data;
• consist of personal data combined with other information that could potentially enable identity fraud; or
• be of significant scale.

A personal data breach is considered to be of significant scale when the number of affected data subjects exceeds 1,000.

That 1,000 figure is therefore a criterion for assessing significant scale. It is not a safe harbour saying that a breach affecting 999 people can simply be ignored.

Source: Personal Data Protection Guidelines on Data Breach Notification (DBN), sections 5.1–5.3

For a breach that meets the notification criteria, the data controller must notify the Commissioner as soon as practicable and no later than 72 hours, in accordance with the DBN notification process.

The DBN Guideline explains that the 72-hour period is calculated from the relevant point at which the data controller becomes aware of the personal data breach, with the guideline providing examples for determining when the period starts.

Source: DBN Guideline, section 6

Where notification to affected data subjects is required, the notification should be made without unnecessary delay and in accordance with the DBN requirements.

Your incident-response system therefore needs more than a Slack channel called #security.

It needs:

• detection;
• incident creation;
• timestamped awareness;
• evidence preservation;
• scope assessment;
• data classification;
• affected-subject estimation;
• notification decision-making;
• notification workflow;
• and an auditable decision trail.

2. DPO appointment is mandatory only in specified circumstances

This is one of the easiest areas to get wrong.

The amended PDPA introduced the requirement to appoint a Data Protection Officer (DPO), but it is not a blanket requirement for every organisation.

A data controller or data processor must appoint one or more DPOs where personal data processing involves any of the following:

• personal data of more than 20,000 data subjects;
• sensitive personal data, including financial information, of more than 10,000 data subjects; or
• activities requiring regular and systematic monitoring, such as online user behaviour tracking.

Source: Personal Data Protection Commissioner FAQ — DPO requirements

The DPO requirement took effect on 1 June 2025.

Source: P.U. (B) 522 — Appointment of Date of Coming Into Operation

The Commissioner's Guideline on the Appointment of Data Protection Officer was issued on 25 February 2025.

Source: DPO Guideline, Version 1.0

Where the DPO requirement applies, the DPO must be appointed and registered in accordance with the applicable requirements.

Source: JPDP DPO registration system

The DPO is not necessarily a new employee.

For a smaller engineering organisation that actually falls within the DPO criteria, an existing qualified person may take the role alongside other responsibilities if the arrangement satisfies the applicable requirements and does not create a conflict of interest.

The important engineering question is therefore not:

"Do we have a DPO because PDPA says everyone needs one?"

It is:

"Do our processing activities trigger the DPO requirement, and if so, have we built the organisational and technical support that allows the DPO to function?"

3. Data processors now have direct security obligations

This is a major change for SaaS companies.

The amended framework introduced a direct obligation for data processors to comply with the Security Principle.

Source: Personal Data Protection (Amendment) Act 2024, Act A1727

If you operate:

• SaaS infrastructure;
• managed databases;
• cloud applications;
• analytics platforms;
• CRM platforms;
• outsourced processing;
• or another service that processes personal data on behalf of a data controller,

you cannot treat privacy security as entirely the customer's problem.

Your engineering controls matter.

That means:

• authentication;
• authorisation;
• logging;
• secrets management;
• vulnerability management;
• access reviews;
• backup security;
• incident response;
• employee offboarding;
• and vendor/sub-processor management

all become part of the privacy risk picture.

4. Cross-border transfers require an actual assessment

The amended framework strengthened section 129 requirements for transferring personal data outside Malaysia.

A cross-border transfer can be permitted under specified statutory conditions, including circumstances involving:

• a destination with laws substantially similar to the PDPA;
• a destination that provides an adequate level of protection;
• consent;
• contractual necessity in specified circumstances;
• legal proceedings or legal rights;
• reasonable precautions and due diligence;
• or protection of vital interests.

The Commissioner's Cross-Border Personal Data Transfer Guideline (CBPDT) provides guidance on the conditions under section 129 and on assessing cross-border transfers.

Source: Cross-Border Personal Data Transfer Guideline

Therefore:

"Our database is in Singapore."

or:

"Our SaaS vendor is hosted in the US."

is not a complete compliance analysis.

It is an architecture fact that should trigger a transfer assessment.

For overseas infrastructure, document:

• destination country;
• actual processing location;
• sub-processors;
• purpose of the transfer;
• applicable transfer condition;
• security controls;
• contractual protections;
• and the reasoning behind the decision.

Where appropriate, perform and document a Transfer Impact Assessment.

A cloud-region selector is therefore not merely an infrastructure setting.

It can become a privacy architecture decision.

5. Sensitive personal data expanded to include biometric data

The amended framework expanded the definition of sensitive personal data to include biometric data.

Source: Personal Data Protection (Amendment) Act 2024, Act A1727

That matters for systems involving:

• fingerprints;
• facial recognition;
• biometric authentication;
• voice characteristics;
• retinal or similar biometric processing;
• and other biometric characteristics.

A Face ID-style authentication system is therefore not just another login table.

Treat the underlying biometric information as high-risk data and minimise what you store.

Where possible, prefer platform-provided authentication mechanisms that allow the application to receive a verification result or credential rather than storing raw biometric material itself.

6. Data portability is now a statutory right

The amended Act introduces a right to data portability under section 43A.

A data subject may request that a data controller transmit their personal data directly to another data controller of their choice by electronic means.

The right is subject to:

• technical feasibility; and
• compatibility of the data format.

Source: Personal Data Protection (Amendment) Act 2024, section 43A

For developers, this means data portability should be considered at architecture time rather than treated as an impossible export request after five years of schema drift.

If your system may need to support portability, think about:

• canonical data models;
• machine-readable exports;
• identity verification;
• request authentication;
• audit trails;
• destination-controller details;
• field-level mapping;
• and safe transmission mechanisms.

Do not confuse data portability with a generic "export everything" button.

Personal data inventory: know what you hold

You cannot protect what you cannot list.

Maintain a living data map — a table, not a feeling:

The Misi Rakyat leak analysis is what an unmapped estate looks like from the outside: customer schemas, rider KYC, vendor records, and a .env file — each a row nobody owned.

Build the table before someone else builds it for you.

For every field, be able to answer:

Why does this field exist?

If nobody can answer, question whether it should exist at all.

Logging without building a liability

Logs are useful evidence and can also become a concentrated personal-data store.

Apply privacy engineering at the logging layer:

• Minimize at write time. Do not log request bodies containing personal data by default. Log identifiers and event metadata instead of raw content.
• Scrub structurally. Redact IC numbers, phone numbers, emails, tokens, cookies, and authorization headers in the logging pipeline rather than relying on developers to remember.
• Use short retention where practical. Debug logs should not live forever. Choose a retention period based on operational, security, and legal requirements.
• Access-control the logs. Log aggregators often contain highly concentrated information and should receive production-grade access controls.
• Separate security evidence from application noise. Authentication events, privilege changes, administrative actions, and suspicious activity deserve stronger retention and access controls than ordinary debug output.

A useful rule:

If a production database needs MFA and access control, your central log platform probably does too.

Databases, backups, and retention that actually deletes

Retention failures usually appear in several places:

• soft deletes that never become real deletion;
• replicas that retain old records;
• backups that contain deleted data indefinitely;
• analytics tables nobody expires;
• object storage without lifecycle policies;
• and logs that silently become permanent archives.

Build actual deletion workflows.

For application data:

• implement explicit deletion paths;
• test deletion against replicas;
• define how backups handle expired data;
• configure object-storage lifecycle policies;
• expire analytics and event data;
• remove stale exports;
• and document exceptions where data must be retained for another legal or operational reason.

Do not describe 90 days as a PDPA-mandated retention period.

A 90-day period may be a reasonable engineering policy for a particular analytics dataset, but the defensibility depends on the purpose, risk, necessity, and other applicable requirements.

The question is:

"Why 90 days?"

not:

"Does PDPA say 90 days?"

Encryption

Encrypt personal data:

• in transit;
• at rest;
• in backups;
• and wherever the risk profile justifies it.

Encryption is an important security control, but avoid claiming that PDPA requires every field in every system to be encrypted in every possible situation.

The stronger engineering position is:

Use encryption as a baseline control, then apply additional protection according to the sensitivity and risk of the data.

For KYC-grade information such as identity documents and selfies, use isolated storage, strict access controls, short-lived credentials, audit logging, and strong encryption.

Cookies, analytics, and third-party scripts

If you run analytics, advertising, customer-support widgets, or other third-party scripts, you have created another personal-data processing surface.

Build an inventory.

For every third-party script, record:

• vendor;
• purpose;
• data received;
• pages where it executes;
• cookies or identifiers used;
• destination;
• retention;
• processor/sub-processor relationship;
• and whether user choice or another applicable requirement affects its deployment.

Avoid loading unnecessary third-party scripts on authenticated pages.

That chat widget might see every page that a logged-in user visits.

Your:

• cookie behaviour;
• privacy notice;
• choice mechanism;
• analytics configuration;
• and actual network traffic

should tell the same story.

If the privacy notice says one thing while the browser sends another, your documentation has become evidence against your implementation.

Vendors and processors: your liability, their servers

Your processor's direct Security Principle obligation does not eliminate the controller's responsibilities.

For every important vendor, document:

• what personal data they receive;
• why they receive it;
• whether they act as processor or another recipient;
• where the data is processed;
• which sub-processors are involved;
• applicable cross-border transfer conditions;
• security commitments;
• breach-notification obligations;
• access controls;
• retention;
• data return;
• deletion;
• and exit procedures.

Do not accept:

"It's in the cloud."

as a complete architecture answer.

Ask:

"Which cloud?"

Then:

"Which region?"

Then:

"Which sub-processors?"

Then:

"What happens when the contract ends?"

Vendor breach notification

If a vendor discovers a breach, your organisation may need to make its own regulatory assessment.

A vendor notification SLA of several days may be operationally useless if your regulatory clock is already running.

For high-risk processors, consider contractual requirements for:

• immediate incident notification;
• escalation contacts;
• incident cooperation;
• evidence preservation;
• affected-data identification;
• forensic support;
• and regulatory cooperation.

Access control and the human layer

A large proportion of practical security failures are access-control failures rather than cryptographic failures.

Common problems include:

• shared admin accounts;
• former employees retaining access;
• support staff with unrestricted database access;
• production credentials in repositories;
• .env files copied into chat;
• long-lived API keys;
• and developer laptops containing production exports.

The fixes are boring:

• SSO;
• MFA;
• role-based access control;
• least privilege;
• privileged-access review;
• short-lived credentials;
• central secrets management;
• automated offboarding;
• audit logs;
• and no unnecessary production data on developer machines.

Treat production access as a privilege that expires.

AI systems and personal data

AI introduces two directions of risk.

1. Personal data going into AI systems

Examples include:

• pasting customer records into a third-party model;
• sending support tickets to an external AI provider;
• training a model on user content;
• allowing an agent to read a CRM;
• or using personal data as model context.

Before doing that, identify:

• purpose;
• data categories;
• necessity;
• provider;
• processing location;
• retention;
• sub-processors;
• security;
• access;
• and applicable disclosure and transfer requirements.

Prefer:

• redaction;
• pseudonymisation;
• minimisation;
• scoped retrieval;
• short-lived context;
• and providers/configurations with appropriate retention controls.

Do not assume:

"The model is AI, therefore the data is no longer personal data."

It is still personal data if the information remains capable of identifying an individual.

2. AI systems handling personal data

Agents that read:

• inboxes;
• CRMs;
• ticket systems;
• HR systems;
• customer databases;
• or internal documents

inherit the risks of those systems.

Scope agent access like you would scope a new employee — and then make it narrower.

An agent that can read an entire CRM because "it might need the information someday" is not least privilege.

Where high-risk or automated decision-making/profiling is involved, assess whether additional privacy governance, risk assessment, or applicable guidance is relevant.

Source: JPDP Automated Decision-Making and Profiling Guideline

Incident response: the first 72 hours

The 72-hour period matters when the breach meets the applicable notification criteria.

Do not design your incident response process around waiting for a lawyer to tell engineering what happened.

Build the workflow now.

1. Contain

Revoke keys.

Rotate secrets.

Disable compromised accounts.

Isolate affected hosts.

Block malicious sessions.

Freeze dangerous pipelines.

Minutes matter more than narrative.

2. Establish the awareness timestamp

Record exactly when the organisation became aware of the personal data breach.

The DBN Guideline provides examples explaining when the notification period begins in different scenarios.

Source: DBN Guideline, section 6

Do not rely on:

"Someone mentioned it in Slack."

Create an incident record.

3. Scope

Determine:

• what happened;
• what systems were affected;
• what personal data was involved;
• how many data subjects may be affected;
• whether sensitive personal data was involved;
• whether identity fraud is possible;
• whether the incident is ongoing;
• and whether the breach may constitute significant harm.

Your data inventory makes this dramatically faster.

4. Preserve evidence

Preserve:

• relevant logs;
• authentication events;
• cloud audit trails;
• database audit records;
• network evidence;
• forensic images where appropriate;
• affected configurations;
• and incident timelines.

Do not destroy evidence while trying to clean up the breach.

5. Make the notification decision

For a qualifying breach, notify the Commissioner as soon as practicable and no later than 72 hours, following the DBN notification process.

The DBN Guideline specifically states that not all personal data breaches are notifiable and requires the data controller to assess whether the notification criteria are met.

Source: DBN Guideline, sections 5 and 6

6. Fix the class, not the instance

If one .env file leaked, search for every .env file.

If one shared account existed, find every shared account.

If one public storage bucket was exposed, inventory every storage bucket.

The post-mortem should eliminate the vulnerability class, not merely repair the single machine.

7. Write everything down

Record:

• detection time;
• awareness time;
• containment;
• scope;
• decisions;
• people involved;
• evidence;
• notifications;
• remediation;
• and follow-up actions.

Memory is not an incident-response system.

Then prepare an honest user notice where required:

• what happened;
• what data was affected;
• what the organisation did;
• what users should do;
• and where users can obtain further information.

The sovereignty connection

PDPA compliance and AI sovereignty are related architectural questions viewed from different directions.

One asks:

"Are we handling personal data according to the applicable Malaysian requirements?"

The other asks:

"Could another organisation, jurisdiction, or infrastructure provider materially affect our ability to control the system?"

A compliant database running on infrastructure you barely understand is not necessarily a resilient architecture.

For systems handling Malaysian personal data in 2026, consider:

• residency;
• cross-border transfers;
• vendor dependence;
• processor relationships;
• operational continuity;
• data access;
• exit strategies;
• and legal accountability

during the same architecture review.

A practical developer checklist

Before shipping a system that processes personal data, ask:

Data

• Do we have a data inventory?
• Do we know why each field exists?
• Do we classify sensitive personal data?
• Do we know where every copy is stored?
• Do we know which vendors receive it?

Access

• Is MFA enabled for privileged access?
• Are roles least-privilege?
• Are former employees automatically removed?
• Are production credentials centrally managed?
• Are administrative actions logged?

Logging

• Are request bodies excluded from logs by default?
• Are tokens and authentication headers redacted?
• Are logs access-controlled?
• Is retention documented?
• Can security events be reconstructed after an incident?

Retention

• Does every important dataset have a retention rationale?
• Are expired records actually deleted?
• Are object-storage lifecycle rules configured?
• Are backups covered by the retention strategy?
• Are analytics tables automatically expired?

Vendors

• Do we know our processors?
• Do we know our sub-processors?
• Do we know where processing occurs?
• Are breach notification obligations documented?
• Is data deletion/return covered by the exit plan?

Cross-border

• Does any personal data leave Malaysia?
• Which countries receive it?
• Which section 129 condition applies?
• Has the decision been documented?
• Is a Transfer Impact Assessment appropriate?

DPO

• Have we checked whether the DPO thresholds apply?
• Do our processing activities involve regular and systematic monitoring?
• If a DPO is required, is the appointment documented?
• Is the DPO registered with the Commissioner?
• Does the DPO have sufficient authority and access?

Breach response

• Can we establish when the organisation became aware of a breach?
• Can we identify affected data quickly?
• Can we estimate affected data subjects?
• Can we determine whether significant harm is likely?
• Can we produce the required notification information quickly?
• Have we rehearsed the process?

FAQ

Does PDPA apply to my small startup?

Potentially yes.

The PDPA applies to persons processing, or having control over or authorising the processing of, personal data in connection with commercial transactions, subject to the Act's scope and exclusions.

There is no general "small startup" exemption that makes the PDPA irrelevant.

However, some obligations have their own thresholds or conditions. The DPO requirement, for example, is not automatically triggered merely because a startup processes personal data.

Source: Personal Data Protection Act 2010 — Application and Non-Application

Do I need a DPO?

Not necessarily.

A data controller or data processor must appoint one or more DPOs where processing involves:

• personal data of more than 20,000 data subjects;
• sensitive personal data, including financial information, of more than 10,000 data subjects; or
• activities requiring regular and systematic monitoring, such as online user behaviour tracking.

Source: JPDP FAQ — DPO

If one of these conditions applies, the DPO must be appointed and registered in accordance with the applicable requirements.

What is the 72-hour rule?

It is the notification deadline for a personal data breach that meets the applicable notification criteria.

The Commissioner should be notified as soon as practicable and no later than 72 hours, in accordance with the DBN Guideline.

The guideline also makes clear that not every personal data breach is automatically notifiable.

Source: JPDP Data Breach Notification Guideline

Does every personal data breach have to be reported?

No.

The Commissioner's DBN Guideline explicitly states:

"Not all personal data breaches are notifiable to the Commissioner."

The data controller must assess whether the breach causes or is likely to cause significant harm.

Significant harm can include physical harm, financial loss, misuse for illegal purposes, exposure of sensitive personal data, potential identity fraud, or significant scale.

A breach affecting more than 1,000 data subjects is considered significant in scale.

Source: DBN Guideline, sections 5.1–5.3

Is using a US cloud provider a cross-border transfer?

If personal data is transferred to or processed outside Malaysia, the cross-border provisions of section 129 need to be considered.

Do not reduce the analysis to:

"US is allowed."

or:

"US is forbidden."

The framework provides multiple statutory conditions for cross-border transfers.

Source: JPDP Cross-Border Personal Data Transfer Guideline

Is 90 days the PDPA retention limit?

No.

PDPA does not create a universal 90-day retention period for application data or logs.

A 90-day period may be an appropriate engineering policy for a particular dataset, but the period should be justified by the purpose, operational needs, risk, and other applicable requirements.

Does PDPA require encryption everywhere?

Do not treat the Act as a blanket rule requiring encryption of every field in every system.

Encryption is an important security control and should normally be part of a modern security architecture, especially for sensitive personal data, credentials, backups, and data moving across networks.

The broader requirement is to implement appropriate practical security measures.

Source: Personal Data Protection Act 2010 and Personal Data Protection Standard

Does Malaysia's PDPA have data portability?

Yes.

Section 43A introduces a right to data portability, subject to technical feasibility and compatibility of the data format.

Source: Personal Data Protection (Amendment) Act 2024, section 43A

Can I send customer data to an AI provider?

Do not assume that an AI provider is automatically safe or automatically prohibited.

Evaluate:

• purpose;
• data categories;
• necessity;
• provider;
• processing location;
• retention;
• sub-processors;
• security;
• access;
• and applicable disclosure and transfer requirements.

Minimise and redact personal data before sending it to an external AI system wherever practical.

Is this legal advice?

No.

This is engineering guidance based on Malaysia's PDPA framework, the Personal Data Protection (Amendment) Act 2024, and publicly available Commissioner regulations, circulars, guidelines, and related materials.

For organisation-specific compliance decisions, obtain advice from a qualified Malaysian data-protection lawyer.

Sources and legal references

The following are the primary sources used for this article. Where this article makes a legal or regulatory claim, readers should verify the current version of the relevant source rather than relying solely on this article.

1. Personal Data Protection Act 2010 [Act 709]
   Personal Data Protection Commissioner Malaysia
   https://www.pdp.gov.my/ppdpv1/en/akta/pdp-act-2010-en/

2. Personal Data Protection (Amendment) Act 2024 [Act A1727]
   Personal Data Protection Commissioner Malaysia
   https://www.pdp.gov.my/ppdpv1/en/akta/personal-data-protection-amendment-act-2024/

3. P.U. (B) 522 — Personal Data Protection (Amendment) Act 2024: Appointment of Date of Coming Into Operation
   Effective dates: 1 January 2025, 1 April 2025 and 1 June 2025
   https://www.pdp.gov.my/ppdpv1/wp-content/uploads/2024/12/PENETAPAN-TARIKH-PERMULAAN-KUAT-KUASA.pdf

4. Personal Data Protection Guidelines on the Appointment of Data Protection Officer (DPO)
   Version 1.0, issued 25 February 2025
   https://www.pdp.gov.my/ppdpv1/wp-content/uploads/2025/08/GP_DPO_ENG.pdf

5. Personal Data Protection Guidelines on Data Breach Notification (DBN)
   Personal Data Protection Commissioner Malaysia
   https://www.pdp.gov.my/ppdpv1/wp-content/uploads/2025/08/GP_DBN_ENG.pdf

6. Personal Data Protection Guidelines on Cross-Border Transfer of Personal Data (CBPDT)
   Personal Data Protection Commissioner Malaysia
   https://www.pdp.gov.my/ppdpv1/wp-content/uploads/2025/08/GP_CBPDT_EN.pdf

7. Personal Data Protection Commissioner FAQ
   Includes current DPO appointment thresholds and related guidance
   https://www.pdp.gov.my/ppdpv1/en/faq/

8. JPDP DPO Registration System
   Official DPO registration criteria and registration portal
   https://daftar.pdp.gov.my/v1/dpo-register

9. Automated Decision-Making and Profiling Guideline (ADMP)
   Personal Data Protection Commissioner Malaysia
   https://www.pdp.gov.my/ppdpv1/en/akta/automated-decision-making-and-profiling-guideline-admp/

10. Personal Data Protection Commissioner — Act 709 resource index
    Official index containing the Act, circulars, guidelines, standards, and related materials
    https://www.pdp.gov.my/ppdpv1/en/akta709/