Drupal Support: What a Retainer Should Cover

Most people looking for Drupal support already own the site. They inherited it from an agency that moved on, or from a developer who left, and now an update is overdue, a form has stopped sending, or a security advisory has landed and nobody can say whether it applies. What they want is not a sales page. It is a scope document: what the work is, what a fair contract says, and what it should cost.

So that is what this is. It sets out the work a Drupal site genuinely needs every month, the operational facts that decide whether a retainer is worth anything, and realistic UK price bands. Read it with a supplier’s proposal open beside it, because the useful part is noticing which of these questions the proposal does not answer.

Two things make Drupal different from generic website maintenance. Its security advisories run to a published timetable, so your exposure window is measurable and can be written into a contract. And a Drupal site is an assembly of contributed modules with independent maintainers, so somebody has to track a moving upgrade target on your behalf.

What should a Drupal support retainer cover? Monitoring the security advisories that apply to your exact module set, applying core and contributed updates on a defined cycle through staging, verifying that backups actually restore, watching uptime and application errors, and a named change budget for small work. In the UK that runs from roughly £250 a month for a simple brochure site to £2,000 or more for a complex one. Below that band you are buying monitoring, not support.

What Drupal Support Actually Means Month by Month

Ask three agencies for a quote and you will get three packages named Essential, Business and Enterprise, each a bulleted list of nouns. The nouns are not the work. The work is a set of recurring tasks that either happen on a schedule or do not happen at all, and the useful exercise is to make a supplier describe each one as an activity, with an owner and a frequency.

There are eight of them. Security advisory monitoring and patching. Core and contributed module updates. Dependency and platform version upgrades. Backup verification and restore testing. Uptime and application error monitoring. Performance regression checks. Content and editorial support. And a change budget for the small work that always arrives.

A contract naming all eight is not automatically good, but a contract naming four is definitely incomplete, and the four that get dropped are almost always the same four: restore testing, performance regression, platform upgrades and the change budget. Those are the expensive ones, which is why they go missing.

Why the package names hide the work

“Unlimited support tickets” says nothing about who applies a core security patch on the third Wednesday of the month. “Proactive monitoring” says nothing about whether a human reads the alert at two in the morning or whether it queues until Monday. “Best effort” says nothing at all.

Replace each phrase with three facts: the activity, its frequency, and the named role that performs it. Most package pages dissolve under that treatment, and the ones that survive are the suppliers worth talking to.

The Patching Window Is the Whole Product

Drupal publishes security releases on a timetable, which is unusual and enormously useful. Core security releases go out in a window on the third Wednesday of the month , starting at 1200 America/New York, which is 1600 or 1700 UTC depending on the season. Contributed projects have a security release window every Wednesday , so contributed advisories arrive far more often than core ones and in batches.

The consequence is that the vulnerability is not the risk. Everybody running Drupal receives the same vulnerability at the same moment, published in the open. The risk is the gap between the advisory going live and the patch being on your production site, because during that gap the flaw is documented, indexed and being scanned for by people who read the advisory faster than your supplier did.

Every other clause in a support contract is decoration next to the number of hours in that gap. So the first question to a prospective supplier is arithmetic, not philosophy. On the third Wednesday of next month, at what time will a person read the advisory, and by when will the patch be live? “Within our standard SLA” is not an answer to that question.

How Drupal Scores Risk, and What That Should Do to Your Contract

Every Drupal advisory carries a number, and that number is the most underused clause-writing tool in the platform. Drupal scores vulnerabilities with the NIST Common Misuse Scoring System, NISTIR 7864 , producing a score from 0 to 25 across six metrics: access complexity, authentication, confidentiality impact, integrity impact, exploit availability and target distribution.

The score maps to five published labels. A score of 0 to 4 is Not Critical, 5 to 9 is Less Critical, 10 to 14 is Moderately Critical, 15 to 19 is Critical, and 20 to 25 is Highly Critical. Those bands are public, stable and not open to interpretation by either party.

