10 Questions to Ask Before Signing an Enterprise Drupal Support SLA

An enterprise Drupal support SLA looks reassuring on paper. Response times, uptime percentages, and severity tiers. The trouble is that most of these agreements are tested for the first time during a real incident, at which point the gaps become clear. After years of reviewing, negotiating, and operating under these agreements, the failures I see rarely come from missing clauses. They come from clauses that were never defined precisely enough to act on.

These are the ten questions I would put to any vendor before signing, and the answers a credible one should give.

1. What does the escalation path actually look like?

This is the part of the SLA that deserves the most scrutiny, and it is the one buyers most often overlook. In a large enterprise, you typically have multiple vendors, multiple agencies, internal IT, and internal marketing all touching different applications. When an incident or a request comes in, whether critical or a routine feature, the agreement needs to define exactly how it gets triaged, analyzed, fixed, tested, and deployed, and who owns each of those steps.

Ask the vendor to show you the escalation tree, not describe it. If they cannot produce one, you are looking at a future communication gap.

2. What does "the Drupal application" include, and what is excluded?

An SLA that covers "the Drupal application" without further definition is where things fall apart. Does that include custom modules? Third-party integrations? The hosting infrastructure? And who is responsible for each of those pieces? Enterprises should push for a detailed scope matrix with clear lines of escalation responsibility.

A precise exclusions list is a sign of a robust agreement, not a weak one. Typical and reasonable exclusions are third-party integrations and APIs the vendor cannot control, such as Salesforce CRM connectors, Google Analytics, and external or proprietary data feeds the enterprise built itself, along with performance degradation caused by client-initiated code or changes. Anything third-party or anything homegrown is normally out of scope, because the vendor cannot control what it did not build and does not operate. A vendor who hides this list, or has no list at all, has left the boundary for you to discover during an incident.

3. How does the SLA separate response time from resolution time?

Response is the first acknowledgment of a request. Resolution is when the issue is actually fixed. An SLA can promise a response within a business day, or within an hour for critical issues, and still leave resolution completely open. The honest complication is that resolution time is sometimes hard to commit to, because you do not always know the depth of a problem until you are inside it.

The right structure is varying levels of both response and resolution time based on severity, with response commitments firm and resolution targets defined as closely as possible, plus an explicit caveat that complex issues may take longer.

4. Who decides what counts as severe?

Severity cannot be defined by one side alone. There needs to be a joint classification process between the client enterprise and the agency, so that everyone agrees in advance on how to assess business impact, which users are affected, and whether there is any security or data exposure risk involving PII or PHI. Priority one is something impacting business operations with no workaround. At the other end of the scale sits an issue like a single content author locked out of Drupal, while a colleague can still get in and make the fix.

If the contract lets the vendor unilaterally downgrade severity, the response targets attached to those severities mean very little.

5. What happens when resolution takes longer than promised?

Sometimes, a priority one ticket simply cannot be resolved within its target window, even with an immediate response. The mitigation is a communication tree written into the agreement: status updates every hour, or every 30 minutes, to the right stakeholders for as long as the incident runs. Structured communication during an overrun is often what preserves trust when the resolution clock has already been missed.

6. How does the agreement handle Drupal's weekly security cycle?

This is where a Drupal-specific SLA separates itself from a generic support agreement. The Drupal Security Team publishes advisories on Wednesdays, covering new issues, changes, and security patches that may or may not apply to your application. The SLA should specify a response window tied to that cycle. For a critical advisory, which happens very infrequently, the patch should be applied within 24 hours, or within 24 to 72 hours depending on severity, and that commitment should be written into the agreement. For minor security releases, which are far more common, within a week or bundled into the next scheduled deploy is the practical standard.

A generic agreement has no concept of this cadence. As a Drupal Diamond Certified Partner and one of the top 20 contributors to the project worldwide, we treat this weekly rhythm as a core part of the engagement, not an afterthought. A Drupal agreement that lacks it is generic in everything but name.

7. Who monitors advisories, tests patches, and pushes them to production?

Patching commitment is only half the picture. The SLA should also define who is monitoring the security advisories and the contributed modules, who is responsible for rolling fixes into the next release, and what the testing protocol is. Are patches applied to staging with the client responsible for validating them, or is the vendor proactively testing and releasing as needed? The roles and responsibilities around how updates reach production need to be written down, not assumed.

8. How are major version upgrades planned?

Incremental and major version upgrades should be factored into the agreement, not treated as surprise projects. We are currently moving many of our clients to Drupal 11, and the difference between a controlled upgrade and an emergency one is lead time. The agreement should scope adequate time and work for upgrades well ahead of the version's end of life, so the migration never becomes urgent.

9. What does the uptime guarantee cover, and what does it exclude?

A 99.9 percent uptime guarantee allows roughly eight hours of downtime per year. What it covers is downtime caused by the application and its supporting infrastructure: a critical error, a full outage, malicious or bot activity taking the site down, or a failed update. What it reasonably excludes are outages at external providers such as AWS or Cloudflare, which no Drupal vendor can control, and scheduled maintenance windows, deploys, and migrations, which are planned for off-hours and weekends.

From the client's perspective, the test is precise. The SLA should state exactly what the guarantee covers and what it does not, so neither side is interpreting it for the first time during an outage.

10. What does accountability look like when something goes wrong?

Three mechanisms matter. First, a written incident report after every significant incident, stating what happened, how it was fixed, and what has been done to make sure it does not happen again, including the future-proofing steps. Second, service credits for downtime that exceeds the agreed thresholds for reasons within the vendor's control. If service credits are not part of the standard SLA, that is worth questioning, because they should be. Third, a contractual right to exit if excessive SLA breaches accumulate, without penalty, so the client is protected and free to move to a vendor who can deliver.

Alongside these, a monthly or quarterly review of how the SLA is working in practice keeps the agreement honest over the life of the engagement.

Where SLAs really fail: the 2 a.m. test

Here is where we land after operating under these agreements for years: SLAs do not usually fail in the contract language. They fail in operational readiness. In a real incident at 2 a.m., a capable 24/7 team responds. Where it falls is unclear, escalation of ownership, communication gaps, missing access or credentials, and the absence of a runbook covering documented procedures, where the credentials live, how to deploy, and where the code lives.

An SLA fails when there is no clear escalation ownership, no playbook, and ambiguity about what is covered by 24/7 on-call versus business hours. The failure mode is almost always the same: the things covered in the first nine questions were agreed in principle but never documented, and the on-call team discovers the gap mid-incident. Documentation, access, and procedures are what turn a contractual commitment into an operational one.

Put your current SLA through these questions

If you are evaluating a Drupal support partner or holding an existing agreement that has never been stress-tested, run it against these ten questions. Where the answers are vague, that is where a strong agreement earns its keep.

Jon Stewart is Director of Product & Client Enablement at Vardot, bringing over 15 years in product leadership, digital platforms, and client-focused delivery. He has led the development and launch of enterprise-grade Drupal platforms across a wide range of complex web applications, with a hands-on, data-driven approach to product strategy and customer discovery. He is President of ZenSource and a member of the Forbes Technology Council.