Almost every Malaysian SME we audit has a privacy policy page. Far fewer can answer the question that actually matters when something goes wrong: who opened this customer's record last Tuesday, and can you prove it?
That gap is what this page is about. ZenWeb builds and inherits business systems every month, and the paperwork side of PDPA is usually the easy part. The PDPA compliance checklist and the privacy policy your website needs get sorted in an afternoon. The database, the logins and the logs are where the real exposure lives, and they take a bit longer.
The video below covers the Act itself in plain terms. After it, we go through what PDPA security for web systems actually looks like in code and configuration, and what it costs a small business to get there.
Malaysia's Personal Data Protection Act (PDPA): What Your Business Should Know
Source video: Clym on YouTube
1. What the Law Asks of the System, Not the Page
Quick Answer: PDPA's Security Principle asks you to take practical steps to stop personal data being lost, misused, altered or accessed without permission. Nothing in it mentions a privacy policy page. It is a statement about how your database, your logins and your backups are configured.
The Personal Data Protection Commissioner publishes minimum requirements covering security, storage and integrity, and they apply to electronic and paper records alike. The Personal Data Protection Standard 2015 sets out three of them, per the Commissioner. Security measures while data is being processed, permanent deletion once it is no longer needed, and keeping records accurate and current. Every one of those lands on your web development build rather than on your legal wording.
What changed recently is enforcement. The amended Act brought in a named Data Protection Officer and mandatory breach reporting, and it extended obligations to data processors — which now includes the people hosting and maintaining your system, not just you.
- Security is a system property. Encryption, access control and logging are settings someone must turn on, not clauses someone can write.
- Deletion is a feature. If nobody can remove a customer record without calling a developer, you cannot meet a deletion request on time.
- Your vendors are in scope. Hosting, CRM and payment providers all touch the data, so their configuration is part of yours.
- Paper counts too. Scanned ICs sitting in a shared drive are the same exposure as a database, usually worse protected.
Key takeaway: Treat PDPA as a build requirement with a legal deadline attached, not as a document to publish. The page you write matters far less than the settings behind it.
2. Encryption: In Transit, At Rest, and the Fields Everyone Forgets
Quick Answer: Encryption in transit is solved by HTTPS everywhere and takes an hour. Encryption at rest is where SMEs stop, because it means picking which columns actually need protecting: IC numbers, phone numbers, addresses, uploaded documents and anything a fraudster could use on its own.
Start with the free part: every page, form and API endpoint served over HTTPS, with old versions of the protocol switched off. Those are the basics behind SSL and HTTPS, and the reason a Not Secure warning is a compliance problem rather than only a trust problem.
At rest is the harder call. Encrypting an entire database sounds thorough but protects you mainly against someone stealing the physical disk, which is rarely how a Malaysian SME loses data. Column-level encryption on the fields that identify a person is the practical version.
- Encrypt identity fields. IC and passport numbers, dates of birth, full addresses, and any bank or card reference your system stores.
- Hash, do not encrypt, passwords. Modern hashing with a per-user salt. If your system can email a customer their existing password, it is storing it wrongly.
- Protect uploads. Scanned documents are usually sitting in a public folder with a guessable filename. Move them behind a login and serve them through code.
- Encrypt backups too. A protected database with plain-text nightly dumps in cloud storage is a solved problem pointing at an unsolved one — see setting up a proper backup and restore plan.
- Keep keys out of the code. Encryption keys in the same repository as the application protect nobody once that repository is copied.
Key takeaway: Encrypt the columns that identify a human being and the backups those columns end up in. Full-disk encryption alone tends to be effort spent on the least likely scenario.
Not sure what your system is actually storing?
Most SMEs are surprised by the answer. We map every table and upload folder that holds personal data before recommending a single change.
See how ZenWeb scopes a web development project →3. Access Control and Audit Logs: Who Opened That Record
Quick Answer: Shared admin logins are the single most common PDPA failure in Malaysian SME systems. Without one account per person you cannot limit what staff see, cannot remove access when they leave, and cannot tell the Commissioner who accessed a record during a breach.
PDPA security for web systems is won or lost here, because this is what decides whether a breach investigation takes an afternoon or a fortnight. Below is what we find on first inspection of a custom web application that has been running for a few years without a security review.
| Gap found | Systems affected | Share | Developer days to fix |
|---|---|---|---|
| One admin login shared by two or more staff | 61% | 2 | |
| No record of who viewed a customer record | 57% | 4 | |
| Accounts of former staff still active | 44% | 1 | |
| Live customer data copied into a test environment | 38% | 3 | |
| Database credentials sitting in the codebase | 29% | 1 |
Source: ZenWeb client sample, first security reviews of Malaysian SME web systems, 2024–2026. Licence.
Read the last column. The two worst gaps cost roughly a day each to close, which is the frustrating part — these are cheap fixes that nobody owns. Audit logging costs more because it has to record reads, not only writes, and most frameworks log neither by default. The same discipline shows up in WordPress website security work and in any accounting system integration, where an API key quietly becomes a second front door.
Key takeaway: One person, one login, and a log that records reads. Without those two things, every other control you buy is unprovable when the Commissioner asks.
4. Consent and Retention Belong in the Database
Quick Answer: Consent you cannot produce is consent you do not have. Every record needs the purpose the customer agreed to, the timestamp, and the wording shown at the time — stored as columns, not implied by the fact that a tick box existed on the form.
Most systems record the outcome and throw away the evidence. A ticked box updates a flag, the form wording changes six months later, and now nothing links the customer to what they actually agreed to. That is a different problem from the cookie banner question and from consent mode in GA4, both of which govern tracking rather than the records your business keeps.
| Data the system holds | Consent timestamped | Retention period set | Staff can delete unaided |
|---|---|---|---|
| Newsletter and marketing list | 67% | 29% | 55% |
| Order and payment records | 58% | 63% | 24% |
| Customer accounts and portal logins | 46% | 35% | 41% |
| Website enquiry form submissions | 31% | 22% | 27% |
| Uploaded documents such as IC copies | 22% | 14% | 12% |
Source: ZenWeb client sample, Malaysian SME web systems reviewed for personal data handling, 2024–2026. Licence.
The bottom row is the worst-handled data in the sample and also the most sensitive. Uploaded IC copies and licences are collected once, needed for a week, and kept forever because no rule ever told the system to remove them. Set a retention period per data type, run the deletion as a scheduled job, and log what it removed — the same operational habit that keeps a customer portal tidy as it grows.
Key takeaway: Give every table a retention rule and a delete route your own staff can use. Data you no longer hold cannot be breached, requested, or argued about.
5. The 72-Hour Breach Playbook
Quick Answer: If a breach is likely to cause significant harm, the Commissioner must be notified within 72 hours, and affected customers within seven days of that notification. Three days sounds generous until you realise most SMEs take longer than that just to notice.
The requirement comes from the Commissioner's guidelines on data breach notification, with reports filed through the Department's own breach reporting channel. Failing to notify is an offence carrying a fine of up to RM250,000, imprisonment of up to two years, or both, under the Personal Data Protection (Amendment) Act 2024. Write the playbook now, while nobody is panicking.
- Contain it first. Rotate credentials and API keys, revoke sessions, and take the affected component offline if you must. Fixing comes after stopping.
- Preserve the evidence. Copy server, database and application logs somewhere read-only before anyone starts repairing, or you will lose the timeline you need to report.
- Scope the damage. Which tables, which fields, how many people, and was any of it sensitive. Your audit log is what makes this answerable in hours.
- Notify the Commissioner within 72 hours. Submit what you know, with what you have not yet established stated plainly. A partial report on time beats a complete one late.
- Tell affected customers within seven days. Plain language: what happened, what data, what you have done, what they should do now.
| How the incident was found | Hours to detect | Hours to report | Inside 72 hours |
|---|---|---|---|
| Automated alert from logs or monitoring | 4 | 11 | 96% |
| Staff noticed something wrong | 38 | 19 | 61% |
| Hosting or software provider raised it | 74 | 26 | 27% |
| A customer complained | 96 | 22 | 18% |
| Found later during a scheduled audit | 210 | 31 | 9% |
Source: ZenWeb client sample, security incidents handled on Malaysian SME web systems, 2024–2026. Licence.
Detection, not paperwork, is what decides compliance here. Businesses with alerting almost always report in time; businesses that wait for a complaint almost never do. That is why a hacked site cleanup so often turns into a reporting problem as well as a technical one, and why recovering rankings afterwards is the smaller of the two headaches.
Key takeaway: The 72 hours are mostly spent before you know. Spend your budget on detection and alerting, because reporting is fast once someone has actually noticed.
No breach plan written down yet?
We draft the playbook against your actual system — who rotates which key, where the logs live, who files the report.
Compare web app maintenance and SLA plans →6. Do You Need a DPO, and What Will They Ask For?
Quick Answer: Most small businesses fall under the thresholds and do not need a registered Data Protection Officer. Plenty still appoint someone internally, because the useful part is having one named person who owns the answers rather than the title itself.
The Commissioner's guidelines on appointing a Data Protection Officer put the trigger at three situations. Processing the personal data of more than 20,000 data subjects, processing sensitive or financial data on more than 10,000, or any activity that requires regular and systematic monitoring. Where the duty applies, the appointment is registered with the Commissioner and the contact details must be easy for the public to find.
Whether or not you cross the line, the questions a DPO would ask are the ones worth answering. Keep the answers in one short document your developer maintains alongside the code.
- What do we hold, and where? Every table, upload folder and third-party tool holding personal data, listed once and kept current.
- Who can see it? A role list, with a name against each role and a date each account was last reviewed.
- How long do we keep it? A retention period per data type, with the job that enforces it.
- Where does it leave the country? Analytics, email and cloud storage often move data offshore, which is its own set of rules — the practical concern behind feeding customer data into AI tools.
- Who is called first? One named person, one backup, and their phone numbers on the wall.
Key takeaway: Check the thresholds honestly, then appoint an internal owner regardless. Compliance fails far more often through nobody owning it than through anybody deciding wrongly.
7. Patching and Penetration Testing: How Often Is Enough
Quick Answer: For a typical SME system, patch security updates within seven days, run automated vulnerability scanning monthly, and commission a proper penetration test once a year or after any major change. Quarterly testing is for systems holding payment or health data.
Cadence beats intensity. A yearly test on a system nobody patches finds the same issues twice. The table below tracks how these habits have spread across Malaysian SME systems we manage, including the sharp move on named data owners once the June 2025 rules landed.
| Practice in place | 2022 | 2023 | 2024 | 2025 | 2026 | 2027* |
|---|---|---|---|---|---|---|
| Security patches applied within 7 days | 21% | 26% | 33% | 41% | 49% | 55% |
| Audit logging switched on | 17% | 22% | 29% | 38% | 47% | 54% |
| Named data protection owner in place | 3% | 5% | 9% | 24% | 38% | 46% |
| Annual penetration test commissioned | 8% | 10% | 14% | 19% | 26% | 32% |
Source: ZenWeb client sample, Malaysian SME web systems under management, 2022–2026; 2027 projected. Licence.
* Projection based on the 2022–2026 trend in this sample.
Penetration testing stays the least adopted line because it is the only one with a real invoice attached. Patching and logging are mostly discipline, which is why they belong in a maintenance agreement rather than a project budget. That is the argument we make in website maintenance in Malaysia, and the same reason where your hosting sits is worth deciding deliberately.
Key takeaway: Buy the cheap habits first. Seven-day patching and switched-on logging cover far more risk per ringgit than an annual test on an unmaintained system.
Nobody owns patching in your business?
Put it in writing with whoever maintains the system, so updates and log reviews happen on a schedule instead of after an incident.
See how ZenWeb supports custom web applications →8. Building It In Rather Than Bolting It On
Quick Answer: Adding roles, audit logs and retention rules to a live system costs roughly three times what it costs during the build. The Commissioner's own guidance points the same way: design the protection in, rather than retrofitting it after launch.
That principle has a name in the guidance. The Data Protection by Design guideline asks organisations to build safeguards into a system from the start. In practice it means four decisions during scoping, none of which slow a project down.
- Collect less. Every field on a form is a liability for as long as you hold it. Drop the ones nobody reads.
- Define roles before screens. Decide who sees what while the requirements are still on paper, not after the interface exists.
- Log from day one. Adding read-logging to a finished application means touching every query; adding it at the start costs almost nothing.
- Check the integrations. Anything that syncs customer data outward — payment, delivery, accounting, marketing — needs the same treatment as your own database, including a payment gateway integration that must never store card data itself.
If you are choosing platforms, PDPA security for web systems belongs in that comparison too. You might go with a headless CMS or standard WordPress, or ship a progressive web app rather than a native app. Either way the personal data lands in one database that somebody has to secure.
Key takeaway: Put roles, logging and retention in the requirements document. They are close to free before the build starts and genuinely expensive afterwards.
9. Getting This Right Without Over-Engineering
Quick Answer: A small business does not need a security operations centre. It needs individual logins, encrypted identity fields, read logging, retention rules that actually run, alerting, and a written breach plan. That list is a few days of work, not a project.
The businesses that get caught out are rarely the ones that decided wrongly. They are the ones where nobody decided at all, and the shared login from 2019 is still in a WhatsApp group. Start with the two cheapest items in section three, then work down.
ZenWeb handles this inside our web development service, on new builds and on systems we inherit from somebody else. Usually the honest answer is a week of unglamorous work — accounts split, logs enabled, retention jobs written, a plan printed and pinned up. Do that, and PDPA security for web systems stops being a worry you carry around and becomes something you can demonstrate on a Tuesday afternoon.
Not sure whether your system would survive a PDPA question?
Book a free 30-minute session. We'll walk through what your system stores, who can reach it, what gets logged and how quickly you could report a breach — then tell you plainly which gaps are worth fixing first and what each one costs.
Get my free PDPA system review →
10. Frequently Asked Questions
1. Does a small business really have to report a data breach?
Yes, where the breach causes or is likely to cause significant harm to anyone affected. Size is not the test. The Commissioner must be notified within 72 hours, and the customers involved within seven days of that notification.
2. Is HTTPS enough to satisfy PDPA?
No. HTTPS protects data moving between the browser and your server, which is one risk out of several. It does nothing about shared logins, missing audit logs, unencrypted uploads or records kept years past their usefulness.
3. Do we need to encrypt the whole database?
Rarely. Encrypting the columns that identify a person, protecting uploaded documents and encrypting your backups covers most realistic scenarios for an SME. Full-disk encryption mainly helps if someone walks off with the physical hardware.
4. How much does PDPA security work cost for a typical SME system?
Closing the common gaps usually runs to five to ten developer days on an existing system, and close to nothing if the same controls go into a new build from the start. Ongoing patching and logging normally sit inside a maintenance retainer.
