Drupal core has a good security record. Almost every compromised Drupal site we have been called to was running a known-vulnerable contributed module, an over-permissive role nobody reviewed, or a file directory the web server was happy to execute. Those are quick to find for someone who knows where to look, and that is what this engagement is: a structured pass over the places Drupal sites actually fail, ending in a list you can act on. You get the findings whether or not you hire us to fix them.
- Who this is for
- Teams who have just inherited a Drupal site, anyone about to put one into production, anyone who has had an incident, and organisations who need a periodic review written into a maintenance contract.
When an audit is worth doing
Four moments, and they are not equally urgent.
- After a takeover. You now own a codebase you did not write. Before you agree a support SLA on it, both sides need to know what is in there. This is the most common reason we are asked.
- Before go-live. The cheapest possible time. Permissions, file handling and dependency currency are all easier to fix before real content and real users exist.
- After an incident. Different work, and urgent: containment and forensics first, then the audit that establishes how it happened and what else is exposed. Say so when you contact us, because the first hours are handled differently.
- On a schedule. Annually, or at whatever cadence your insurer or your board asks for. Most of our maintenance clients have this written into the contract, because security patching is continuous but reviewing the shape of the thing is not.
What is in scope
The audit covers the layers a Drupal site is actually attacked through, from the code down to the server:
- Core and contributed module currency. Every installed module checked against the published security advisories, including the ones that are abandoned upstream and will never receive another fix. Unsupported modules are reported separately from out-of-date ones, because the remedy is different.
- Composer dependencies. The libraries under Drupal, audited for known vulnerabilities, including dependencies you never chose and pulled in transitively.
- Roles and permissions. Every role read against what it can actually do. The findings here are usually the most serious and the least expected: an editor role with "administer filters", an authenticated-user permission that should have been staff-only, a PHP filter still enabled from a migration.
- User accounts. Dormant administrators, shared logins, accounts belonging to people who have left, and whether an administrator can be created without anybody noticing.
- File handling and permissions. Upload validation, what a private file directory really protects, and whether anything in a writable directory can be executed by the web server.
- Forms and input handling. Text formats and which roles reach the permissive ones, spam and flood controls, and custom form handlers that build queries or render markup themselves.
- APIs and integrations. Exposed REST and JSON:API resources, authentication on each, what a key can do if it leaks, and whether credentials are in configuration that ends up in version control.
- Environment and transport. TLS configuration, security headers, error verbosity in production, database and cache exposure, and whether the update and administrative paths are reachable from the public internet.
What you get back
A single report, classified so that it can be triaged rather than read end to end:
- Critical: exploitable now, with a plausible path to it. Fix before anything else on this list.
- High: exploitable given one more condition, or a known-vulnerable component with a public advisory.
- Medium: weakens defence in depth, or makes an incident harder to detect and recover from.
- Low: hardening and hygiene, worth doing in the next maintenance window.
Each finding carries what it is, where it is, what it would allow, the recommended remediation, and an effort estimate. The estimates are the part clients use most: they turn a security report into a budget conversation instead of an argument.
We also state plainly what we did not test. An audit with no stated boundary is not an audit.
How this differs from ongoing maintenance
They solve different problems and clients regularly buy the wrong one.
Maintenance keeps you current. Security advisories are applied as they are published, dependencies are kept moving, backups are taken and monitoring runs. It is continuous, it is priced per month, and it is on the support and maintenance page. What it does not do is question the configuration it inherited: if a role was over-permissive on the day maintenance started, patching will never find it.
The audit is a point-in-time review of that inherited shape: permissions, configuration, architecture, dependencies. It finds the things patching cannot, and it is the reason most of our maintenance contracts open with one.
If you are buying both, the audit first is the cheaper order. It is also how we price a support SLA honestly: a monthly fee quoted without knowing what is in the codebase is a guess that gets corrected later, at your expense.
Remediation, and who does it
Findings are quoted for separately, after they exist. The order we recommend is rarely the order of severity alone: module updates that close several advisories at once usually come first because they are cheap, then the permission model, then anything requiring code changes.
Where the underlying cause is an unsupported Drupal version, remediation is an upgrade rather than a patch, and we will say so rather than sell you a month of patching that cannot work. Drupal 10 reaches end of life on 9 December 2026, and after that date a currency finding on core has only one fix.
Your own team is equally welcome to do the work. The report is written for a developer who was not in the audit, and we answer questions on our own findings at no charge.
What it costs
The audit is scoped from the size of the codebase, the number of contributed and custom modules, and how many environments and integrations are in scope. It is quoted as a fixed price before it starts.
Remediation is quoted separately against the findings. Our published bands are on the pricing page; audit and remediation work sits in the maintenance and support band, which runs from $100 to $5K and above per month depending on the system. Work delivered by us carries the usual warranty: one year as standard, extendable up to three by agreement, as set out in the warranty policy.
Questions we get asked
Is this a penetration test?
No, and the distinction matters when a buyer asks. A penetration test attacks a running system from the outside to prove exploitability. This is a white-box review of the code, configuration and permissions with the source in front of us, which finds a different and usually larger set of problems. If your requirement is specifically a penetration test by an accredited tester, we will tell you so rather than sell you this instead.
Can you audit a site you did not build?
That is the normal case. A site we did not build is exactly where an audit earns its money, because nobody currently holds the whole picture of it.
How long does it take?
It scales with the number of contributed and custom modules, the amount of custom code, and how many environments and integrations are in scope. We give you that figure with the quote, before you commit.
We think we have already been compromised. What now?
Say that when you contact us, because the first hours are handled differently: containment and preserving evidence come before any review. An audit run on a live compromise both destroys forensic evidence and answers the wrong question.
Do you need production access?
We prefer a copy: the codebase, a sanitised database, and read access to the configuration. Some findings (TLS, headers, exposed paths) need the production hostname, but that is observation from outside rather than access to it. Where production access is genuinely needed we ask for the narrowest account that will do the job, and it is revoked when the audit ends.
What if the findings are embarrassing?
They usually are, for whoever built it, and almost never for the person who commissioned the audit. The report describes the system, not the people. We work under NDA as a matter of course, and the findings go to you and to nobody else.
Our Drupal version is out of support. Is an audit still worth it?
Yes, but expect the headline recommendation to be the upgrade, because on an unsupported version core currency findings have no other fix. The audit is still what tells you how exposed you are in the meantime, and which of the other findings are worth money before the upgrade lands.
Do you fix what you find?
If you want us to. It is quoted separately against the findings list so that the audit is never a sales instrument with a predetermined conclusion. Plenty of clients take the report to their own team, which is a perfectly good outcome.
How often should we repeat it?
Annually is what most of our maintenance contracts settle on, plus after any significant change of architecture, hosting or team. Patching should be continuous and is a maintenance activity, not an audit one.
Migrate & Audit
Related services
Find out what is actually in there
Tell us the site and why you are asking. The findings are yours whether or not we do the remediation.