← Back to blog

Data Security Basics Every Malaysian Business Owner Should Know

Why security matters more now

Malaysian businesses are collecting more customer data than ever — names, ICs, payment details, health records, location data. The Personal Data Protection Act (PDPA) 2010 creates legal obligations around how that data is handled. And cyber incidents that would have been buried five years ago now make the news.

This isn't a reason to panic. But it is a reason to understand the basics — especially if you're responsible for software that handles customer data.

PDPA: what you actually need to know

The PDPA applies to any organisation that processes personal data in the course of commercial transactions. If you collect customer information through your software — even just names and email addresses — the PDPA applies to you.

The key obligations:

Consent. You need explicit consent to collect personal data, and you must tell people what you're collecting it for. Burying this in a 50-page terms document doesn't count.

Purpose limitation. You can only use data for the purpose it was collected. Customer emails collected for order confirmations can't be used for marketing without separate consent.

Data security. You must take "practical steps" to protect personal data from loss, misuse, modification, or disclosure. The Act doesn't specify exactly what these steps are — which means you need to use judgement, and document it.

Retention. You can't keep personal data longer than necessary for the purpose it was collected.

Non-compliance penalties can reach RM500,000 and/or three years imprisonment. More practically, a data breach that becomes public is expensive in customer trust, which is harder to rebuild than paying a fine.

The five vulnerabilities we find most often

When we inherit an existing codebase — taking over maintenance from another vendor or building on top of an existing system — we almost always find the same categories of problems.

1. Exposed API keys in source code
Credentials committed to a Git repository, sometimes years ago. Even if the repo is private, this is a significant risk. Rotate any keys that have ever been in version control, and use environment variables going forward.

2. No rate limiting on authentication endpoints
A login endpoint with no rate limiting can be brute-forced. An OTP endpoint with no rate limiting can be used to burn through SMS credits and lock users out. These are simple fixes that are frequently missed.

3. Missing authorisation checks
Authentication (are you logged in?) and authorisation (are you allowed to do this specific thing?) are different. We regularly find systems that authenticate users correctly but don't check whether the authenticated user has permission to access specific records. User A can see User B's data just by changing an ID in the URL.

4. Unvalidated user input
SQL injection is a 25-year-old problem and we still find it. Any input that reaches a database query, file system, or shell command needs to be validated and sanitised. Using parameterised queries and an ORM prevents most of this class of problem.

5. Outdated dependencies with known vulnerabilities
npm audit or composer audit will tell you immediately if your dependencies have published security vulnerabilities. Running this takes 10 seconds. Not running it is how you end up exposed to vulnerabilities that have had patches available for two years.

Practical starting points

You don't need to solve everything at once. If you do nothing else this quarter, do these three things:

1. Run a dependency audit and update anything with a high-severity vulnerability
2. Verify that your API checks authorisation, not just authentication, on every endpoint that returns user-specific data
3. Make sure you have a process for rotating credentials if they are ever exposed

Security is not a project you complete — it's a practice you maintain. But starting with these three things puts you ahead of the majority of Malaysian SMEs we encounter.