Which makes them the natural spine of a support SLA, and almost nobody uses them. Rather than inventing private severity definitions that a supplier can argue about later, write the response commitment directly against the Drupal score: Highly Critical patched within a stated number of hours including out of hours, Critical within one working day, Moderately Critical in the next scheduled cycle, everything else batched. Neither side gets to relitigate what “urgent” meant, because a third party already decided.

Highly Critical Is a Different Operational Event

Highly Critical core releases are rare, and Drupal treats them differently. The security team publishes a public service announcement in advance so that site owners can arrange cover. PSA-2026-05-18 did exactly that, warning on 18 May 2026 of a highly critical core release scheduled for Wednesday 20 May affecting all supported branches.

That advance notice is the thing your retainer should be built around, because it converts an emergency into a booking. A supplier who knows about the PSA on the Monday and has a deployment slot held for the Wednesday is running a support service. A supplier who finds out on the Thursday is running a mailing list.

There is also a mitigation worth knowing about. Drupal Steward is a paid, globally distributed web application firewall run by the Drupal Association and the security team, providing network level virtual patching for highly critical core vulnerabilities so a site is protected while the update is tested. Pricing is published in US dollars and scales with traffic: under 20 dollars a month for a site serving around one million HTTP requests, under 100 dollars a month above ten million. It buys time, not immunity, and a good retainer says who pays for it.

What the Security Advisory Policy Does Not Cover

Three exclusions in the security advisory process and permissions policy change what a retainer has to do, and most support contracts are silent on all three.

Advisories are issued only for stable releases. If a module on your site is running an alpha, beta, release candidate or dev version, no advisory will ever be published for it, and the absence of news means nothing. Coverage is also opt in per project rather than automatic, so an uncovered contributed module can carry a known flaw with no notification path at all.

Then the one that catches people out: no advisories are issued for external libraries, even when a contributed project requires you to install one. A JavaScript or PHP library pulled in as a dependency is your problem, tracked by you, and it will not appear in the Drupal feed.

Coverage can also be withdrawn

Security coverage is not permanent. PSA-2026-07-22 removed advisory coverage from the QA Accounts module on the grounds that it prioritises ease of use over security and is intended only for sites that are not reachable from the internet.

That is the shape of the risk. A module you installed years ago under coverage can quietly lose it, and nothing on your site changes to tell you. Keeping an inventory of every installed project with its current coverage status and release stability is real recurring work, and it belongs in the retainer in writing.

Dependency and Platform Upgrades Are Support Work

The most commonly excluded item in a Drupal support contract is the one that eventually decides whether the site survives. Drupal’s platform requirements move, and they move in steps that need a hosting change rather than a composer update.

On PHP, Drupal 10 requires at least PHP 8.1 , while Drupal 11 has required PHP 8.3 as a minimum since 11.1. PHP 8.5 support arrived in Drupal 11.3, and Drupal 12.0 supports PHP 8.5 only. That last detail matters more than it looks: a site sitting comfortably on PHP 8.1 today is two forced platform moves away from Drupal 12.

The database requirements moved just as far. Drupal 11 needs MySQL 8.0 or later, MariaDB 10.6 or later, PostgreSQL 16 or later, or SQLite 3.45 or later. Drupal 10 accepted MySQL 5.7.8, MariaDB 10.3.7 and PostgreSQL 12. A managed host still serving MySQL 5.7 is a blocker on the upgrade path, not a detail, and our note on what actually runs Drupal well covers what to move to.

The Drupal 10 End of Life Is Already a Retainer Problem

Drupal 10 reaches end of life on 9 December 2026 , and Drupal 12 is released in the same week, beginning 7 December 2026. Security support for the 11.3.x and 10.6.x branches ends at that point too. As of September 2026 the branches receiving security releases are 11.4.x, 11.3.x and 10.6.x.

Read against the calendar, that is roughly three months. Any Drupal 10 site without a costed upgrade plan in September 2026 is going to spend December either paying a rush premium or running unsupported, and the second option is a decision somebody should make deliberately rather than by drift.

A retainer worth its fee should already have produced four things: a current upgrade status report, a deprecated code scan of the custom modules and theme, a readiness check on every contributed module against Drupal 11 and 12, and a written estimate. If your supplier has produced none of those by now, that is the finding. Our breakdown of Drupal migration costs, options and deadlines sets out what the work involves, and the same planning sits inside our website development engagements.

