PDPA Malaysia untuk Developer: Apa yang Perlu Dibina

PDPA Malaysia untuk Developer: Apa yang Perlu Dibina

Ini panduan teknikal untuk pembina, bukan nasihat guaman. Kerangka undang-undangnya ialah Akta Perlindungan Data Peribadi 2010 (Akta 709), bersama Akta Perlindungan Data Peribadi (Pindaan) 2024, peraturan, pekeliling dan garis panduan Pesuruhjaya. Artikel ini menerangkan apa yang patut dibina dari sudut engineering; ia bukan penentuan sama ada sesuatu organisasi itu compliant dari segi undang-undang.

Bertahun-tahun lamanya PDPA terasa seperti bunyi latar untuk kebanyakan developer: checkbox consent, privacy policy yang tiada siapa baca, dan kawalan data yang dianggap kerja dokumentasi semata-mata.

Pendekatan itu semakin sukar dipertahankan.

Akta Perlindungan Data Peribadi (Pindaan) 2024 membawa perubahan besar yang mula berkuat kuasa secara berperingkat pada 2025.

Antaranya:

• rangka kerja data breach notification;
• pelantikan Data Protection Officer (DPO) dalam keadaan tertentu;
• kewajipan Security Principle secara langsung kepada data processor;
• hak data portability;
• perubahan kepada keperluan pemindahan data ke luar Malaysia;
• biometric data dimasukkan dalam kategori sensitive personal data;
• dan peningkatan penalti bagi kesalahan tertentu.

Tarikh kuat kuasa pula tidak semuanya sama:

• 1 Januari 2025 — beberapa peruntukan pindaan mula berkuat kuasa;
• 1 April 2025 — beberapa peruntukan termasuk kewajipan keselamatan processor;
• 1 Jun 2025 — antara lain peruntukan DPO dan data breach notification.

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

Bagi developer, point penting bukan istilah undang-undang itu sendiri.

Point penting ialah:

Apa yang perlu berubah dalam architecture, database, logging, access control, vendor management dan incident response?

Artikel ini cuba jawab soalan itu.

Mod kegagalannya pula tempatan dan konkrit — skema pelanggan yang bocor lengkap dengan lokasi dan data KYC, RM28.67 juta lesap kepada scam kod QR, dan username yang menjadi identiti.

Model mental 60 saat

PDPA melindungi data peribadi yang diproses dalam transaksi komersial, tertakluk kepada skop dan pengecualian di bawah Akta.

Ia terpakai kepada pihak yang memproses, atau mempunyai kawalan atau membenarkan pemprosesan, data peribadi dalam transaksi komersial. Kerajaan Persekutuan dan Kerajaan Negeri mempunyai pengecualian tertentu di bawah Akta.

Source: JPDP — Application and Non-Application of the Act

Kalau aplikasi anda mengendalikan:

• nama;
• emel;
• nombor telefon;
• nombor IC;
• lokasi;
• gambar;
• ID peranti;
• rekod pelanggan;
• dokumen KYC;
• atau maklumat lain yang boleh mengenal pasti individu yang masih hidup,

maka data tersebut patut dianggap sebagai isu engineering, bukan sekadar isu privacy policy.

JPDP sendiri memberi contoh seperti nama, alamat, nombor kad pengenalan, nombor pasport, maklumat kesihatan, emel dan gambar sebagai data yang boleh menjadi personal data apabila individu boleh dikenal pasti.

Source: JPDP FAQ

Mulakan dengan sepuluh soalan:

1. Apa personal data yang kita pegang?
2. Kenapa kita memprosesnya?
3. Di mana ia disimpan?
4. Siapa boleh akses?
5. Siapa menerima data tersebut?
6. Berapa lama ia diperlukan?
7. Bagaimana permintaan akses atau pembetulan dikendalikan?
8. Apa berlaku jika data bocor?
9. Adakah data dipindahkan atau diproses di luar Malaysia?
10. Vendor dan processor mana yang boleh mengaksesnya?

Tujuh prinsip PDPA masih menjadi rangka asas:

