Auditing an inherited Drupal site

Why an inherited Drupal site audit comes before any change

Before you change anything on an inherited Drupal site, you need a written answer to three questions: what is running, what is still supported, and what is risky. An inherited site audit answers those questions by reviewing the codebase, contributed modules, patches, security status and hosting, then turning the findings into a prioritized remediation plan. Teams usually need it when a departed developer or another agency hands over a site and nobody on the new team can explain how it was built or what it depends on.

The first checks usually decide the scope. Confirm the Drupal core version and the PHP version the site runs on, because both set the upgrade path. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so a Drupal 7 site cannot be treated as a routine maintenance job. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so a Drupal 10 site has a dated decision ahead. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later, so an old PHP runtime may force hosting work before any Drupal work. Ask the outgoing team for these versions in writing and verify them on the server, not in the README.

Drupal core and contributed projects are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself, so the audit does not involve a license purchase. The cost and risk sit in your team's own custom modules, themes, patches and hosting. Those are the parts most likely to be undocumented, so an audit should start there and treat any locally edited core file or unmaintained custom module as a finding to explain, not a detail to skip.

How the audit runs, step by step

The sequence moves from confirmed access and a complete inventory through code, security and hosting review to a ranked remediation plan that your team can own after handover.

Confirm access and agree scope in writing
Before any analysis, the auditor confirms what access the client can legally and practically provide: source repository, staging and production admin accounts, database read access, hosting consoles and the backup location. Access is granted under a named account for each person, and the audit scope is recorded in writing with the systems and sites included. The step is done when every system in scope has a working, tested login and the client has signed off the scope document.
Build a site and dependency inventory
The auditor records what is actually running rather than what the handover notes say. This covers the Drupal core version, the PHP version reported by the running site, every contributed module and theme with its version, custom modules, Composer dependencies, patches applied to core or contrib, the database engine and the web server. Confirm the running Drupal core and PHP versions against the Drupal.org system requirements and PHP requirements pages, and note whether the site is on a supported major version. The step closes with an inventory file that matches what the site reports, not what the documentation claims.
Review the codebase and patch set
Custom code is read for bad practices that will make future upgrades expensive, such as core overrides, hardcoded values, direct database queries and missing dependency injection. Each core and contributed patch is compared with the upstream issue to see whether it has been merged, superseded or is still needed. The reviewer also checks that the repository is in version control, that the lock file matches the deployed code and that no development files or credentials are committed. The step is complete when every patch has a status and every custom module has a short risk note.
Check unsupported modules and security status
Each contributed project is checked against its Drupal.org project page for maintenance status, compatibility with the running core and any open or published security advisories. The Drupal Security Team publishes advisories with CVE identifiers, so the reviewer matches installed versions against those advisories. Any Drupal 7 component is flagged, because Drupal 7 security support ended on January 5, 2025. The output is a list of modules that are unsupported, abandoned, or behind a published security fix, with the advisory reference for each.
Verify staging matches production before testing
Before the auditor runs any test or update, they confirm that the staging copy has the same code commit, the same contributed module versions, the same configuration export and a recent database copy as production. Differences are logged and resolved, since a test on a drifted copy tells you little about production. The check includes comparing the active configuration with the exported configuration. The step is done when a documented comparison shows no unexplained differences, and the team agrees that staging is a valid test target.
Review hosting, backups and operations
The hosting review covers the web server, PHP configuration, database version and engine, cron execution, file storage, TLS, secrets handling, and where backups go and how often they run. The auditor also checks whether a restore has ever been tested, who receives monitoring alerts and what logs exist. Items are compared with the Drupal.org system requirements, and any version that is out of support is recorded. The output is a hosting findings list with each item marked as verified, unknown or failing.
Rank remediation by risk and effort
Findings from the earlier steps are grouped into security exposure, upgrade blockers, operational gaps and cleanup. Security items and anything that blocks a supported Drupal version are placed first. Each item gets an owner suggestion, a dependency note and the test it will need. Items the client cannot act on yet, such as a Drupal 7 site that must be migrated, are documented with interim options and the question of who provides them, including any extended support provider the client chooses to engage. The result is a ranked plan the client can approve line by line.
Hand over the findings and the runbook
The auditor delivers the written report, the inventory, the patch register, the advisory list and the ranked plan, then walks the client's technical owners through them. The handover includes the access inventory, the list of credentials that must be rotated and the steps for the first monthly update cycle. The step is complete when the client's named owner confirms receipt, questions are answered and the remediation items are either accepted into a scope or assigned internally.

