Your customer data is sitting somewhere right now. Names, phone numbers, emails, maybe payment details. If someone gets in, the Personal Data Protection Department will ask hard questions. Customers will get angry. The average cost of a data breach in Malaysia is already around RM3.2 million. The legal fine is only part of it.
Most companies feel safe because they have a privacy policy and a security document. Those papers rarely get tested. The law does not care how good the documents look. It cares whether you actually protected the data.
PDPA compliance Malaysia got stricter after the 2024 amendments. The maximum fine is now RM1 million. You must also report a significant breach within 72 hours. Paper policies alone will not save you.
This checklist focuses on the gap between written rules and real protection, especially through Vulnerability Assessment and Penetration Testing.
The PDPA Security Principle: What the Law Explicitly Demands
The law says you must take practical steps to protect personal data from loss, misuse, modification, unauthorised or accidental access or disclosure, alteration or destruction. That standard of “practical steps” is where most companies get stuck. What feels enough internally can look careless to the Personal Data Protection Department or a court.
What counts as personal data
Anything that identifies or relates to a specific person, including:
- Email address
- Phone number
- Home or delivery address
- Purchase history linked to a customer
- Payment or bank details
- IP address
- Cookies that track behaviour
If it can point back to one person, it needs protection.
What reasonable security actually means
It is not a fixed list. Protection must match the risk:
- Payment data needs stronger controls than a basic email list
- Health or biometric data needs even tighter safeguards
- Leaving a known, actively exploited vulnerability unfixed is rarely considered reasonable
Regulators also look at what similar organisations were doing at the time. Written policies alone do not count.
Data processors (cloud providers, IT vendors, any third party handling the data) now carry direct legal duties. You cannot shift the responsibility to them.
If the measures fall short
A breach that shows weak security can lead to:
- Fines up to RM1 million
- Possible criminal liability
- Civil claims from customers
- Insurance pushback
Spending on proper testing now is almost always cheaper than dealing with the consequences later. The Security Principle is about showing real protection, not just paperwork.
The Malaysia PDPA Security Compliance Checklist for IT Leaders
Stop guessing. Use this checklist to see whether your customer data is actually protected.
Data Mapping & Inventory
You probably don’t actually know where all your customer data lives.
- It’s in your main database
- It’s in email backups
- It’s in development systems your team uses for testing
- It’s in cloud storage
- It’s on someone’s laptop who downloaded it for analysis
- It’s in your backup systems
- It’s in third-party vendor systems you use for analytics or marketing
Hackers don’t attack your main database. They attack the forgotten development system with weak security, the backup nobody’s monitoring, and the third-party vendor with terrible security.
What you need to do
Create a complete inventory of every system storing customer data.
Walk through your actual business processes:
- Where does data enter your company? (Website? Mobile app? Email? Partner integrations?)
- Document the entry point
- Follow the data
- Where does it get stored?
- Which systems hold it?
- Who can access it?
- How long do you keep it?
Example inventory
| Data Type | System | Who Can Access | How Protected | How Long Kept |
| Customer emails | Main database | 3 developers, 2 admins | Encrypted at rest, encrypted in transit | Until customer deletes account |
| Purchase history | Data warehouse | 5 analysts | Encrypted at rest, no encryption in transit | 3 years |
| Payment cards | Payment processor | 0 employees (external) | PCI DSS compliance | 30 days |
| Customer photos | Cloud storage (AWS S3) | 2 developers | No encryption | Indefinitely |
| Support emails | Email server | 10 support staff | Plain text | 5 years |
Now, check the Customer photos with no encryption stored indefinitely. That’s your vulnerability. That’s what hackers find.
Action items
- List every system holding customer data
- Verify encryption on each system
- Confirm access restrictions match job functions
- Check retention periods comply with PDPA
- Identify systems that shouldn’t exist (old development databases, forgotten backups)
Access Control & Privilege Management
The problem is usually simple and messy at the same time. Weak access control is one of the most common reasons organisations fail PDPA compliance Malaysia checks.
- Your finance manager left two years ago. Their account still has access to the customer database.
- Your junior developer got promoted but still carries the same junior permissions.
- Your new contractor got admin access because it was faster than figuring out exactly what they needed.
- Your ex-vendor still has database access because nobody remembered to remove them.
Hackers love this pattern. They target disgruntled ex-employees who still have access. They compromise a junior account and then escalate to admin rights that should never have existed.
Action items
- Audit every account that can reach customer data
- Verify each person still needs that level of access for their current job
- Remove access for terminated employees the same day they leave
- Strip admin rights from anyone who does not need them
- Expire contractor access the day the contract ends
- Make sure system accounts use strong unique passwords and are not shared
- Review permissions every quarter, not once a year
Secure API Endpoints
Your apps, website, payment system and third-party tools all talk to each other through APIs. Those same connections are one of the easiest ways customer data walks out the door.
In testing, we keep seeing the same problems:
- APIs that answer requests without checking who is asking
- Endpoints that return full customer records when the user should only see limited data
- No rate limits, so attackers can hammer the system nonstop
- Weak checks on incoming data
- Almost no logging, so no one notices when something goes wrong
Many teams assume that if the front end works, the API behind it must be fine. That assumption is where breaches often begin.
What needs checking
- Does the API demand proper authentication before it responds?
- Does it only return the data that person is allowed to see?
- Is the data encrypted while it moves?
- Are rate limits in place to stop abuse?
- Is every input being validated properly?
- Are requests logged so you can investigate later?
A common weak spot
An endpoint takes an email or customer ID and returns the full profile. No proper login check. No permission check. Someone writes a short script, runs through a list of emails, and walks away with thousands of records. Some companies only discover it months later.
Action items
- Test authentication on every API
- Confirm authorisation rules actually work
- Turn on rate limiting
- Add proper input validation
- Enable logging and monitoring
- Include APIs in your penetration tests
APIs usually get less attention than websites or mobile apps. That gap is where many breaches start.
Regular Infrastructure Hardening
Most breaches still start with basic, preventable weaknesses:
- Servers running outdated operating systems
- Network devices still using factory passwords
- Security patches left uninstalled for months
- Firewalls on default settings
- Logs that nobody reviews
Hardening means removing what you do not need, closing known holes, setting proper configurations, and watching for unusual activity. The work itself is straightforward. Doing it consistently is the hard part.
New patches appear every week for operating systems, databases, web servers, routers and applications. Fall behind and you leave known vulnerabilities open. Attackers already know how to exploit them.
What needs attention
- Apply critical security patches within 30 days
- Remove unused software and services
- Change every default password
- Configure firewalls to block anything not explicitly allowed
- Turn on logging across systems
- Review logs regularly, not only after an incident
Action items
- Set a clear patching schedule and follow it
- Disable unnecessary services
- Eliminate all default credentials
- Tighten firewall rules
- Enable logging on critical systems
- Check logs at least weekly
Infrastructure hardening is the work that stops many attacks before they start.
Independent Technical Verification
Your team can believe the systems are secure. That belief means little without proof.
Regulators, customers and courts want evidence, not confidence. The only reliable way to get it is to bring in qualified outsiders who try to break in the same way real attackers would.
What proper penetration testing does
- Attempts to gain access
- Tries to move through systems
- Targets customer data
- Tests privilege escalation
When testers succeed, you find the weaknesses early. When they fail, you have documented proof the controls held up.
Under the PDPA Security Principle, you must take practical steps to protect personal data. Independent testing is one of the strongest ways to show those measures are real. Organisations that cannot produce recent test results and proof of fixes usually sit in a weaker position during investigations or audits.
Action items
- Engage qualified penetration testers at least once a year
- Include every system that stores or processes customer data
- Keep clear records of findings and risk ratings
- Fix the issues discovered
- Retest to confirm the fixes worked
- Store the reports so they are ready if regulators ask
Internal reviews help. They are not a substitute for independent testing. Without outside verification, you are still operating on assumptions.
How VAPT Acts as the Ultimate Shield Against PDPA Data Breaches
Vulnerability Assessment and Penetration Testing (VAPT) is the practical way to check whether your security actually works. One part finds the weak spots. The other part tries to break in through them. Together they show what is theoretical and what is genuinely dangerous.
Automated scanners are useful but limited. They only catch problems that already exist in their databases. They miss new attack methods, business logic flaws, and creative ways of chaining small issues into real access. Human testers think the way attackers do. That difference is why many serious problems only appear during proper penetration testing.
What proper VAPT usually uncovers
- APIs that return far more data than they should
- Authentication that can be bypassed
- Privilege escalation paths that should not exist
- Business logic flaws that scanners never notice
- Misconfigurations that look harmless until someone abuses them
A common pattern looks like this. The scanner report comes back clean. Manual testers then find an endpoint that hands over large amounts of customer data without proper checks. The vulnerability was never in the scanner’s list, so it stayed invisible until someone actively tried to exploit it.
Typical VAPT process
| Phase | What happens | Why it matters |
| Reconnaissance | Testers gather information about systems and setup | Builds a realistic picture of the target |
| Scanning | Automated tools look for known weaknesses | Creates a baseline of obvious issues |
| Enumeration | Testers dig deeper into the systems manually | Finds what automation misses |
| Exploitation | Testers attempt real attacks | Proves which problems are actually usable |
| Reporting | Clear findings with practical fix advice | Gives you a prioritised action list |
| Retesting | Testers check the fixes | Confirms the problems are truly closed |
The retesting step is often the most valuable. Teams fix something, only to discover the fix was incomplete or introduced a new issue. Without retesting, you can easily believe a problem is solved when it is not.
For organisations handling personal data under the PDPA, VAPT provides concrete evidence that security measures go beyond written policies. It turns “we think we are secure” into something you can actually demonstrate.
Choosing a Qualified VAPT Partner to Secure Your Customer Data
Most organisations looking for a VAPT partner want three things:
- Testers who actually think like attackers, not just run scanners
- Clear reports that can stand up if a regulator or auditor asks questions
- Someone who will come back and retest after the fixes are done
Not every company delivers that. Pick the wrong one and you get a polished report that still leaves real gaps. That false sense of safety is often worse than knowing the problems exist.
Warning signs of weak testers
- They quote a fixed price before understanding your environment
- They promise to find a certain number of issues
- They rely almost entirely on automated scanners
- They struggle to explain how they actually test
- They also sell the remediation work (this creates a conflict of interest)
- They cannot give solid recent references
Signs you are dealing with a proper team
- They ask detailed questions about your systems and data flows before quoting
- They insist on proper scoping
- They combine automated tools with strong manual testing
- They can clearly explain their approach
- They only test and report. They do not try to sell you the fixes
- They can provide references from organisations that handle similar data
- They hold recognised credentials (CREST is good, but practical experience and other solid certifications also matter)
- Their reports are detailed enough to use as evidence if regulators ask questions
Questions worth asking before you hire anyone
- Will the testing cover every system that actually holds customer data, or just the public-facing ones?
- How much of the work is done by people versus automated tools?
- Can you give me recent references from companies roughly our size or in a similar industry?
- What happens when you find something serious during the test? How do you report it?
- Do you come back and retest after we fix the problems?
- What kind of report will we get, and is it useful if a regulator asks for evidence?
- How soon can you start, and how long does a proper test usually take?
A good VAPT partner should make you slightly uncomfortable during the test. That discomfort is the point. If the process feels too easy or too sales-driven, keep looking.
Qualysec is one firm that matches what most teams are looking for. They are CREST-accredited, focus on human-led testing supported by automation, and produce reports that organisations use as evidence for compliance work, including under the PDPA. If you want to see how their testing approach lines up with the checklist above, you can request a short scoping discussion with their team.
Conclusion & Strategic Roadmap
Customer data needs real protection. The PDPA compliance Malaysia makes it a legal duty. Fines and lost trust make it a business problem.
Do these things in order:
- Find every place customer data is stored
- Restrict access so only the right people can reach it
- Secure your APIs
- Harden your servers and systems
- Get independent penetration testing to check the controls actually work
Complete these steps properly and you cut the risk of becoming the next public breach. Start now. Your customers and your company both depend on it.
Frequently Asked Questions
1. What constitutes “Personal Data” under the Malaysia PDPA framework?
Anything that identifies or relates to a specific person. Names, emails, phone numbers, addresses, purchase history, payment details, IP addresses, cookies and health data all count.
2. Can an automated scanner satisfy the security mandates of a PDPA audit?
No. Scanners only catch known issues. Regulators expect real testing that includes manual checks. Automated tools alone are not enough.
3. What are the penalties for a company found negligent during a PDPA data breach in Malaysia?
Fines can reach RM1 million. Criminal charges are possible in serious cases. Customers can also sue and insurance may refuse to pay.
4. How frequently should an organization conduct VAPT to maintain PDPA readiness?
At least once a year. Add extra tests after big system changes or security incidents. Waiting longer than a year is risky.
5. Does having a clear privacy policy protect a company if a technical hack occurs?
No. A privacy policy only explains how you handle data. It does not stop hackers. You still need strong technical security.