Backups Are Worth Nothing Until a Restore Is Tested

Almost every Drupal support contract promises backups. Very few promise a restore, and the distinction is the entire value of the line item. The NCSC puts it plainly in its guidance for small organisations: once you have made your backup , you need to know how to restore it and to check that it contains everything important.

A Drupal restore has three moving parts, and partial backups fail on the second one with dreary regularity. You need the database, the public and private files directories, and the configuration. A backup that captures the database but not the files directory restores a site with intact content and no images, which looks like a working site to a monitoring script and like a disaster to a customer.

Ask for a dated restore test, performed into a scratch environment, with a written note of how long it took and what was missing. Quarterly is a reasonable frequency for most sites. If a supplier has never done one, they do not know their own recovery time, and neither do you.

Uptime and Error Monitoring, and What Uptime Really Measures

There is a large gap between a server being up and a site working, and Drupal sits squarely inside it. A PHP fatal error, an exhausted memory limit, a failed database connection or a broken cache rebuild all produce a page that a naive check reads as a success or a plain 500 that nobody is watching for.

Monitoring measured at the server tells you the box responds. Monitoring measured at the application requests a real page, follows redirects, and asserts that expected content is present in the response body. Those are different products with different prices, and a support proposal that says “uptime monitoring” without saying which one is describing the cheaper of the two.

Underneath that sits Drupal’s own log. The recent log messages report and the PHP error log are where a failing cron run, a deprecated function or a module throwing exceptions on every request will show up long before a visitor complains. Somebody has to read them on a schedule. Our piece on uptime SLAs that mean something covers how the percentages translate into permitted minutes.

Reading a Drupal Support SLA Critically

Most support SLAs are written to be agreed rather than to be used, and they are agreed because they are read quickly. Three clauses carry nearly all the weight, and a careful reading of them takes ten minutes.

Response time is not resolution time

An SLA promising a two hour response usually promises that somebody will acknowledge the ticket within two hours. It does not promise that anybody looks at your site. Suppliers who mean it commit to a resolution target, or at minimum to a target for a diagnosis and a workaround, with the fix time stated separately.

Where the work genuinely cannot be time boxed, an honest contract says so and commits to continuous effort until resolution instead. That is a real commitment. “Two hour response” on its own is a commitment to send an email.

Severity definitions decide everything

Every SLA has a severity table, and the supplier usually assigns the severity. That is the loophole. If the definition of Priority 1 is “site unavailable”, then a checkout that fails for a third of customers is Priority 3 and gets looked at next week.

Write the definitions around business impact rather than technical state, and include worked examples in the contract: a failing payment step, an inaccessible admin login, a broken contact form on the enquiry page. Then agree who assigns severity and how you dispute an assignment.

Cover hours are not business hours

“Business hours” and “cover” mean different things and are often used interchangeably. Cover is the period during which the clock runs and someone is obliged to act. If cover is 09:00 to 17:30 on working days, an advisory published at 1700 UTC on a Wednesday in December is picked up the following morning at the earliest.

For Drupal specifically, notice that the core security window opens at 1600 or 1700 UTC. A UK supplier with cover ending at 17:30 is structurally at the edge of it, so out of hours arrangements for Highly Critical advisories need to be named separately and priced.

What Counts as an Incident, and What Is Excluded

The exclusions section is where a retainer quietly becomes cheaper than it looks. Common exclusions are entirely reasonable in isolation and unreasonable in combination: third party hosting faults, issues caused by client staff, problems in modules not installed by the supplier, anything to do with a paid theme, and anything the supplier classifies as a change rather than a fault.

That last one is the sharp edge. If a bug fix requires a configuration change, and configuration changes are billable, then almost any fault can be reclassified into the billable column. Ask directly how the supplier distinguishes a fault from a change, and ask for two examples of each from their own recent work.

Also check what happens with third parties. When the payment gateway, the CRM connector or the host is at fault, does the supplier coordinate the fix, or does the ticket close as out of scope? Coordination is genuine work and worth paying for, but only if the contract says it happens.