Audit depth options and when each fits

This table compares three audit depths for an inherited Drupal site: a light inventory, a full codebase and security audit, and an audit tied to a migration decision. Read each row against your own risk, timeline and the state of the site, and note what each depth leaves open.

Audit depth	What it covers	Who it suits	What it leaves open
Light inventory audit	Drupal core and contributed module versions, PHP and database versions, list of custom modules, patches applied to core or contrib, hosting layout and backup status	Teams that need a clear picture before a budget or handover decision and have a developer who can act on findings	Custom code quality, exploitable vulnerabilities, hard-coded secrets and access control logic are not tested
Full codebase and security audit	Everything in the light inventory plus custom code review, patch and fork review, configuration and permission review, security status of each contributed project, secrets handling and hosting hardening	Organizations keeping the site on its current major version, or handling personal or regulated data where a security baseline is needed	Does not decide the long-term platform path, and findings still need a funded remediation plan to close
Audit combined with a migration decision	Full audit scope plus readiness assessment for moving to a supported Drupal version, content and configuration mapping, and theme and module replacement analysis	Drupal 7 sites that cannot stay on their current version, and sites that must move to Drupal 10 or later	Migration cost and sequencing depend on content volume and custom modules, which need confirmation from the actual codebase before a quote is firm
Illustrative: Drupal 7 site with unsupported modules	Inventory shows the site is past security support, so the audit maps each module to a supported replacement or a migration path	Teams who must decide between migrating and paying for extended security support	Extended support is a separate arrangement with a certified provider, and it does not remove the need to migrate later

What the audit checks in the codebase and hosting

An inherited site fails in a few predictable places, and each check below tests one of them. Read together, they tell you how far the site is from a supported state, how much work an upgrade will be, and which risks need action before anything else changes.

Core version and support status

Start by confirming the exact Drupal core version in composer.lock and comparing it with the core release schedule. Drupal 7 security support ended on January 5, 2025, so a Drupal 7 site needs a separate decision on extended support or migration. For Drupal 10 sites, the end-of-life date is the deadline that shapes the upgrade plan. Record the version, its support end date and the gap in months.

Contributed module compatibility

List every contributed project and its installed release, then check whether each one has a release for the target Drupal version and whether it is still maintained. Abandoned modules and dev snapshots are the most common blockers in an upgrade. Flag any module that is installed but unused, since it still adds security exposure and upgrade work.

Custom code and direct core patches

Check for edits made directly inside core/, modules/contrib/ or vendor folders, along with patches applied outside the Composer workflow. Such changes are overwritten on the next update or silently lost in a rebuild. Review custom modules for deprecated APIs, hard-coded hostnames and unescaped output. Document each patch with its upstream issue, if one exists, so it can be dropped once the fix ships.

PHP version against target requirements

Compare the PHP version on the running servers with the minimum for the Drupal version you plan to reach. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. No supported Drupal version runs on PHP 7, so a PHP 7 site must move the runtime before any core upgrade. Check whether the hosting image pins PHP and who can change it.

Database and web server stack

Identify the web server, such as Apache or Nginx, and the database engine, such as MariaDB, MySQL, PostgreSQL or SQLite, along with their versions. Confirm that they are still vendor-supported and that the database engine matches what the Drupal system requirements list. Unusual combinations, such as SQLite on a production site, need an explicit owner and a reason. Also check TLS configuration, file permissions on the webroot and whether settings.php is writable.

