Drupal security

What Drupal Security and Modernization Services Include

Drupal security and modernization services cover the audit, patching, and structural upgrade work needed to keep a Drupal site secure, supported, and easy to update. That includes core version upgrades, contributed module updates, custom module review, PHP and database version alignment, hosting and caching configuration, access and role cleanup, and written documentation of what was found and what changed. The point is not a one-time cleanup. The point is a site your team can update on a schedule instead of a site nobody wants to open.

Most agency copy on this topic stops at "we patch and update." That skips the part that matters to the people paying for it: what an unpatched or end-of-life core version actually costs. For a university, it is application forms failing during enrollment season. For a healthcare or senior living organization, it is compliance exposure and downtime on pages patients and families depend on. For a B2B company, it is broken lead capture and CRM handoffs that quietly drain pipeline for weeks before anyone notices.

When You Need Drupal Security Work

You need Drupal security work when your site is running a core version more than one major release behind, when nobody on your team can say with confidence when the last patch was applied, when the original build team is gone and left no documentation, or when your core version has reached end of life. End of life is the hard deadline: patches stop permanently, and any newly disclosed vulnerability stays open on your site forever.

Two softer signals matter just as much. First, if updates are treated as a special project instead of routine maintenance, the cost of each cycle is compounding. Second, if forms, analytics, or CRM integrations have broken after past updates and nobody caught it for weeks, you have a QA gap rather than a code gap. We test both. Our team's Growth & Marketing Services background is exactly why we treat a broken Webform as a failed release rather than a cosmetic issue.

What a Strong Drupal Security Engagement Looks Like

A strong engagement starts with a documented audit covering core version, module vulnerabilities, server and PHP configuration, user access, backup readiness, and form and integration integrity. Findings get ranked by severity and remediation effort so you can sequence work against real budget cycles. Then remediation runs through a repeatable pipeline instead of ad hoc SSH sessions.

O8 runs a reusable, semi-automated Drupal core and contrib update pipeline in production on our own o8.agency site: composer audit against the dependency tree, a feature branch for the update set, QA on a staging environment, explicit approval, then merge. Our own site runs Drupal with Varnish, Redis, and Cloudflare on Upsun at real production traffic, so the process is one we depend on, not one we invented for a proposal. When we set this up for a client, the deliverable is the pipeline itself plus documentation, so the cadence survives staff turnover.

Engagement models we scope

How Much Does Drupal Security & Modernization Cost?

Pricing is scoped after the audit, not before it. The variables that move the number are the number of contributed modules in the build, how much custom code exists and whether it is documented, how many major versions separate your current core from a supported one, hosting and caching conditions, and how many integrations and forms need post-release verification. A site one release behind with clean contrib is a fundamentally different engagement than an end-of-life install with undocumented custom modules and no staging environment.

Because of that spread, we do not publish a package price. We run the documented audit first, show you the findings, and then scope remediation so you are buying against evidence. If the audit shows an in-place upgrade is not the right path, we say so, and we may recommend a a website redesign engagement instead of a rebuild-in-place. We never push clients off Drupal to sell a bigger project.

Taking Over a Drupal Site You Didn't Build

Undocumented, agency-abandoned Drupal sites are a normal starting point for us. Discovery comes first: local environment setup, dependency inventory, custom module review, hosting and DNS access mapping, and a written record of what you actually own. Only after the codebase is legible do we start changing it.

We build and actively support live enterprise Drupal sites for the University of Minnesota, Baker University, MCAD, St. Mary's Press (LERI), and Ecumen. Those are environments where downtime and access failures have real consequences, which shapes how conservatively we sequence upgrades. Longer term, structural work often overlaps with our Web Design & Development Services team, and forward-looking builds sometimes involve our our AI web development team practice when new functionality is on the roadmap alongside the upgrade.

Handoff So Your Team Is Not Dependent On Us

The end state we aim for is an internal team that can run routine updates and content work without a support ticket. That means documentation written for humans, local setup instructions that actually work, and role-appropriate training for editors, marketers, and developers. Retainers should exist because you want senior help available, not because nobody else can log in.

How Our Delivery System Supports Drupal Security Work

Behind the scenes, O8 Intelligence is the internal delivery infrastructure we use to keep advisory monitoring, dependency audits, and post-release QA results connected in one auditable trail. When a highly critical advisory drops, we can see which client sites carry the affected module, what version each is on, and what changed in the last release cycle without reassembling that context by hand. It is not a product you log into. It is why our reporting on your patch history is specific instead of vague.

Get The Audit First

The fastest way to know your real exposure is a documented audit of core, contrib, custom code, hosting, and access. Bring us the site, even if the last team left nothing behind. We will tell you what is running, what is at risk, and what order to fix it in.