What a security review actually looks at

You bought a firewall plugin, a malware scanner and an uptime monitor. Each renews separately and each reports on a different part of the system.

Ask which of your systems are reachable from the internet right now and nobody has a complete list. The products above do different jobs; none produces that inventory, and every decision after it depends on having one.

I start a review by listing what answers, what it runs, who can reach it and what one compromised component could reach next. In my experience, removal candidates are often services nobody realised were still running.

Security by subtraction

Removing an unused service eliminates its patching, monitoring and renewal work as well as its attack surface. You cannot remove services customers need, so I start with those that have no current owner or purpose.

Products arrive with a checkout page and a dashboard. An inventory is not something you switch on; someone has to trace the systems, accounts and connections. That difference helps explain why a company can have several security subscriptions and no dependable list of what they cover.

Step one: what answers

Five sources disagree with each other, which is useful:

1. The DNS zone, every record. Look for records pointing at retired infrastructure, unmanaged mail hosts and wildcards that resolve more names than expected.
2. Certificate Transparency logs. Public certificate logs can reveal hostnames that were covered by submitted certificates. They are a discovery source, not proof that each hostname is still live.
3. The hosting control panel. Compare what is running with what the site needs: PHP pools, databases, file-transfer services, scheduled jobs and old virtual hosts.
4. An authorised port scan. Scan only the domains and addresses the client has authorised in writing, within the hosting provider’s permitted-use policy.
5. The deployed files. Check for exposed repositories, environment files, directory listings, database backups, debugging files and admin paths left by software the site no longer uses.

A common finding is an old staging copy. It may contain production data, run older software or accept weaker access controls than the live site. Each of those conditions has to be observed rather than assumed.

Step two: what it runs

The version question is not “Is this the latest?” It is “Is anyone still shipping security fixes for it?”

For the language runtime the dates are published and unambiguous. PHP 8.1 stopped receiving security fixes on 31 December 2025. PHP 8.2 stops on 31 December 2026 — the end of this year. If your site is on either of those, that is the first line of the report, above anything you have installed to protect it.

One caveat worth asking your host about directly: some platforms run distribution packages that continue to receive backported security fixes after the upstream branch ends. That is a real answer and it changes the finding — but you have to ask for it in those words rather than assume that “supported” on a features page means the same thing.

Apply the same question to the operating system, web server, database, CMS core, plugins, modules and themes. A long release gap is a reason to investigate, not proof that an extension is abandoned. Check its published support policy, security releases, maintainer activity and compatibility with the supported runtime.

What common security products cover, and what still needs separate verification.

What you bought	What it can do	What still needs checking
In-application firewall plugin	Blocks configured request patterns inside the application	Other services, stolen credentials and vulnerabilities outside the plugin
External WAF	Filters web traffic before it reaches the application	Origins that bypass it, non-web services and accounts
Malware scanner	Detects files or behaviour matching its rules	The way in and persistence outside its scan scope
Uptime monitor	Reports whether a tested endpoint responds	Integrity and unauthorised access need different evidence
Managed hosting	Maintains layers named in the service agreement	Who owns application updates, accounts, backups and incident response
TLS certificate	Encrypts traffic in transit when correctly deployed	The application and systems at either end

Step three: who can reach it

Accounts often outlive the reasons they were created.

Check administrator accounts held by former suppliers, staff who have left, short-term contractors and integrations that no longer run. For each account, record an owner, purpose, privilege level and last use before deciding whether to retain or remove it.

Review OAuth grants and connected applications separately. An analytics tool may hold access to an advertising account, a form builder may have a mailbox token and a deployment integration may have rights across several repositories. Password changes do not necessarily revoke those grants, and the website’s own admin panel may not display them.

Then check keys, CI variables, shared credentials, active sessions, multifactor authentication and account-recovery routes. A narrowly scoped service credential with a named owner is easier to rotate than a deployment key tied to someone’s personal account.

Step four: what one compromise reaches

The last question is the one that decides how bad a bad day is. If the staging site is taken, does that reach production data? Does the application connect to its database with a user that can drop tables, when it only ever needs to read and write rows? Are the backups reachable with the same credentials as the thing they are backing up — which is the question ransomware asks first? Does mail leave from the same machine, so that a compromise costs you your sending reputation as well?

This does not necessarily require another subscription. It does require evidence from configurations, account lists, logs, access tests and interviews. Someone has to follow the connections and record what each credential can reach.

What comes out of it

Each finding gets the same five fields: the affected system, observed condition, consequence, recommendation and priority. Evidence belongs with the observed condition so another person can reproduce it.

For example, a finding about a public staging host would record the observed response, resulting exposure, recommended restriction or deletion and priority. That illustrates the format; it does not assume every staging site has the same defect.

That format makes the report usable by your developer or another supplier. I would apply the same test to anyone you hire: the evidence and recommendation should be clear enough for a competent third party to act on.

What this is not

This review is not a penetration test: it includes no exploitation, social engineering or denial-of-service testing. Those require separate scope, authorisation and specialist work.

It is not a compliance certificate. Compliance depends on the applicable requirements, evidence and accountable organisation; this review covers only its stated technical scope.

It is also not incident response. A review identifies reachable and stale systems; it does not prove that compromise has not occurred. Suspected compromise starts with logs and forensic evidence and takes priority.

Sites processing card or health data and organisations shipping software need controls and assessment beyond this review.

Sources

1. Supported versions — PHP.net — PHP 8.2 security support ends 31 December 2026; PHP 8.3 ends 31 December 2027. Checked 20 August 2026.
2. Unsupported branches — PHP.net — PHP 8.1 reached end of life on 31 December 2025. Checked 20 August 2026.
3. How Certificate Transparency works — How certificates and precertificates enter public logs and how those logs can be queried. Checked 20 August 2026.
4. Attack Surface Analysis — OWASP — Mapping entry points, accounts, data and trust relationships, then reducing unused attack surface. Checked 20 August 2026.

Start with what is exposed.

Send the URL and tell us what already worries you. The first deliverable is the list of what answers from the internet — and it is yours to keep, whoever does the remediation.

Ask for a reviewWhat a review covers