Why Most PDPA Checklists Miss the Point
Most PDPA compliance guides are written by lawyers for lawyers. They tell you what the law says — not what your engineering team needs to build. The result is organisations that can recite the seven principles but can't answer a basic question: where is every piece of personal data stored, and who has access to it?
This article is the technical complement. It assumes you've read the legal frameworks. It focuses on what your systems actually need to do to satisfy those obligations.
The Seven Principles, Engineered
1. General — Lawful Basis and Consent
Every piece of personal data your system collects needs an identified lawful basis. For most commercial applications in Malaysia, this will be consent. That means your consent capture mechanism must: record exactly what was consented to, store the timestamp and version of the consent notice, and allow the user to withdraw it at any time with equal ease.
An audit trail table in your database is not optional — it's the proof of compliance. If you can't demonstrate that User X consented to Y on date Z, you don't have consent.
2. Notice — Privacy Notices That Mean Something
Your privacy notice must be available before or at the time of collection. In practice, this means it must be surfaced during onboarding, not buried in a footer. The PDPC has specifically called out buried consent mechanisms as inadequate.
3. Disclosure — Third-Party Data Sharing
Every third-party service that receives personal data from your systems is a data processor. You need a Data Processing Agreement (DPA) with each of them. More critically, your data flow diagram must be accurate — you cannot have processors that are invisible to your DPO. Audit your integrations: analytics SDKs, CRM connectors, payment processors, cloud infrastructure providers.
4. Security — The Technical Controls
The Act requires "practical steps" to protect personal data. In practice, this means: encryption at rest (AES-256 minimum) and in transit (TLS 1.2+), role-based access controls with principle of least privilege, audit logging of all access to personal data tables, multi-factor authentication for admin access, and regular penetration testing (annually at minimum for systems processing sensitive data).
If you're on AWS, GCP, or Azure, most of these are available natively — but they are opt-in. They are not active by default.
5. Retention — You Cannot Keep Data Forever
This is the most commonly ignored principle. Personal data must not be retained longer than necessary for the purpose it was collected. This means building a data retention policy and then actually implementing it in your database. Scheduled jobs that delete or anonymise records past their retention window are a compliance requirement, not a nice-to-have.
6. Data Integrity — Accuracy and Correction Rights
Users have the right to correct inaccurate personal data. Your system needs a mechanism for users to request corrections and for those corrections to be processed in a reasonable timeframe. If you replicate data across systems (CRM, analytics, data warehouse), a correction must propagate across all of them.
7. Access — Subject Access Requests
Data subjects have the right to access a copy of all personal data you hold about them. Building a process to respond to Subject Access Requests (SARs) within 21 days is required. If your data is spread across five microservices and three third-party tools, responding to a SAR becomes an engineering problem, not just a process one.
The Practical Engineering Checklist
- Data inventory: Map every personal data field, its source, its storage location, who can access it, and its retention period.
- Consent logging: Immutable audit trail of consent events with timestamps and consent version.
- Encryption: AES-256 at rest, TLS 1.2+ in transit. Verify your cloud provider settings are actually enabled.
- RBAC audit: Remove access from everyone who doesn't need it. Log every access event to sensitive tables.
- Retention jobs: Automated scheduled jobs to delete or anonymise records past their retention window.
- SAR workflow: A documented and tested process to produce a full data export for any given user within 21 days.
- Processor DPAs: Signed agreements with every third-party data processor.
- Breach response plan: A tested procedure for notifying the PDPC within 72 hours of a discovered breach.
"PDPA compliance is not a legal project. It is an engineering project with legal consequences."
If your organisation needs help building a PDPA-compliant data architecture, our team has designed systems for healthcare networks, financial services companies, and government agencies across Malaysia. We're happy to share what works.