The Three Retainer Models, Compared Honestly

Almost every Drupal support arrangement is one of three shapes, and each is a reasonable answer to a different situation. The mistake is buying one shape while expecting the behaviour of another.

Fixed hours a month

You buy a block of hours, say eight or sixteen, and the supplier applies them to whatever you ask for. It is transparent, it is easy to compare between quotes, and it suits an organisation with a steady trickle of small changes and someone internal capable of prioritising them.

Its weakness is that maintenance competes with features for the same pool. In a busy month the security patching quietly loses to the campaign landing page, because the person spending the hours has a deadline and the patch does not feel like one. If you buy this model, ring fence a portion of the hours for maintenance in the contract itself.

Unlimited fixes plus quoted changes

The supplier absorbs maintenance and small fixes for a flat monthly fee, and anything above an agreed threshold is quoted separately. This is the model most agencies push, and for a stable site with a nervous owner it is genuinely the right answer, because it converts a variable risk into a fixed line in the budget.

Its weakness is the boundary. “Small fix” is undefined until somebody needs one, and the threshold moves depending on how the month is going. Insist on a written definition, ideally a time box such as anything under thirty minutes, and a monthly report showing what was absorbed.

Pure time and materials

No retainer, a day rate, and work when you ask for it. This is the honest choice for a low risk site with an owner who genuinely will chase updates, and for organisations with in house capability who need occasional specialist help rather than cover.

Its weakness is that nothing proactive ever happens, because nobody is paid to look. Time and materials also queues badly: you are competing with retained clients for the same engineers, so the response on a bad day is measured in weeks rather than hours.

The Incentive Problem in Unmetered Support

Unmetered support has a structural problem that nobody in the industry enjoys discussing. If the supplier is paid the same regardless of how many hours a site consumes, then every hour spent on your site reduces their margin, and the rational commercial behaviour is to spend as few as possible.

That does not usually show up as neglect. It shows up as a preference for the quick fix over the correct one, for suppressing a symptom rather than tracing a cause, and for deferring the module upgrade that would take a day of regression testing. It also shows up in the reverse direction on cheap plans, where the fee only makes sense if the site is genuinely never touched.

The counterweight is a reporting obligation. A monthly report listing hours consumed, updates applied, advisories assessed and tickets closed makes the consumption visible to both sides, and makes an unprofitable account a conversation rather than a slow decline in service. Any supplier confident in the model will agree to it. A supplier who resists is telling you what the model is really for.

What Good Looks Like Operationally

Three technical practices separate a Drupal supplier who can support your site safely from one who is improvising. None of them are exotic, and all three are easy to ask about.

Composer, or nothing

Drupal’s own documentation is blunt about mixing update methods, warning that sites may encounter critical update problems if Composer updates are combined with other approaches, and that once Composer manages one module it must also manage core. A supplier still uploading module folders over FTP will eventually delete a vendor directory that a contributed module depended on.

Ask whether composer.json and composer.lock are in version control, and whether Composer runs on production or the built artefact is deployed. Either answer can be right. Not having an answer cannot.

A staging environment that matches production

A staging site running a different PHP version, a different database version or a different set of modules does not test anything useful. The point of staging is to let a security patch fail somewhere that does not cost money, and it only does that if the two environments match on the axes that break.

Ask how staging is refreshed from production, how often, and whether it holds a sanitised copy of real content. A staging site with three test nodes will not reveal the update that breaks a view over forty thousand rows.

Configuration in version control

Drupal keeps configuration in the database by default , and the configuration management system exists to export it to files that can be committed, reviewed and imported into another environment. A team using it can reproduce the site’s settings deterministically. A team not using it is clicking through admin screens on production and hoping.

This is the single clearest signal in a supplier conversation. Ask how a change made on staging reaches production. If the answer is a description rather than a pause, the rest of the conversation is usually fine.

If they cannot describe deployment, that is the answer

There is no polite way to put this. A supplier who cannot describe, in one unhurried minute, how code moves from a developer’s machine to your live site is telling you that deployments are improvised. Improvised deployments are the reason security patches get delayed: nobody wants to run the risky manual process on a Wednesday evening.

