Website security checklist title card with a flat illustration of a browser window whose heading and hero area are fully drawn while the three blocks below them and a wide band at the foot are only empty dashed outlines, one small scarlet button beside them

A website does not become less safe by being changed. It becomes less safe by sitting still while everything around it moves: new flaws published against plugins that were already installed, a certificate rule that changed in March, a breach law that took effect last year and gives you three days rather than three weeks. The website security checklist below is the once-a-year version of that review, and most of it has nothing to do with clicking Update.

Start by getting the threat right, because the wrong picture of it leads to the wrong spending. Almost nothing that reaches a small business site was aimed at that business, which is why company size has never had much to do with who gets hit.

What actually breaks into a small business website?

Not a person sitting in front of your homepage. What a small site sees is scanning: software that already knows which plugin versions carry a published flaw, requesting the exact paths that would prove one is present, across thousands of sites an hour. The answer it is looking for is a version number.

That changes how much time you have. Patchstack’s State of WordPress Security in 2026 measured the gap between a flaw becoming public and being attacked, weighted by how heavily each one was actually exploited: the weighted median time to first exploit is 5 hours, and approximately half of high-impact vulnerabilities are exploited within 24 hours. A patch released on Tuesday and applied at the end of the month was not applied late. It was applied in a different era.

The second finding takes away the answer most owners give. Patchstack tested what hosting-level protection actually stops and reported that traditional defences only blocked 12% of WordPress-specific vulnerability attacks; across a broader set that included generic attacks, only 26% of total attacks were blocked. A firewall is worth having and not worth relying on, and “our host handles security” is a sentence with a number attached to it.

The industry’s own risk list has shifted the same way. The OWASP Top 10 was rewritten in 2025, and the categories that moved are the ones an assembled website is made of: Security Misconfiguration moved up from #5 in 2021 to #2 in 2025, and Software Supply Chain Failures arrived as a new entry at number three. One is a setting nobody revisited; the other is code written by somebody you have never met and installed in one click.

Nobody chose your website. Something scanned it, and the only question it asked was which version you are running.

A labelled diagram headed HOW FAST A KNOWN FLAW IS USED with a vertical timeline marked Flaw published at the top, a scarlet marker at 5 hours captioned Median first exploit, and a marker at 24 hours captioned About half already exploited
A wide labelled diagram headed WHAT HOSTING DEFENCES BLOCKED with two long horizontal tracks, the upper one filled about a quarter of the way and marked 26% blocked above the caption All attacks tested, and the lower one filled a much shorter scarlet portion marked 12% blocked above the caption WordPress-specific attacks

A website security checklist you can finish in an afternoon

Three things on this list can be checked from the front of the site. The rest live in the admin area and on the server, where nothing looks wrong to a visitor and nothing looks wrong to you either, because absence does not announce itself.

  • Every plugin and theme, including the ones switched off. A deactivated plugin is still files on the server and can still be reachable. List what is installed, when each was last updated by its developer, and whether the licence on a paid component has lapsed — that usually means the updates stopped arriving, not that the plugin stopped working. Anything nobody can name a use for gets deleted, not deactivated.
  • The software underneath. WordPress core, the PHP version in your hosting panel, the database. These are the layers postponed because changing them can break a page, and postponing them is how a site ends up years behind. The versions and their end-of-support dates are covered in our piece on when a website becomes expensive to maintain; the check here is whether anyone has looked this year.
  • Who still has an administrator account. Open the user list and read it as people, not usernames. The freelancer from the 2023 build, the intern, the agency that stopped invoicing, the account called admin nobody created. Each is a way in that needs no vulnerability at all.
  • How those people sign in. One reused password on an administrator account undoes the rest of this list. Two-factor authentication on every administrator is the highest-value hour most sites can spend, and it costs nothing.
  • Whether a backup actually restores. Nearly every site has backups. Far fewer have one somebody has restored, kept somewhere other than the server it is backing up, and taken often enough that losing everything since would be tolerable. An untested backup is a belief, not a plan.
  • Where the alarm would go. If the site were defaced tonight, who finds out, and how? Search Console verified and its emails reaching somebody who reads them, uptime monitoring, and a named person allowed to take the site offline without calling a meeting. Most of the damage happens in the days before anyone notices.