1. Prinsip Am — pemprosesan perlu mematuhi keperluan Akta, termasuk keperluan consent dan keadaan pengecualian yang dibenarkan.
2. Prinsip Notis dan Pilihan — berikan notis yang diperlukan mengenai pemprosesan personal data.
3. Prinsip Penzahiran — jangan dedahkan data di luar tujuan dan keadaan yang dibenarkan.
4. Prinsip Keselamatan — ambil langkah praktikal untuk melindungi personal data.
5. Prinsip Penyimpanan — jangan simpan personal data lebih lama daripada yang diperlukan.
6. Prinsip Integriti Data — pastikan data tepat, lengkap, tidak mengelirukan dan terkini.
7. Prinsip Akses — sediakan mekanisme bagi hak akses dan pembetulan yang berkenaan.

Source: Personal Data Protection Act 2010 (Act 709)

Penting: jangan terus copy model GDPR ke dalam sistem Malaysia.

Malaysia mempunyai framework sendiri.

Apa berubah pada 2024–2025 — dan kenapa developer perlu peduli

1. Data breach notification menjadi sebahagian daripada architecture

Pindaan 2024 memperkenalkan s.12B — Data Breach Notification.

Akta menyatakan bahawa apabila data controller mempunyai sebab untuk mempercayai bahawa personal data breach telah berlaku, Commissioner perlu dimaklumkan mengikut cara dan bentuk yang ditentukan.

Jika breach tersebut menyebabkan atau berkemungkinan menyebabkan significant harm kepada data subject, data subject juga perlu dimaklumkan tanpa unnecessary delay mengikut keperluan yang ditetapkan.

Source: Personal Data Protection (Amendment) Act 2024, s.12B

Garis Panduan Data Breach Notification (DBN) kemudian menerangkan bila sesuatu breach dianggap perlu diberi perhatian sebagai breach yang boleh dinotifikasikan.

Antara keadaan yang boleh menunjukkan significant harm termasuk:

• risiko physical harm;
• financial loss;
• kesan kepada credit atau property;
• penyalahgunaan untuk tujuan yang menyalahi undang-undang;
• sensitive personal data;
• data yang bersama maklumat lain boleh membawa kepada identity fraud;
• atau breach pada skala yang signifikan.

Garis panduan tersebut juga menggunakan lebih daripada 1,000 data subjects sebagai kriteria significant scale.

Jangan tafsir angka itu sebagai:

"Kalau 999 orang, selamat."

Ia ialah salah satu kriteria untuk menilai significant harm/significant scale, bukan lesen untuk mengabaikan breach kecil.

Source: JPDP — Data Breach Notification Guideline

Untuk breach yang memenuhi kriteria notification, DBN framework menetapkan notification kepada Commissioner secepat yang praktikal dan tidak lewat daripada 72 jam, mengikut proses yang ditetapkan.

Jadi jangan bina incident response dengan:

"Nanti lawyer tengok."

Bina sistem yang boleh menghasilkan:

• detection timestamp;
• awareness timestamp;
• incident ID;
• scope;
• affected systems;
• data classification;
• affected data subjects;
• significant-harm assessment;
• evidence;
• notification decision;
• notification status;
• dan audit trail.

72 jam bukan sekadar masalah legal.

Ia ialah masalah observability.

2. DPO bukan wajib untuk semua organisasi

Ini salah satu perkara paling mudah untuk ditulis secara salah.

Pindaan memperkenalkan s.12A — Appointment of Data Protection Officer, tetapi bukan semua organisasi wajib mempunyai DPO.

Data controller atau data processor perlu melantik satu atau lebih DPO apabila pemprosesan memenuhi salah satu keadaan berikut:

• melibatkan personal data melebihi 20,000 data subjects;
• melibatkan sensitive personal data, termasuk financial information, melebihi 10,000 data subjects; atau
• melibatkan aktiviti yang memerlukan regular and systematic monitoring, contohnya online user behaviour tracking.

Source: JPDP FAQ — Appointment of Data Protection Officer

Keperluan DPO berkuat kuasa pada 1 Jun 2025.

Source: P.U. (B) 522

Jadi soalan untuk startup bukan:

"Adakah PDPA memaksa semua startup ada DPO?"

Tetapi:

"Adakah processing activity kita memenuhi salah satu daripada criteria DPO?"

Kalau ya, barulah proses appointment dan registration perlu dibuat.