Configuration and secrets exposure

Search the repository and the environment for database passwords, API keys, SAML certificates and OAuth client secrets committed in settings.php, services.yml, exported configuration or CI files. Confirm that the production config/sync directory does not contain test-only settings and that the database and file backups are excluded from the webroot. Any secret found in version control should be treated as exposed and rotated, not just removed from the next commit.

How Drupal 7 and other legacy sites change the audit

On a legacy site, the audit answers a different question: not how to patch the current codebase, but whether the site can stay in service at all. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so any Drupal 7 site you inherit is running without core security releases. Record that as a finding on day one, along with the date you confirmed it, and check every contributed module against its own project page for the same reason.

A Drupal 6 or 7 site cannot be updated in place to Drupal 10 or later. Drupal.org documents the path as a migration into a new site, using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt because they cannot be migrated. For the audit, this means the content model, custom modules and theme are reviewed as inputs to a rebuild, not as code to keep. Ask the previous team which custom code is actually used, and list the modules that have no Drupal 10 or 11 equivalent, since those decide the migration effort.

If the business cannot migrate yet, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites in that position. The audit should record this as an option, not a decision. Confirm eligibility, coverage, duration and pricing directly with each vendor, because those terms are theirs to state and can change. Whichever path you choose, put the end-of-support date in the remediation plan so the migration or extended support contract is scheduled before the site falls out of coverage.

How the audit changes by inherited situation

When a site arrives with no handover notes, the audit starts by reconstructing what exists. The auditor cannot assume the running code matches any repository, build script or environment record, so the first pass is inventory: what is deployed, where it runs, and which accounts and secrets it depends on. Findings from this phase often shape the rest of the plan, because undocumented behavior is where surprises tend to sit.

Deployed code versus repository: Compare the live codebase, including composer.lock and any files edited directly on the server, against the version-controlled source, if one exists.
Enabled modules and configuration: Export the active configuration and list every contributed and custom module, noting which ones have no clear owner or purpose.
Hosting and access: Identify the web server, database, PHP version, cron method, DNS, certificates and who holds administrator credentials.
Scheduled and background work: Find cron jobs, queue workers and external scripts that the site depends on but nobody has written down.
Data and integrations: Map outbound API calls, third-party services and the data each one receives.

Remediation plans in this situation usually begin with a documented baseline, followed by a restore path tested on a separate environment. Confirm with the departing team whether source control history, deployment logs and password manager entries are available before estimating the work.

A half-finished upgrade is one of the most common findings on inherited sites. The previous team may have started a move to a newer Drupal core or a major module version, updated some dependencies, then stopped. The site can then run in a mixed state where some code expects the new version and other code still expects the old one, which makes both testing and rollback harder.

Mixed core and module versions: Check core/lock or the Composer constraints for core, then confirm each contributed module is compatible with the version actually installed.
Leftover code paths: Look for deprecated APIs, custom code that was partly ported, and duplicate modules or themes kept from the old version.
Database schema state: Confirm whether database updates were run, and whether any update hooks failed or were skipped.
Configuration drift: Compare exported configuration with what the code expects, since partial exports often leave settings that do not load cleanly.
Run an upgrade readiness report: Use the Upgrade Status module to list blocking issues in the current codebase before deciding whether to finish the upgrade or rebuild.

The remediation plan typically decides between completing the upgrade on a staging copy and restarting from a clean codebase. Ask the client which version was the target and whether any production data changed during the partial work.

How to prioritize findings in the remediation plan

Rank findings in three tiers. The first tier holds exposed security issues and unsupported core: a Drupal core version that no longer receives security releases, a contributed module with a published advisory that is still installed, or an exposed admin path or file that should not be reachable. These go first because they can be exploited without any further work by the attacker. The second tier holds patches that block updates: core or contributed patches applied directly to code, custom overrides that pin a module version, and Composer constraints that stop a security release from applying cleanly. Each of these turns the next monthly release into a manual project. The third tier is technical debt, such as deprecated APIs, duplicated configuration, and custom code without tests. Debt matters for the upgrade later, but it rarely justifies work ahead of the first two tiers.