None of that replaces upkeep between reviews: what a real maintenance plan covers is the month-to-month version of the same discipline. The annual check exists to catch what a monthly routine never looks at.

A labelled square diagram headed WHERE THE CHECKS ACTUALLY LIVE, split by a vertical dashed rule into a left column headed What a visitor can see listing HTTPS certificate, Login page and Contact forms, and a scarlet-headed right column reading What only you can see listing Plugin and theme versions, Administrator accounts, Backups that restore and Where the alert goes

Two rules that changed this year

Both of these are dated, both apply to ordinary business websites in Malaysia, and neither shows up in any plugin’s update screen.

Certificates got shorter. Until March the maximum life of a public TLS certificate — the thing behind the padlock — was 398 days, which fitted a yearly renewal reminder. From 15 March 2026 the maximum is 200 days, falling to 100 days in March 2027 and 47 days in March 2029. If somebody renews the certificate by hand once a year, that routine has already stopped matching reality, and an expired certificate is the one security failure every visitor sees, in a full-page browser warning. The check is not the expiry date. It is whether renewal is automated at all.

Breaches acquired a clock. Since 1 June 2025, section 12B of the Personal Data Protection Act requires notification to the Commissioner within 72 hours of a personal data breach, with affected individuals told no later than seven days after that where the breach is likely to cause significant harm; failure to comply carries a fine of up to RM250,000, up to two years’ imprisonment, or both. The Department of Personal Data Protection publishes the data breach notification guidelines in full. The consequence for a website owner is unglamorous: you cannot answer a 72-hour question without server logs, a record of who had access, and a named person who knows the call is theirs.

A contact form that stores enquiries in the WordPress database is holding personal data, as is an order table, a newsletter list or a CV upload folder. That is most business websites.

What if it has already happened?

The signs are rarely dramatic: pages you did not write appearing in a search for your own brand, visitors redirected but only on a phone, a run of 404s for URLs in a language you do not publish in. Google often notices before your customers do — pages or sites affected by a security issue can appear with a warning label in search results or an interstitial warning page — and the Security Issues report in Search Console explains what it found. If you find something, the order matters more than the speed.

  • Copy before you clean. Snapshot the files, the database and the server logs before anything is deleted. It is the only evidence of what was reached and when, and the 72-hour question cannot be answered without it.
  • Change the keys, not just the passwords. Every administrator password, the database password, hosting and FTP credentials, and the WordPress security salts. A password change alone leaves an active session untouched.
  • Restore from before the first sign, then update. Deleting the spam pages you can see removes the symptom and leaves whatever created them. Restore a backup taken before the earliest evidence, update everything on the restored copy, and only then put it back in front of the public.
  • Find the way in before you reopen. An out-of-date plugin, a reused password, a form that accepted any file. If that is not identified the same thing happens again within weeks, usually worse, because a backdoor was left behind.
  • Ask for the review last. Request a review in Search Console once the site is genuinely clean. Asking early and failing costs days, and the warning stays up for all of them.

Frequently asked questions

Does HTTPS mean my website is safe?

No. The padlock says the connection between visitor and server is encrypted, which stops somebody on the same public wifi reading what is typed into your contact form. It says nothing about the software on the server, who holds an administrator account, or whether a plugin with a published flaw is installed. A compromised website keeps its padlock.

Is a security plugin enough on its own?

It helps, and it does not replace updating. A blocking tool has to recognise an attack to stop it; an applied patch removes the weakness the attack is aiming at. Use one for the visibility it gives you — login attempts, file changes, malware scans — and treat its alerts as something a person reads.

Do we have to report every security incident to the Commissioner?

Not every incident, but the threshold is lower than most people assume. The obligation is triggered when a data controller has reason to believe a personal data breach has occurred, and affected individuals must be told as well where it is likely to cause significant harm. Decide in advance who makes that judgement and where the logs they would need are kept.

Where iRevamps fits

Most of the insecure sites we are shown are not neglected. They are sites that were built well, handed over, and then left in the care of nobody in particular. Our website development and maintenance service starts with the review above, written up as a list of what is exposed, what it would take to close, and what can honestly be left. If you have read this far and cannot say who holds the administrator accounts on your site, that is the place to begin.