The Offboarding Clause Nobody Reads

At some point you will change supplier, and the clause governing that moment is written while everybody is friendly and read while nobody is. It should say four things plainly.

Who owns the code, including custom modules and theme work, and under what licence. Where the repository lives and how access transfers. That a full export of database, files and configuration will be provided in a stated format within a stated number of working days. And that DNS, hosting and third party service credentials are handed over rather than held.

The failure mode is not usually malice. It is a supplier who hosts your site on their own account, holds the only copy of the repository, and takes six weeks to respond because you are no longer a paying client. Ask for the offboarding clause before you sign, and treat reluctance as information.

Drupal 7: End of Life, Extended Support, and the Gap Between Them

Drupal 7 security support ended on 5 January 2025 . The community stopped producing patches, and the enormous contributed module ecosystem that made Drupal 7 useful stopped being maintained alongside it.

The Drupal Association runs an Extended Security Support Provider Program, and HeroDevs and Tag1 Consulting are the certified vendors under it. Buying that support is a legitimate decision for an organisation that genuinely cannot migrate this year, and it is meaningfully better than nothing.

What it does not do is make the site secure in the ordinary sense. A commercial vendor patches the vulnerabilities it finds or is told about, on its own schedule, for the module set it has agreed to cover. It does not restore the public advisory process, it does not cover every contributed module you happen to have installed, and it does not extend to the external libraries those modules depend on. Extended support is a controlled way to run an unsupported platform, and a support contract is not a synonym for being secure.

If you are on Drupal 7 in September 2026, the honest advice is to spend the money on migration rather than on rent. Our 2026 guide to Drupal web development covers the platform as it stands, and the deeper detail on the advisory process sits in our note on Drupal security, advisories and real risk .

Content Support and the Change Budget

Two items get squeezed out of support contracts because they are hard to bound, and both are the ones clients actually notice.

Content and editorial support means somebody who can add a content type, fix a view that stopped filtering correctly, retrain an editor after a staff change, or work out why an image style is cropping faces. It is low drama and high frequency, and a retainer without it produces a client who stops asking and starts working around the site.

The change budget is the other half. Every site accumulates a queue of small work: a field on a form, a redirect after a page moves, a change to who receives an enquiry. Naming a monthly allowance for that queue, in hours, is what stops it turning into a quarterly emergency project. Two to four hours a month is a realistic figure for a small site, eight to sixteen for a busy one.

What Drupal Support Costs in the UK

The numbers below are our house estimates for 2026, based on UK agency work rather than a published survey, and they assume a supplier doing the eight activities described above rather than a monitoring subscription with a support inbox attached.

In prose: a small brochure site sits at roughly £250 to £600 a month, which buys advisory monitoring, a monthly patch cycle, backup verification and an hour or two of changes. A mid sized site with integrations runs about £700 to £1,800, because every integration adds a regression surface that has to be retested after each core update. A complex or multilingual site with custom modules starts around £2,000 and reaches £6,000 or more.

Monitoring only arrangements, where a supplier watches the advisories and tells you what applies but does not deploy, sit lower at roughly £250 to £450 a month. Set those bands against UK agency day rates of £600 to £900, and a £1,500 retainer buys somewhere near two engineer days. The rate detail is in our note on Drupal developer rates, skills and vetting , and the wider budgeting picture in software maintenance cost .

What Moves a Site From One Band to the Next

The instinct is to price support by traffic, and traffic is very nearly irrelevant. A site serving two hundred thousand visits a month with twenty modules and no integrations is cheaper to support than a site serving two thousand with a CRM connector, a payment gateway and a custom migration.

Three things actually drive the cost. Module count, because every contributed module is an advisory feed to watch and a compatibility risk at every core update. Integration count, because each one is an external contract that can change under you and a regression test that has to be rerun. And editorial volume, because a busy editorial team generates support questions, permission changes and content model tweaks at a steady rate.

Custom code is the multiplier across all three. A site with twelve thousand lines of custom module code needs a deprecation scan and a regression pass at every minor release, which is a day of work that a purely contributed site does not incur. That is where the top band comes from, and it is the work our software development engagements are usually asked to absorb.