JPDP juga membenarkan DPO dilantik daripada existing employees, outsourced arrangement, atau seorang DPO yang berkhidmat untuk beberapa organisasi dalam keadaan yang dibenarkan, dengan syarat kompetensi, resources dan conflict-of-interest requirements dipenuhi.

Source: JPDP FAQ — DPO

Selepas appointment, notification kepada Commissioner perlu dibuat melalui sistem yang ditetapkan. Manual rasmi JPDP menyatakan notification appointment perlu dibuat dalam tempoh 21 hari daripada tarikh appointment.

Source: JPDP — DPO Registration User Manual

3. Processor kini mempunyai kewajipan keselamatan secara langsung

Ini perubahan yang penting untuk SaaS.

Akta pindaan memasukkan peruntukan bahawa apabila processing dilakukan oleh data processor bagi pihak data controller, data processor hendaklah mematuhi Security Principle.

Source: Personal Data Protection (Amendment) Act 2024, s.5

Ini bermakna kalau anda menjalankan:

• SaaS;
• managed database;
• cloud application;
• CRM;
• analytics platform;
• outsourced processing;
• atau platform lain yang memproses personal data bagi pihak controller,

security architecture anda bukan sekadar masalah customer.

Ia adalah sebahagian daripada privacy risk.

Minimum engineering baseline patut merangkumi:

• authentication;
• authorisation;
• MFA untuk privileged access;
• logging;
• secrets management;
• vulnerability management;
• backup security;
• incident response;
• employee offboarding;
• access review;
• vendor dan sub-processor management.

4. Cross-border transfer memerlukan assessment sebenar

Section 129 mengawal pemindahan personal data keluar dari Malaysia.

Pindaan 2024 mengubah struktur section tersebut dan membolehkan data controller memindahkan personal data ke luar Malaysia tertakluk kepada keadaan yang ditetapkan dalam Akta.

Antara keadaan yang berkaitan termasuk:

• destinasi yang mempunyai undang-undang yang substantially similar kepada PDPA;
• destinasi yang memberikan tahap perlindungan yang mencukupi;
• consent;
• keadaan tertentu berkaitan contractual necessity;
• legal proceedings atau legal rights;
• reasonable precautions dan due diligence;
• dan keadaan lain yang dinyatakan dalam section 129.

Source: Personal Data Protection (Amendment) Act 2024, s.129

JPDP juga telah menerbitkan Cross-Border Personal Data Transfer Guideline (CBPDT) untuk menerangkan keadaan-keadaan tersebut.

Source: JPDP — Cross-Border Personal Data Transfer Guideline

Jadi:

"Database kita dekat AWS US."

bukan jawapan compliance.

Ia ialah architecture fact.

Soalan seterusnya:

• data apa yang keluar Malaysia?
• siapa menerima?
• di negara mana?
• processor atau sub-processor siapa?
• apa tujuan transfer?
• condition section 129 yang mana digunakan?
• apa contractual protection yang ada?
• apakah security controls?
• dan bagaimana keputusan itu didokumentasikan?

CBPDT juga memperkenalkan konsep Transfer Impact Assessment (TIA) sebagai risk assessment untuk menilai rangka kerja undang-undang dan perlindungan di tempat penerima.

Source: CBPDT Guideline

Cloud-region selection bukan lagi sekadar keputusan infrastructure.

Untuk sistem yang memproses personal data, ia juga boleh menjadi keputusan privacy architecture.

5. Biometric data kini termasuk sensitive personal data

Akta A1727 menambah definisi biometric data dan memasukkannya ke dalam definisi sensitive personal data.

Source: Personal Data Protection (Amendment) Act 2024

Ini relevan untuk sistem seperti:

• fingerprint authentication;
• facial recognition;
• biometric identity verification;
• voice-based biometric processing;
• dan sistem lain yang memproses ciri fizikal, fisiologi atau tingkah laku melalui technical processing.

Jangan terus anggap bahawa menggunakan Face ID pada telefon bermaksud aplikasi anda menyimpan data biometrik pengguna.

Kalau platform authentication hanya memberikan application satu authentication result atau credential dan raw biometric tidak pernah sampai ke server anda, architecture itu sangat berbeza daripada menyimpan template biometric sendiri.

Prinsip engineering yang lebih selamat:

Jangan simpan biometric material kalau architecture tidak memerlukannya.

6. Data portability menjadi hak statutori

Section 43A memperkenalkan hak data portability.

Data subject boleh meminta data controller menghantar personal data mereka secara terus kepada data controller lain yang dipilih oleh mereka melalui electronic means.

Hak ini tertakluk kepada:

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

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

Ini bermakna data portability patut difikirkan ketika architecture dibina.

Pertimbangkan:

• canonical data model;
• machine-readable export;
• identity verification;
• request authentication;
• audit trail;
• destination-controller details;
• field mapping;
• secure transmission;
• dan schema versioning.

Jangan tunggu lima tahun kemudian baru cuba bina:

Export Everything.

Inventori data peribadi: tahu apa yang anda pegang

Anda tidak boleh melindungi apa yang anda sendiri tidak boleh senaraikan.

Kekalkan peta data yang hidup.

Jadual lebih berguna daripada rasa yakin.

Analisis kebocoran Misi Rakyat ialah rupa estate yang tidak dipetakan dari luar: skema pelanggan, KYC rider, rekod vendor, dan file .env.

Setiap satunya akhirnya menjadi:

"Eh, benda ni siapa yang punya?"

Bina jadual itu sebelum orang lain membinanya untuk anda.

Logging tanpa membina liabiliti

Log ialah bukti operasi.

Tapi log juga boleh menjadi database personal data kedua yang jauh lebih mudah diakses oleh developer.

Amalkan:

• Minimumkan ketika menulis. Jangan log request body yang mengandungi personal data secara default.
• Log identifier, bukan kandungan. Gunakan request ID, user ID atau event ID apabila kandungan sebenar tidak diperlukan.
• Redact secara struktur. Mask IC number, phone number, email, tokens, cookies dan authorization headers dalam logging pipeline.
• Tetapkan retention berdasarkan tujuan. Jangan anggap semua log perlu disimpan selamanya.
• Kawal akses. Log aggregator perlu access control seperti sistem production lain.
• Pisahkan security events daripada debug noise. Authentication events, privilege changes dan administrative actions mungkin memerlukan retention serta protection yang berbeza.

Personal Data Protection Standard 2015 menetapkan bahawa langkah keselamatan yang praktikal perlu digunakan untuk melindungi personal data daripada kehilangan, salah guna, pengubahsuaian, akses atau disclosure tanpa kebenaran, serta pemusnahan.

Source: Personal Data Protection Standard 2015

Jadi jangan tulis:

"Log 14 hari sebab PDPA kata 14 hari."

Tulis:

"Log ini disimpan 14 hari kerana itu tempoh yang dipilih berdasarkan keperluan operasi dan security."

Itu dua perkara yang berbeza.

Database, backup dan retention yang betul-betul memadam

Retention failure biasanya bukan berlaku pada satu database sahaja.

Ia berlaku pada:

• soft delete;
• replica;
• backup;
• analytics;
• object storage;
• export;
• cache;
• log;
• dan developer machine.

Personal Data Protection Standard 2015 menyatakan bahawa data controller perlu mengambil langkah yang munasabah untuk memastikan personal data dimusnahkan atau dipadamkan secara kekal apabila ia tidak lagi diproses.

Source: Personal Data Protection Standard 2015

Jadi bina deletion workflow sebenar:

• explicit deletion path;
• deletion pada replica;
• object-storage lifecycle;
• analytics expiry;
• stale export cleanup;
• backup strategy;
• dan documented exception apabila sesuatu data perlu dikekalkan atas sebab lain.

90 hari bukan retention limit yang ditetapkan PDPA.

Kalau anda memilih 90 hari untuk analytics:

"Kenapa 90 hari?"

mestilah boleh dijawab.

Contohnya:

"90 hari diperlukan untuk fraud analysis dan operational trend analysis."

bukan:

"Sebab PDPA kata 90 hari."

Encryption

Encryption patut menjadi baseline security control moden:

• TLS untuk data in transit;
• encryption at rest;
• encrypted backups;
• key management;
• dan perlindungan tambahan untuk data berisiko tinggi.

Tetapi jangan tulis bahawa PDPA secara blanket mewajibkan setiap field personal data diencrypt.

