Most Malaysian businesses discover their web security gaps after something goes wrong — a defaced website, a data breach notice, or a failed compliance audit. This checklist exists so you can find those gaps before an attacker does.
Web security is not a one-time configuration. It is an ongoing discipline that spans your hosting environment, your application code, your access management practices, and your incident response readiness. In working with Malaysian SMEs and corporate clients over the years, I have seen the same gaps appear repeatedly — SSL misconfigurations, forgotten admin accounts, systems running on three-year-old software versions, and no backup plan that has ever actually been tested.
The National Cyber Security Agency of Malaysia (NACSA) reported a steady increase in cybersecurity incidents affecting Malaysian organisations, with web defacement, phishing, and ransomware among the most common. These are not sophisticated zero-day attacks targeting large enterprises. Most of them exploit basic configuration failures that this checklist directly addresses.
Work through each section. Assign a status — done, in progress, or not started — and use it as the foundation for your next security review cycle.
1. SSL/TLS Configuration
Every business website and web application must operate over HTTPS with a valid SSL certificate. This is no longer optional — browsers flag HTTP sites as insecure, and Google treats HTTPS as a ranking signal. But having a certificate is only the starting point.
- SSL certificate is valid and not expired
- Certificate covers all subdomains in use (wildcard or multi-domain certificate where needed)
- TLS 1.2 is minimum; TLS 1.3 is preferred
- Older protocols (TLS 1.0, SSL 3.0) are disabled at the server level
- HTTP requests are redirected to HTTPS via server configuration or
.htaccess - HSTS (HTTP Strict Transport Security) header is configured
RSA key size and cipher suite selection also matter — particularly if your business has received a penetration test report flagging weak cryptography. For a technical walkthrough of what affects browser compatibility and security rating, refer to our article on SSL RSA key size and browser compatibility.
2. Software Patching and Version Management
Unpatched software is the single most exploited attack surface in Malaysian SME web environments. Content management systems, plugins, server packages, and PHP versions all require regular updates — not just when something breaks, but on a scheduled cadence.
- CMS (WordPress, Joomla, or custom framework) is on a supported, up-to-date version
- All plugins and extensions are updated and actively maintained by their developers
- Abandoned plugins (no updates in 12+ months) are removed or replaced
- PHP version is current and supported (PHP 7.4 and below are end-of-life)
- Web server software (Apache, Nginx) is on a current stable release
- Database engine (MySQL, MariaDB) is patched and on a supported version
- A patch management schedule exists — updates are not left to chance
3. Access Control and Authentication
Compromised credentials remain one of the leading causes of web application breaches. Weak passwords, shared accounts, and unchecked admin access create unnecessary exposure at every level.
- All admin and backend accounts use strong, unique passwords (minimum 12 characters, mixed characters)
- Multi-factor authentication (MFA) is enabled for all admin access — hosting, CMS, server panels, cloud consoles
- Default admin usernames (admin, administrator, root) have been changed or disabled
- Access follows the principle of least privilege — users only have the permissions they need
- Former employee accounts are deactivated immediately upon departure
- A user access review is conducted at least every six months
- FTP access is disabled or restricted; SFTP is used instead
- SSH root login is disabled; key-based authentication is used
4. Web Application Security
If your business runs a custom web application — a customer portal, quotation system, inventory platform, or internal workflow tool — application-level security requires specific attention beyond what a standard hosting setup provides.
- All user inputs are validated and sanitised server-side (not client-side only)
- Parameterised queries or prepared statements are used — not string-concatenated SQL
- Output encoding is applied wherever user-generated content is displayed (XSS prevention)
- File upload functionality restricts file types and scans for malicious content
- Error messages do not expose stack traces, database names, or file paths to end users
- Security headers are configured: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options
- Session tokens are regenerated on login and invalidated on logout
- API endpoints require authentication and enforce rate limiting
- Admin and internal areas are IP-restricted where operationally feasible
For businesses that have received formal penetration test reports but have not completed remediation, every unresolved finding on that report is a known vulnerability in a documented location. If your last pen test report is sitting in a folder unactioned, that is a higher risk than never having tested at all — because the findings are now discoverable. Our guide to acting on penetration test findings walks through how to prioritise and resolve these systematically.
5. Backup and Recovery
A backup that has never been tested is not a backup — it is a false sense of security. Ransomware incidents and server failures in Malaysia frequently expose businesses that assumed backups were running but had never verified a successful restore.
- Automated backups run on a defined schedule (daily for active applications)
- Backups are stored off-server — not on the same hosting environment as the live site
- At least one backup copy is stored in a geographically separate location or cloud storage
- Backup retention policy is defined (how many versions, how long they are kept)
- A restore test has been completed within the last six months — and documented
- Recovery time objective (RTO) is known: how long does a full restore take?
- Database backups are separate from file backups and tested independently
6. Monitoring and Logging
You cannot respond to what you cannot see. Many Malaysian businesses have no visibility into what is happening on their web systems until something visibly breaks — by which point an attacker may have been present for days or weeks.
- Server access logs and error logs are retained and reviewed periodically
- Failed login attempts are logged and trigger alerts above a threshold
- Uptime monitoring is active — you are notified if the site goes offline
- File integrity monitoring alerts on unexpected changes to core application files
- A web application firewall (WAF) is in place and actively filtering traffic
- Malware scanning runs on a scheduled basis
7. Penetration Testing
A checklist helps identify gaps in configuration and process. A penetration test is a scoped assessment of how an application responds to realistic attack techniques. The appropriate mix depends on your system and risk.
For systems that handle sensitive data or important transactions, discuss testing scope and frequency with your security team or appointed assessor. Any regulatory obligation should be checked against the rules that apply to your organisation.
- Assessment frequency reflects system risk and applicable requirements
- Scope covered both external-facing and internal interfaces
- All critical and high findings from the last report have been resolved
- A retest was conducted to verify remediation
- The next assessment is planned according to risk and applicable requirements
If your internal security team or appointed assessor has identified web application findings, our security remediation support helps implement fixes and record changes for their verification.
8. Incident Response Readiness
Security incidents happen — even to well-maintained systems. The difference between a contained incident and a prolonged breach often comes down to whether the response is planned or improvised.
- An incident response plan exists and is documented
- Key contacts are listed: hosting provider, development team, management escalation
- Staff know who to contact and what to do if a breach is suspected
- The process for taking a compromised site offline quickly is known
- NACSA or relevant authorities are listed as notification contacts for serious incidents
Turning This Checklist Into an Action Plan
A complete checklist review typically takes a half day for a technically competent internal team. What it produces is a prioritised gap list — grouped by severity and effort — that becomes the basis for a remediation plan.
In my experience, most Malaysian businesses completing this checklist for the first time will find gaps in three areas: patch management (because it was never formalised), backup verification (because no one tested the restore), and access control (because former employees or default credentials were never cleaned up). These areas are worth reviewing early because gaps can remain unnoticed during routine operations.
The businesses that manage web security well do not have larger budgets or dedicated security teams. They have consistent habits — quarterly reviews, immediate patching cycles, tested backups, and scheduled pen tests. The website security and maintenance service we operate for clients is built around exactly this rhythm, so that security becomes a managed process rather than a reaction to a crisis.
Want Help Running Through This Checklist?
If you have identified gaps and need help prioritising remediation, or if your business is preparing for a formal penetration test, discuss your situation with us.
Request a Security Discussion ->Frequently Asked Questions
What are the most critical web security risks for Malaysian businesses?
Common risks include unpatched software, weak authentication, misconfigured transport security, untested backups and limited security review of important application changes.
How often should a Malaysian business conduct a web security review?
Set a review cadence based on the system, its risks, major changes and any applicable requirements. Arrange testing with a qualified assessor where appropriate.
Is penetration testing required for Malaysian businesses?
Testing requirements vary by sector, system and contract. Ask your compliance team or qualified adviser which obligations apply, and appoint a security assessor when testing is needed.
What is the difference between a security audit and a penetration test?
A security audit reviews your systems, configurations, and policies against a checklist or standard to identify gaps. A penetration test goes further — a tester actively attempts to exploit vulnerabilities the way a real attacker would. Both serve different purposes: audits identify what is misconfigured, pen tests confirm what is actually exploitable.