Questions to Ask a Prospective Supplier

Six questions, and the answers that should worry you.

Which Drupal version and PHP version is our site on now, and what is the upgrade path? An answer that requires them to go and look is fine. An answer that arrives a week later is not. How do you find out that a security advisory applies to us? “We monitor drupal.org” is weak; a per site module inventory is the answer you want.

Walk me through your deployment process. Hesitation here is the strongest negative signal in the whole conversation. When did you last restore this site from backup? “We take daily backups” is not a response to that question. What is excluded from the retainer, and how do you decide whether something is a fault or a change? And finally: if we leave, what do we get and how quickly?

What Happens When There Is No Retainer

This is a sequence rather than a warning, and it runs at about the same pace on every unsupported Drupal site.

For the first few months nothing happens, which is the problem, because it teaches everybody that nothing needs to happen. Somewhere between month six and month twelve the update backlog crosses the point where updates stop being individually safe, because a module now needs a newer core, which needs a newer PHP, which the host does not offer. Applying one patch has become a project.

Then the site drifts out of platform support entirely, and a browser or PHP change breaks something visible. The repair now starts with an upgrade nobody budgeted for, quoted as emergency work, and the parts of the site with no documentation are rebuilt rather than fixed. If a breach occurs on the way through and personal data is involved, the ICO expects notification within 72 hours of becoming aware where the breach is likely to result in a risk to people’s rights and freedoms, which is a deadline you meet with logs and backups you either have or do not.

The recovery bill is reliably several times the retainer that would have prevented it, and the difference is not the labour. It is that planned work happens on a Tuesday with a rollback plan, and emergency work happens on a Sunday without one.

Getting the Scope Right Before You Sign

The point of all of this is not to make you distrust suppliers. It is to make the comparison between two proposals mean something, because at present most Drupal support quotes are incomparable by design: different words, different exclusions, and no shared definition of what the monthly work is.

Take the eight activities, the Drupal risk bands, the three retainer models and the six questions, and put them against whatever is on your desk. Whatever survives that is a real proposal.

Mecanik supports Drupal sites as part of our website development and software development work, and the first engagement is usually an inventory rather than a fix, because most sites arriving with us cannot say which of their modules are still covered by the security advisory feed .

Frequently Asked Questions

What should a Drupal support retainer include? Eight activities: security advisory monitoring against your exact module set, core and contributed module updates on a defined cycle, dependency and PHP platform upgrades, backup verification with tested restores, uptime and application error monitoring, performance regression checks, editorial support, and a named change budget in hours. A contract naming only four is incomplete, and the four usually missing are restore testing, performance checks, platform upgrades and the change budget.

How much does Drupal support cost per month in the UK? As a house estimate for 2026, a small brochure site runs roughly £250 to £600 a month, a mid sized site with one or two integrations £700 to £1,800, and a complex multilingual site with custom modules £2,000 to £6,000. Monitoring only arrangements sit around £250 to £450. Against UK agency day rates of £600 to £900, a £1,500 retainer buys about two engineer days.

When does Drupal release security patches? Drupal core security releases go out in a window on the third Wednesday of the month, starting at 1200 America/New York, which is 1600 or 1700 UTC depending on the season. Contributed projects have a security release window every Wednesday. Highly critical core releases are preceded by a public service announcement so site owners can arrange cover in advance.

Is Drupal 7 extended support the same as being secure? No. Drupal 7 security support ended on 5 January 2025, and the Drupal Association certifies HeroDevs and Tag1 Consulting under its Extended Security Support Provider Program. Those vendors patch what they cover, on their own schedule, for an agreed module set. It does not restore the public advisory process, cover every contributed module you have installed, or extend to external libraries.

When does Drupal 10 reach end of life? Drupal 10 reaches end of life on 9 December 2026, in the same week that Drupal 12 is released, beginning 7 December 2026. Security support for the 11.3.x and 10.6.x branches ends at the same point. Drupal 12 supports PHP 8.5 only, so sites on older PHP versions need a hosting change before the upgrade, not after it.