Kerangka undang-undang dan Personal Data Protection Standard menekankan langkah keselamatan yang praktikal dan munasabah.

Source: Personal Data Protection Standard 2015

Untuk KYC seperti IC, passport, selfie dan dokumen identiti:

• asingkan storage;
• ketatkan access control;
• gunakan encryption;
• audit akses;
• gunakan credentials jangka pendek;
• dan minimakan salinan.

Cookies, analytics dan skrip pihak ketiga

Analytics, advertising, chat widget dan third-party scripts semuanya boleh menambah permukaan pemprosesan data.

Jangan anggap browser sebagai tempat yang terpisah daripada architecture.

Inventorikan setiap third-party script:

• vendor;
• tujuan;
• data yang diterima;
• cookie atau identifier;
• halaman yang menjalankannya;
• destinasi data;
• retention;
• processor/sub-processor relationship;
• dan keperluan notice, choice atau consent yang terpakai.

Jangan buat claim:

"Semua analytics cookie mesti consent sebab PDPA."

Itu terlalu simplistik.

Sebaliknya:

Pastikan mekanisme cookie, privacy notice, user choice dan network behaviour konsisten dengan keperluan yang terpakai.

Kalau privacy notice kata satu benda tetapi browser menghantar benda lain, implementation anda sendiri sudah menjadi bukti yang bercanggah.

Source: JPDP — Guidance on the Preparation of Personal Data Protection Notices

Vendor dan processor: data anda, server mereka

Processor kini mempunyai kewajipan terus terhadap Security Principle.

Tetapi itu tidak bermaksud controller boleh lepas tangan.

Untuk setiap vendor penting, tahu:

• personal data apa yang mereka terima;
• kenapa mereka menerimanya;
• peranan mereka sebagai processor atau pihak lain;
• di mana processing berlaku;
• siapa sub-processor;
• sama ada data keluar Malaysia;
• security commitments;
• breach notification;
• access control;
• retention;
• deletion;
• data return;
• dan exit procedure.

Jangan terima jawapan:

"It's in the cloud."

Tanya:

"Cloud mana?"

Kemudian:

"Region mana?"

Kemudian:

"Sub-processor siapa?"

Kemudian:

"Apa berlaku apabila kontrak tamat?"

Vendor breach notification

Vendor mungkin mempunyai kewajipan kontrak yang berbeza daripada kewajipan regulator organisasi anda.

Sebab itu SLA vendor sangat penting.

Jangan reka kontrak:

"Vendor akan notify dalam 30 hari."

sedangkan organisasi anda mungkin perlu membuat assessment dan notification jauh lebih awal.

Untuk processor berisiko tinggi, pertimbangkan keperluan kontrak berkaitan:

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

Kawalan akses dan lapisan manusia

Banyak security failure bukan bermula dengan cryptography.

Ia bermula dengan:

• shared admin account;
• bekas staf masih ada access;
• support staff boleh baca database penuh;
• production credentials dalam repository;
• .env dalam chat;
• API key yang hidup bertahun-tahun;
• production dump dalam laptop developer.

Pembetulannya memang membosankan:

• SSO;
• MFA;
• role-based access control;
• least privilege;
• privileged access review;
• short-lived credentials;
• secrets management;
• automated offboarding;
• audit logs;
• dan larangan terhadap production data yang tidak diperlukan pada developer machine.

Treat production access sebagai privilege.

Bukan hak kekal.

Sistem AI dan data peribadi

AI menambah dua arah risiko.

1. Personal data masuk ke sistem AI

Contohnya:

• paste customer record ke third-party model;
• hantar support ticket kepada AI provider;
• training menggunakan user content;
• agent membaca CRM;
• atau personal data dijadikan context model.

Sebelum data dihantar, tahu:

• tujuan;
• kategori data;
• keperluan;
• provider;
• lokasi processing;
• retention;
• sub-processors;
• security;
• access;
• dan keperluan disclosure/cross-border yang terpakai.

Utamakan:

• redaction;
• pseudonymisation;
• minimisation;
• scoped retrieval;
• short-lived context;
• dan konfigurasi provider yang sesuai dengan keperluan data protection.

Jangan anggap:

"Ini AI, jadi data bukan lagi personal data."