Fit the plan to Drupal's release rhythm. Bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, so the remediation sprints should end with a tested build ready for those dates, not start on them. Set the target major version before sequencing the work, because it decides which patches are still worth writing. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule. Confirm these dates against the Drupal core release schedule before you commit, since the schedule can change. Remember that a Drupal 12 target also requires PHP 8.5 or later, so the hosting work belongs in the same plan.

Security risks to check first on an inherited site

An inherited Drupal site often carries the security debt of its previous operator, and the risks below tend to appear together. Each one is checked against the codebase, the running server and the recovery process, so the audit can rank findings by what an attacker could reach first.

Unpatched core and contributed modules

Compare the installed Drupal core version and every contributed project against the Drupal Security Team advisories, which carry CVE identifiers and risk scores. Record each exposed component, its installed version and whether a fixed release exists for that branch. Check whether the site is still on Drupal 10 or earlier, since Drupal 10 reaches end of life on December 9, 2026, and Drupal 7 security support ended on January 5, 2025. Patch status is the first thing to confirm with the previous team, because a missing update history usually means nothing was tracked.

Exposed administrative paths

Test whether the login page, user administration, update.php and the Drush and cron endpoints are reachable from the public internet, and whether they are restricted by network rules or a reverse proxy. Record the path, the access rule that applies and the roles that can reach it. Administrative exposure combined with an outdated module is a higher priority than either finding alone.

Shared or default credentials

List every administrator account, service account and database user, and note accounts that are shared between people, named after a former employee or still using a seeded default password. Check whether the database credentials in settings.php match a password reused elsewhere. Record each account, its last login and its owner, and confirm with the client which accounts should be disabled before go-live of the new team.

File permissions and public file exposure

Check that settings.php is not writable by the web server user and that the files directory does not allow execution of uploaded scripts. Confirm that private files live outside the web root and that directory listing is disabled. Record each path with its current mode, owner and whether it is served publicly, because misconfigured permissions on the codebase often go unnoticed until a compromise.

Hard-coded secrets in code and configuration

Search the repository, Composer files, custom modules, exported configuration and the hosting environment for API keys, SMTP passwords, payment tokens and salts placed directly in code or synced configuration. Confirm where the hash salt and any encryption keys are stored. Record each secret, its location and the systems it unlocks, so rotation can be planned once access is secured.

Missing backups and untested restores

Confirm that database and file backups exist, where they are stored, how long they are kept and who can read them. Ask for evidence of a restore to a separate environment, not just a backup log. Record the last successful backup date, the restore time observed and any gaps in coverage for uploaded files. A backup that has never been restored is an assumption, and the audit should label it as one.

Questions buyers ask before an inherited site audit

What drives the cost and effort of auditing an inherited Drupal site?

The size and condition of the codebase drive most of the effort. A reviewer has to read custom modules, the theme, the contributed module list, the patch set and the hosting setup, and each of these grows with the number of sites in a multisite estate and the amount of undocumented custom code. Cost components are the reviewer's time, any environment access work, and tooling runs such as Upgrade Status or dependency checks. Ask a quote to itemize these, state which systems are in scope, and say whether the audit includes a written remediation plan or only findings. Most engagements are fixed-scope, so the written scope sets the price once the inventory is known.

How long does an inherited Drupal audit take to produce a usable plan?

The timeline depends on how fast access and documentation arrive, more than on the audit itself. A reviewer needs the codebase, a database copy or staging environment, hosting details and any previous security notices before analysis starts. Delays usually come from missing credentials, unclear ownership of DNS or mail, and undocumented custom code that needs interviews with the former developers. Ask for a schedule with named checkpoints in the written scope, and confirm how the findings will be ranked so the plan can be acted on quickly.

What must the client provide before an audit starts?

The client provides access and context, and the audit cannot work without them. Typical inputs are:

Read access to the code repository, including the composer.json and composer.lock files and any patch directory
A recent database copy or a staging environment that mirrors production, with sanitized personal data
Hosting, server, deployment and backup configuration, plus the list of cron jobs and queues
Any previous security advisories, incident notes and the list of administrator accounts

Confirm with the outgoing vendor which of these exist, and agree who can answer questions about custom code.

Can our internal team run the inherited site audit themselves?

Yes, a capable team can inventory modules, check Drupal.org project status and review security advisories without outside help. The gaps usually appear in three places: judging how custom code interacts with core upgrades, reviewing hosting and secrets handling with an outside view, and testing exploitable paths that an internal team does not have time to probe. Teams often miss patches applied directly to core, abandoned contributed modules that still run, and configuration that exists only in the production database. Decide early whether the internal review or an external one will produce the document you present to leadership.

What does a Drupal site audit not certify?

A DeployOpen audit does not produce an audit report, attestation or certification. It records what was found in the codebase, configuration and hosting at the time of review, and it prepares evidence and a remediation plan. Compliance assessments are performed by independent auditors and certification bodies, and an auditor may ask for controls that the audit only describes. The audit also does not guarantee that the site is free of vulnerabilities, because findings depend on the systems and versions that were available for review. Ask the provider to state these limits in the written scope.

How does the audit output feed a Drupal upgrade or a Drupal 7 migration?

The audit sorts findings into three groups: items to fix in place, items to rebuild and items to retire. For Drupal 6 or 7 sites, the Drupal.org upgrade documentation says sites are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and themes must be rebuilt because they cannot be migrated. Drupal 7 security support ended on January 5, 2025, so the audit should record which contributed modules have no migration path. For sites already on Drupal 10 or 11, the same list of custom code and blocked contributed modules feeds the upgrade plan. Ask for the output to include a module-by-module disposition.

Which Drupal versions and PHP requirements should the audit check first?

The first check is the Drupal core version and the PHP runtime, because they set the upgrade path. According to the Drupal.org PHP requirements page, Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, and no supported Drupal version runs on PHP 7. The Drupal core release schedule lists Drupal 10 end of life on December 9, 2026. Ask the auditor to confirm the installed core version, the PHP version on each environment and whether the hosting platform can run the target versions.

Who owns the findings after the audit is delivered?

The client owns the codebase, the repository, the findings and the remediation plan. Fixes can be carried out by the internal team, by another agency or by DeployOpen under a separate written scope. Ongoing patching and security response are handled as a separate support arrangement, because the Drupal Security Team publishes advisories on a regular schedule that the site must follow. Agree in writing who receives each finding, who approves changes and who monitors new advisories after the handover.

How DeployOpen scopes and delivers an inherited site audit

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For an inherited Drupal site, we start with a written, fixed scope, review the codebase and hosting in your environment, and hand over a prioritized remediation plan your team can act on.

How we scope

Agree in writing which sites, environments, repositories and hosting accounts the audit covers before work starts.
Confirm the Drupal core and PHP versions in use, then record which contributed modules and patches are present.
Define who receives access, how credentials are shared and how access is removed when the audit closes.

How we build

Review the Composer files, custom modules and patches to separate core changes from contributed code.
Check each contributed module for maintenance status, security advisories and whether it still supports your Drupal version.
Assess web server, database, PHP and backup configuration, then rank findings by risk and effort in a remediation plan.

How we hand over

Deliver a written audit report with findings, evidence, affected components and recommended remediation order.
Walk your engineers and security leads through the plan so decisions about upgrades and migrations stay with your team.
Document the environment, access model and open risks so the next team can continue without the original developers.

How we support

Offer remediation as a separate fixed-scope piece of work, or as a retainer for ongoing updates and monitoring.
Plan remediation around Drupal's monthly bugfix and third-Wednesday security release windows where your team needs them.
Ask your DeployOpen contact to confirm retainer terms, response expectations and handover steps in the written scope.