A website security checklist you can verify yourself

The request usually arrives after a scare. Someone in the group chat had their site defaced, or an invoice email turned out to be fake, and now there is a question: is our website safe. The honest answer is that nobody can tell you from the outside, and that most of what gets published as a security checklist is a list of things a developer does, not a list of things you can verify.

So this is the shorter version. Seven checks you can carry out yourself, without shell access and without taking anyone's word for it, and an honest note about the parts that genuinely need someone technical. The point of verifying it yourself is not distrust. It is that a check nobody performs is indistinguishable from a check that failed.

Start with what is already being broken into

There is a free, public list of the vulnerabilities that are actually being exploited, as opposed to the ones that theoretically could be. The US Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities catalog, which it describes as "the authoritative source of vulnerabilities that have been exploited in the wild", and it advises that organisations "should use the KEV catalog as an input to their vulnerability management prioritization framework".

It held 1,760 entries when this was written, and the recent additions explain why it belongs in a business owner's checklist rather than only an engineer's. On 27 October 2026 the catalog added an Adobe Commerce and Magento flaw, CVE-2026-48356, with a remediation date of 10 November. The day before, two PHP flaws were added, CVE-2026-109619 and CVE-2026-109618, with a due date of 29 October, a three day window.

Magento is a shop. PHP runs underneath a large share of the web including WordPress. Neither of those is an exotic target, and the short due dates are the useful signal: when something is being exploited now, the window to patch is measured in days. That is the whole argument for the first check below.

The seven checks, and how you confirm each one

Each of these is verifiable by you. Where the answer is a screenshot or a date rather than a yes, ask for the screenshot or the date.

• Updates were applied this month. Ask for the date of the last platform and plugin update. A date, not an assurance. If nobody can name one, that is the finding.
• A backup exists and has been restored. The check is the restore, not the backup. Ask when a backup was last restored somewhere and what was found missing.
• Every account that can publish or install has two factor authentication. That means the CMS, the hosting panel, the domain registrar and the email account tied to them.
• Nobody still has access who left. Open the user list and read it. Ex staff, an old agency, a developer from two rebuilds ago.
• HTTPS is on and the certificate renews itself. A padlock today proves nothing about March. Ask whether renewal is automatic.
• The admin login is not on the obvious address with the obvious name. An account called admin is half of a guessed password.
• Someone would notice the site being down. Not a person checking, a monitor that sends a message.

The second one is where most small businesses fail, and they fail it confidently, because a backup plugin reports success every night. A backup that has never been restored is a belief. Restoring it once tells you whether it includes the database, the uploaded images and the configuration, and it is usually one of those three that turns out to be missing. The longer read on that is a data backup strategy for a small business, in plain terms.

What the security plugin is not doing

A security plugin is worth having and it is not a control. It will block noisy automated traffic, it will complain about file permissions, and it will send an email every week that nobody opens after the first month. What it cannot do is apply an update, and it cannot make a decision about an account that should have been removed.

It is also running inside the thing it protects. If the platform underneath it has a flaw being actively exploited, the plugin is a tenant in that building. This is not an argument against plugins, it is an argument for the update date being check number one instead of check number five.

Four of the seven are yours and cost nothing but an afternoon. That ratio is the reason this is worth doing as an owner rather than delegating wholesale: the cheap half is also the half that is usually wrong.

The reference to use when someone quotes a standard at you

If an agency or a buyer's questionnaire starts citing a standard, the one meant is almost always the OWASP Top 10, published by the OWASP Foundation as what it calls "a standard awareness document for developers and web application security". The current edition is the 2025 one.

It is written for developers, and that is the point to hold onto. It is a good list for the people building the thing, and it is not a checklist an owner can work through, which is why the seven above do not try to restate it. When a questionnaire asks whether you follow it, the honest answer is a sentence about who builds your site and how they keep current, not a tick.

Where the cost actually lands

Security is not a line item on its own in a small business, it is the part of maintenance people cut first because nothing visibly happens when it is done. The monthly update habit, the restore test, the certificate that renews itself: that is maintenance, and it is covered honestly in software maintenance cost after launch: the year one bill.

There is also a structural answer that is worth naming, because it removes several of these checks rather than performing them. A site with no database and no admin login has a much smaller surface to protect, and for a brochure site that is a real option with a performance argument attached: static site vs WordPress performance, the honest numbers. If you are weighing what the running arrangement costs either way, what does a web app cost per month to run has the breakdown.

The honest limits

This checklist will not stop a determined attacker and it is not meant to. It is aimed at the overwhelming majority of incidents that reach small businesses, which are automated, opportunistic, and looking for a known flaw that was published months ago and never patched. If you are handling card data directly, or you hold health or government records, you are in a different conversation with a different budget and you need an assessment rather than a list.

There is no figure here for how much any of this reduces your risk, because we do not have one worth citing. The numbers in circulation come from vendors selling the fix, and the honest position is that these seven are cheap, verifiable and widely recommended, not that they buy a measurable percentage.

The last limit is the uncomfortable one. Most of what is written above is somebody else's job, and the only part you can genuinely own is asking for the evidence and reading the answer. A site that is maintained by nobody in particular is the actual finding in most of these reviews, and no checklist fixes that. Deciding who is responsible, by name, is the first fix.