Every few months a business comes to us with a website that somebody else built, often years ago, and a simple question: is it in good shape? Sometimes the question is prompted by a story in the news. Sometimes by a new person taking over the marketing budget. Sometimes by a customer's procurement team asking for a security statement nobody knows how to write. Whatever the trigger, the answer has to come from looking, not from reassurance, and over the years we have turned that looking into a routine.
This is what the review covers, in roughly the order we do it. Not because we expect to find problems, but because the fastest way to know a site is sound is to check the same things every time, in the same order, and write down what we see.
First, the inventory
You cannot protect what you cannot list. The first day is spent building an accurate picture of what exists: the Drupal core version, every module and theme with its version, the PHP and database versions, the web server, where the site is hosted, which domains and certificates point at it, and which third-party services it talks to. We also list the people: who has an account, which roles they hold, and when they last logged in.
This inventory alone answers a surprising number of questions. A site running a core version several releases behind has a clear next step. A module that has not been updated by its maintainer in years, or has no security coverage, deserves attention regardless of whether it is currently exploitable. Twelve administrator accounts for a team of four is a conversation to have. None of these findings are dramatic; all of them are actionable.
Comparing against published advisories
Drupal has a dedicated security team that publishes advisories for core and for every covered contributed module, on a fixed weekly schedule. That gives us something rare in software: an authoritative list of what has been fixed, when, and in which version. We compare the inventory against it. Every gap between the installed version and the last security release becomes a line in the report, with the advisory's own severity rating next to it.
The same comparison runs on the layer beneath Drupal. PHP, the database and the operating system have their own advisories, and a site is only as current as its slowest layer. On infrastructure we manage, this comparison runs automatically every day, so a review of a site already on our platform starts from a clean baseline and the inventory step is mostly confirmation.
How the site is served
The next set of checks is about the path between the visitor and the application. Is every page served over HTTPS, with certificates that renew themselves? Are the standard security headers in place, so browsers enforce the protections they are able to enforce? Are administrative paths, installation scripts and version files reachable from the public internet? Is there a firewall in front of the application that filters the most common attack patterns before they reach PHP?
These are the checks most reviews find something on, usually because they were never anyone's job. They are also the cheapest to fix. A well-configured edge, like the web application firewall in front of every site we host, takes most of this category off the table permanently.
Accounts, permissions and the login page
Then we look at who can do what. Which roles exist, what each one may do, and whether the people holding them actually need it. Whether administrator accounts belong to named people or to shared logins. Whether two-factor authentication is on for anyone who can change content or configuration. Whether the login page limits repeated attempts. Whether former staff and former contractors still have access.
Permissions drift over time in every organization, and untangling them is more about conversation than technology. We propose a role structure that matches how the team actually works, and we apply the account habits we recommend everywhere, starting with the accounts that hold the most power.
Backups, and proof that they restore
A backup that has never been restored is a hope, not a plan. We check what is backed up, how often, where the copies live, how long they are kept, and whether anyone has ever restored one. Where we can, we do a test restore into an isolated environment and time it. That number, the time it takes to bring the site back from a copy, is one of the most useful facts a business can know about its website, and most have never measured it. We run these drills on a schedule for the sites we host, and a review is a good moment to start.
Custom code and configuration
Finally, we read. Custom modules and themes are where a site is unique, and where general advisories cannot help. We look for the usual categories: user input that reaches a database query or a page without being handled properly, files that are written where they can be executed, secrets stored in the repository, and code that bypasses Drupal's own access checks. We also review configuration for the settings that matter most: text formats, file upload rules, error display, and the permissions granted to anonymous and authenticated users.
This part is the most time-consuming and the most valuable, because it is where the site's own history lives. Findings here are almost always the result of reasonable decisions made under time pressure years ago, and we describe them that way in the report.
What you receive
The outcome is a short document, ordered by impact, with an estimate next to each item and a clear recommendation for the first thirty days. Some items are an afternoon. Some belong in a plan. Most sites we review need less work than their owners fear, and the work itself is calm: updates, configuration, a firewall, two-factor logins, a tested restore. The value of the review is not the list; it is knowing where you stand and being able to say so, in writing, to anyone who asks.
If your site has been running for a while and nobody has looked at it this way, we are glad to. A review takes a few days, and it is the natural first step whether you end up working with us or not.