Audit an enterprise Drupal site across five areas: core and module health, security posture, AI readiness, content architecture, and hosting hygiene. Sixteen checks, roughly 60 minutes, using the admin UI and a few Drush commands. The output is not a remediation plan. It is a list of the places where you cannot answer the question, which is where a formal audit should start.
Most enterprise Drupal sites don't fail suddenly. They degrade quietly: one unreviewed module update, one undocumented configuration change, one deployment that "worked fine" until it didn't.
By the time a CTO asks hard questions, nobody can say when the site was last patched, which modules are custom, or why performance has been slipping.
This checklist helps technical leaders run a rapid self-audit across the five highest-risk areas. It is a 60-minute orientation rather than a full governance audit: it surfaces the right questions and flags where professional depth is warranted.
Is Your Drupal Core and Module Stack Up to Date? (15 minutes)
Start here, because everything else in the audit sits on top of it. Most of this section is answerable from a single page: Reports, then Available updates.
Drupal Core Version
What a red flag looks like: Running anything below the current minor release, or on an unsupported PHP version, means you're exposed to vulnerabilities with no upstream fix path. The near-term marker is fixed: Drupal 10 reaches end of life on 9 December 2026, and individual 10.x minors lose coverage before the branch does.
How to check: Reports, then Status report, for core and PHP versions. Compare your minor against the release schedule rather than against the last time someone updated.
Contrib Module Update Status
What a red flag looks like: If more than 20% of your contrib modules haven't been updated in 6+ months, you have a maintenance liability that compounds with every Drupal release.
How to check: Reports, then Available updates, or drush pm:security for the security subset. Count the modules flagged against the total installed to get the percentage.
Abandoned or Unsupported Modules
What a red flag looks like: Any module flagged as abandoned on Drupal.org with no maintained fork and still active in production is an unowned liability with no security fix path.
How to check: The Available updates page marks unsupported releases. For anything ambiguous, open the module's Drupal.org project page and look at the maintenance status and the date of the last commit.
Is Your Security Posture Documented? (10 minutes)
This section is less about the site than about whether anyone owns it. Every red flag below is a governance answer rather than a technical one, which is why it takes ten minutes and not thirty.
Last Security Advisory Review
What a red flag looks like: No documented process for monitoring Drupal Security Advisories, and no defined patch response window, means vulnerabilities are discovered reactively after exposure, not before.
How to check: Ask who is subscribed to the Drupal security advisory mailing list and what the agreed response window is for a critical advisory. If the answer is a name rather than a process, that is the finding.
Admin Role Proliferation
What a red flag looks like: More than a handful of accounts holding the top-level administrator role with no clear business justification, or no custom roles defined at all beyond the defaults.
How to check: People, filtered by role, for the administrator count. People, then Roles, to see whether custom roles exist. A site with three roles and forty editors has no permission model.
SA-CORE Exposure
What a red flag looks like: If no one on your team can confirm when SA-CORE advisories were last reviewed against your installed version, you have a governance gap, not just a patching gap.
How to check: Take your current core version from the status report and read forward through the SA-CORE advisories published since. Anything affecting your version that you cannot account for is open exposure.
Is Your Site Ready for AI? (10 minutes)
AI readiness is a data-structure question before it is a tooling question. The three checks below determine whether AI features would have anything reliable to operate on, which is why a site can install the Drupal AI module suite and still get ungovernable output.
What a red flag looks like: Content stored without consistent, structured fields or taxonomy gives AI-assisted tools no reliable data layer to operate on. Outputs will be inconsistent and ungovernable at scale.
How to check: Structure, then Content types, then Manage fields. Look for content types where the substance lives in one long body field rather than in typed fields, and for taxonomy vocabularies that are unused or applied inconsistently.
Content Workflow Automation Capability
What a red flag looks like: No documented workflow states, approval stages, or automation hooks means your CMS cannot support AI-assisted publishing without significant rearchitecting.
How to check: Configuration, then Workflow, then Workflows. Confirm whether Content Moderation is enabled and which content types it actually applies to, which is frequently fewer than the team assumes.
API and Integration Readiness
What a red flag looks like: No headless capability or documented API layer means the platform cannot connect to the AI tools, personalization engines, or third-party systems your enterprise teams are already adopting.
How to check: Extend, filtered for Web services. Confirm whether JSON:API or REST is enabled, and whether anyone has documented which endpoints are exposed and to whom.
Is Your Content Architecture Governed? (15 minutes)
This is the section that most often produces the surprise. Content architecture accumulates without anyone deciding it should, and the cost surfaces during a migration or a redesign rather than during normal operation.
Content Type Sprawl
What a red flag looks like: More content types than the business can account for, with overlapping purposes, no clear owners, and no governance trail. This is a structural liability that compounds the cost of every future migration, redesign, or platform upgrade.
How to check: Structure, then Content types. Ask a business stakeholder to name the purpose of each one. The types nobody can explain are the finding.
Orphaned Nodes
What a red flag looks like: A significant share of total nodes unpublished, unedited for two years or more, or unlinked from any menu or view, serving no current purpose but still bloating the database and adding query load.
How to check: Content, filtered by unpublished status and sorted by last updated. Compare that count against total nodes to get a proportion rather than a raw number.
Editor Role Structure
What a red flag looks like: Everyone sharing a single broad editorial role, with no separation between creators, reviewers, and publishers, means there's no accountability layer and no audit trail for content changes.
How to check: People, then Roles, then Permissions. Look specifically at who holds the publish permission for each content type. If it matches who holds the create permission, there is no separation.
Content Approval Chain and Audit Trail
What a red flag looks like: No formal approval chain between content creation and publication, and no audit trail for who published what and when, means you cannot demonstrate content governance to a compliance reviewer or internal stakeholder.
How to check: Open a recently published node and check its Revisions tab. If revisions are disabled or the log messages are empty, you have no trail to produce.
Is Your Hosting and Deployment Hygiene Sound? (10 minutes)
None of this is visible from inside Drupal, which is exactly why it goes unexamined. All three checks are questions for whoever holds the hosting relationship.
Backup Frequency and Restore-Tested Status
What a red flag looks like: Infrequent or unverified backups with no documented restore test means the site has no reliable recovery path in the event of data loss or a security incident.
How to check: Ask for the date of the last successful restore test, not the date of the last backup. A backup nobody has restored from is an assumption.
Environment Parity
What a red flag looks like: Significant differences between dev, staging, and production in PHP version, module versions, or configuration indicate issues won't be caught before they reach production.
How to check: Pull the status report from each environment and compare. If there is no staging environment at all, that is the more serious finding.
Uptime Monitoring
What a red flag looks like: No active monitoring tool in place, or alerting that doesn't reach the right team in real time, means users discover downtime before you do.
How to check: Ask what endpoint the monitoring actually checks. If it checks the cached public URL, a failing origin server behind a CDN will still report green.
What Do These Audits Usually Find?
Vardot's position: the most common finding is not a single critical vulnerability. It is accumulated governance debt: modules nobody owns, roles nobody audited, deployment processes nobody documented. That pattern holds across the enterprise Drupal instances we have audited in the nonprofit, higher education, and government sectors.
The pattern surfaces quickly. Closing it takes a structured plan. As AI tools enter the enterprise content stack, that gap becomes more urgent, because governance debt compounds faster when automation amplifies ungoverned processes.
Pay attention to which checks you could not answer rather than to which ones failed. A red flag is a task. A question nobody in the organization can answer is a governance gap, and those are the ones that take longest to close.
Vardot's Enterprise CMS Audit covers these five areas in depth and delivers a prioritized action report to technical leadership: not a list of findings, but a ranked remediation plan with effort estimates. Vardot is a Drupal Diamond Certified Partner with 200+ platforms launched and a 4.9/5 Clutch rating across verified reviews.
If this checklist surfaced more questions than answers, that's the signal.
With over six years in the field and three at Vardot, Majdouleen is a Senior Product Owner who bridges the gap between technical thinking and client needs. Her engineering background sharpens her approach to analysis and problem-solving, while her deep commitment to clients keeps the human side of product at the center; from the first requirements session all the way to go-live.
It is a structured review of your content management platform across technical, governance, and operational dimensions. It goes beyond performance checks to assess whether your CMS can support the workflows, compliance controls, and integrations your organization requires now and as AI tools become part of the content stack.
AI readiness refers to whether your CMS platform can effectively support AI-assisted content workflows. This includes whether content is stored with consistent structured fields and taxonomy that AI tools can reliably process, whether workflow automation hooks exist, and whether the platform has the API or headless capability to connect to the AI tools your teams are adopting or evaluating.
If you can answer the following without hesitation, a self-audit may be sufficient: When was the site last patched? Is there a documented approval chain for published content? Is there an audit trail? If any of those questions require investigation to answer, that's the signal that a professional audit with a prioritized, effort-estimated remediation report is the more reliable path.
For most organizations, annually is the minimum. That said, a CMS audit should also be triggered by specific events: a planned platform migration, a significant change in editorial team structure, the addition of new integrations or third-party tools, or a security incident. Governance debt accumulates quietly,regular audits surface it before it compounds.