Kalau maklumat itu masih boleh mengenal pasti individu, nature datanya tidak berubah hanya kerana ia dimasukkan ke dalam model.

2. AI yang mengendalikan personal data

Agent yang boleh membaca:

• inbox;
• CRM;
• support tickets;
• HR system;
• customer database;
• atau internal documents

mewarisi risiko sistem tersebut.

Scope agent seperti anda scope pekerja baru.

Kemudian sempitkan lagi.

Agent yang boleh baca seluruh CRM kerana:

"Mana tahu dia perlukan nanti"

bukan least privilege.

Untuk automated decision-making atau profiling yang berisiko, semak juga guidance JPDP yang berkaitan.

Source: JPDP — Automated Decision-Making and Profiling Guideline

Tindak balas insiden: 72 jam pertama

72 jam penting apabila notification kepada Commissioner diperlukan di bawah DBN framework.

Jangan tunggu sehingga breach berlaku baru design process.

1. Bendung dahulu

• Batalkan keys.
• Rotate secrets.
• Disable compromised accounts.
• Isolate host.
• Block malicious sessions.
• Freeze dangerous pipelines.

Minit lebih penting daripada naratif.

2. Rekod awareness timestamp

Catat bila organisasi mendapat tahu tentang breach.

Jangan bergantung kepada:

"Someone mentioned it dalam Slack."

Bina incident record.

3. Scope

Cari:

• apa yang berlaku;
• system mana terjejas;
• personal data apa terlibat;
• sensitive personal data atau tidak;
• berapa data subject;
• adakah identity fraud mungkin berlaku;
• adakah incident masih berjalan;
• dan adakah significant harm berkemungkinan.

Data inventory yang baik mempercepatkan langkah ini.

4. Preserve evidence

Preserve:

• logs;
• authentication events;
• cloud audit trails;
• database audit records;
• network evidence;
• affected configuration;
• forensic evidence apabila sesuai;
• dan incident timeline.

Jangan padam bukti semasa cuba "clean up".

5. Buat notification assessment

Jika breach memenuhi notification criteria, ikut DBN process dan notify Commissioner dalam tempoh yang ditetapkan, termasuk tempoh tidak lewat daripada 72 jam untuk notification yang berkenaan.

Source: JPDP — Data Breach Notification Guideline

6. Betulkan kelasnya, bukan instance-nya

Kalau satu .env bocor:

Cari semua .env.

Kalau satu shared account wujud:

Cari semua shared account.

Kalau satu public bucket terbuka:

Audit semua bucket.

Post-mortem mesti membunuh vulnerability class, bukan sekadar satu symptom.

7. Tulis semuanya

Rekod:

• detection;
• awareness;
• containment;
• scope;
• decision;
• evidence;
• notification;
• remediation;
• follow-up.

Memory bukan incident-response system.

Sambungan kedaulatan

Pematuhan PDPA dan kedaulatan AI mempunyai soalan architecture yang berkait:

"Siapa mengawal data?"

dan:

"Siapa mengawal infrastructure yang memproses data itu?"

Database yang memenuhi keperluan tetapi bergantung kepada infrastructure yang kita sendiri tidak faham bukan architecture yang sangat resilient.

Untuk sistem yang memproses data Malaysia pada 2026, masukkan perkara berikut dalam architecture review:

• residency;
• cross-border transfer;
• vendor dependency;
• processor relationships;
• operational continuity;
• access;
• exit strategy;
• dan legal accountability.

Checklist developer

Sebelum shipping sistem yang memproses personal data:

Data

• Ada data inventory?
• Tahu kenapa setiap field wujud?
• Tahu data mana sensitive?
• Tahu semua lokasi salinan?
• Tahu vendor yang menerima data?

Access

• MFA untuk privileged access?
• Least privilege?
• Offboarding automatik?
• Production credentials centralized?
• Administrative actions dilog?

Logging

• Request body dikecualikan daripada logs secara default?
• Token dan authorization headers diredact?
• Log access-controlled?
• Retention didokumenkan?
• Security events boleh direconstruct?

Retention

• Setiap dataset ada retention rationale?
• Data expired betul-betul dipadam?
• Object storage ada lifecycle?
• Backup strategy mengambil kira deletion?
• Analytics/event data mempunyai expiry?

Vendors

• Tahu semua processor?
• Tahu sub-processor?
• Tahu lokasi processing?
• Ada breach notification clause?
• Ada deletion/return selepas kontrak tamat?

Cross-border

• Ada personal data keluar Malaysia?
• Negara mana menerima?
• Condition section 129 yang digunakan?
• Keputusan didokumenkan?
• Perlu TIA?

DPO

• Sudah semak threshold DPO?
• Ada regular and systematic monitoring?
• Jika DPO diperlukan, appointment didokumenkan?
• Notification/registration dibuat?
• DPO mempunyai resources dan access yang mencukupi?

Breach response

• Boleh establish awareness time?
• Boleh identify affected data?
• Boleh estimate data subjects?
• Boleh assess significant harm?
• Boleh hasilkan notification information dengan cepat?
• Pernah buat incident-response exercise?

FAQ

Adakah PDPA terpakai kepada startup kecil saya?

Boleh jadi ya.

Skop PDPA bukan berdasarkan saiz startup semata-mata. Ia berkaitan pemprosesan personal data dalam transaksi komersial, tertakluk kepada skop dan pengecualian Akta.

Jadi jangan anggap:

"Kami startup kecil, PDPA tak apply."

Source: JPDP — Application and Non-Application of the Act

Tetapi jangan juga anggap semua kewajipan mempunyai threshold yang sama.

Contohnya, DPO tidak wajib untuk semua startup.

Apa peraturan 72 jam itu?

Untuk breach yang memenuhi notification requirements di bawah DBN framework, notification kepada Commissioner perlu dibuat secepat praktikal dan tidak lewat daripada 72 jam, mengikut proses yang ditetapkan.

72 jam itu ialah operational deadline yang datang daripada DBN framework.

Teks s.12B sendiri menyebut notification kepada Commissioner perlu dibuat as soon as practicable.

Source: Personal Data Protection (Amendment) Act 2024, s.12B

Source: JPDP — Data Breach Notification Guideline

Adakah setiap breach automatik perlu diumumkan kepada pengguna?

Tidak.

Notification kepada data subject bergantung kepada keadaan yang ditetapkan, termasuk sama ada breach menyebabkan atau berkemungkinan menyebabkan significant harm.

Jangan samakan:

"personal data breach berlaku"

dengan:

"semua pengguna mesti terus diberitahu."

Buat assessment mengikut DBN framework.

Perlukah saya ada DPO?

Tidak semestinya.

DPO diperlukan apabila processing memenuhi salah satu daripada criteria berikut:

• personal data melebihi 20,000 data subjects;
• sensitive personal data termasuk financial information melebihi 10,000 data subjects; atau
• regular and systematic monitoring, seperti online user behaviour tracking.

Source: JPDP FAQ — DPO

Jika criteria dipenuhi, DPO perlu dilantik dan notification dibuat melalui sistem yang ditetapkan.

Bolehkah CTO menjadi DPO?

Boleh dalam keadaan yang sesuai.

JPDP menyatakan DPO boleh dilantik daripada existing employees selagi individu tersebut mempunyai kelayakan, pengalaman, kemahiran dan expertise yang sesuai serta tiada conflict of interest dengan tugas sedia ada.

Source: JPDP FAQ — DPO

Jadi:

"CTO = DPO"

bukan automatik salah.

Tetapi:

"CTO jadi DPO tanpa resources, training atau independent access"

ialah architecture/governance yang patut dipersoalkan.

Adakah guna cloud AS dikira cross-border?

Jika personal data dipindahkan atau diproses di luar Malaysia, section 129 perlu dipertimbangkan.

Tetapi jangan ringkaskan undang-undang kepada:

"US dibenarkan."

atau:

"US dilarang."

Section 129 menyediakan beberapa keadaan yang membolehkan cross-border transfer, dan CBPDT Guideline menerangkan bagaimana keadaan tersebut dinilai.

Source: JPDP — Cross-Border Personal Data Transfer Guideline

Adakah 90 hari ialah had retention PDPA?

Tidak.

PDPA tidak menetapkan satu universal 90-day retention limit untuk semua application data atau logs.

Kalau organisasi memilih 90 hari, mesti ada rationale berdasarkan tujuan processing, operational requirements, risk dan keperluan lain yang terpakai.

Adakah PDPA mewajibkan encryption untuk semua personal data?

Jangan tulis begitu.

Personal Data Protection Standard 2015 mewajibkan langkah keselamatan yang praktikal untuk melindungi personal data.

Encryption ialah control yang sangat penting dan patut digunakan mengikut risk profile, terutama untuk sensitive/high-risk data, backups dan communications.

Tetapi jangan claim bahawa setiap field wajib encrypted secara blanket.

Source: Personal Data Protection Standard 2015

Adakah biometric data sekarang sensitive personal data?

Ya.

Akta A1727 menambah biometric data ke dalam definisi sensitive personal data.

Source: Personal Data Protection (Amendment) Act 2024

Adakah Malaysia mempunyai data portability?

Ya.

Section 43A memperkenalkan hak data portability, tertakluk kepada technical feasibility dan compatibility of data format.

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

Bolehkah saya hantar customer data kepada AI provider?

Jangan anggap automatik selamat atau automatik dilarang.

Nilai:

• tujuan;
• kategori data;
• necessity;
• provider;
• processing location;
• retention;
• sub-processors;
• security;
• access;
• disclosure;
• dan cross-border requirements yang terpakai.

Minimakan dan redak personal data sebelum dihantar ke external AI system apabila praktikal.

Adakah ini nasihat guaman?

Tidak.

Ini panduan engineering berdasarkan Akta Perlindungan Data Peribadi 2010, Akta Pindaan 2024, standard, pekeliling dan garis panduan rasmi JPDP/PPDP.

Untuk keputusan compliance organisasi yang spesifik, dapatkan nasihat daripada peguam perlindungan data Malaysia.

Sources dan rujukan rasmi

Artikel ini sengaja menggunakan sumber primary daripada JPDP/PPDP untuk claim berkaitan undang-undang.

1. Personal Data Protection Act 2010 — Act 709

Personal Data Protection Act 2010

Sumber asas untuk tujuh prinsip, skop Akta, hak data subject dan kewajipan pemprosesan.

2. Personal Data Protection (Amendment) Act 2024 — Act A1727

Personal Data Protection (Amendment) Act 2024

Rujukan utama untuk:

• DPO;
• data breach notification;
• processor security obligation;
• biometric data;
• data portability;
• cross-border transfer;
• dan pindaan lain.

3. P.U. (B) 522 — Effective Dates

Appointment of Date of Coming Into Operation

Menetapkan tarikh kuat kuasa pindaan:

• 1 Januari 2025;
• 1 April 2025;
• 1 Jun 2025.

4. DPO Guideline

Personal Data Protection Guidelines on the Appointment of Data Protection Officer

Version 1.0, issued 25 February 2025.

Rujukan untuk pelantikan, peranan, independence, competency dan operasi DPO.

5. JPDP DPO FAQ

JPDP FAQ

Sumber rasmi untuk threshold DPO:

• 20,000 data subjects;

• 10,000 sensitive personal data including financial information;

• regular and systematic monitoring.

6. DPO Registration Manual

DPO Registration User Manual

Rujukan untuk proses registration dan notification DPO.

7. Data Breach Notification Guideline

Personal Data Protection Guidelines on Data Breach Notification

Rujukan untuk:

• significant harm;
• significant scale;
• notification;
• 72-hour operational requirement;
• dan data subject notification.

8. Cross-Border Personal Data Transfer Guideline

Personal Data Protection Guidelines on Cross-Border Transfer of Personal Data

Rujukan untuk section 129 dan cross-border transfer assessment.

9. Personal Data Protection Standard 2015

Personal Data Protection Standard 2015

Rujukan untuk minimum security, storage dan data integrity requirements.

10. Guidance on Personal Data Protection Notices

Guidance on the Preparation of Personal Data Protection Notices

Rujukan untuk privacy notice dan implementation.

11. Automated Decision-Making and Profiling Guideline

Automated Decision-Making and Profiling Guideline

Rujukan tambahan apabila sistem AI melakukan automated decision-making atau profiling.

12. JPDP Act 709 Resource Index

Official Act 709 Resource Index

Index rasmi untuk Akta, pekeliling, standard dan garis panduan berkaitan PDPA.