Executive review: what your leadership team should know about Drupal risk
In most organisations, Drupal risk sits with IT or with the agency that looks after the website. The board hears about it when something breaks or when an upgrade needs a budget. That split feels sensible, because the work is technical and the people closest to it understand it best.
However, an agency can find and report a risk, but it can’t decide how much of that risk the business is willing to tolerate. Only leadership can make that call. If nobody on the board owns it, fixes and upgrades wait until someone asks for them. Until then the website stays exposed, even though no one agreed to accept that risk.
Why Drupal risk gets treated as a technical issue
Drupal problems arrive in technical language. A security advisory names a module, a type of vulnerability and a risk score. An end-of-life notice names a version number and the date after which it gets no more security fixes. Neither says what the business stands to lose.
The wider data shows the same gap. The UK Government’s Cyber Security Breaches Survey 2025/2026 found that 31% of UK businesses have a board member or trustee responsible for cyber security. For large businesses the figure is 68%, so about a third of them still have no one in that role at board level.
The same survey found that only 15% of businesses review the risks posed by their immediate suppliers. The agency that runs your website is one of those suppliers, and a good one should make that review easy.
Software flaws and third parties both appear often in breaches. Verizon’s 2026 Data Breach Investigations Report, based on more than 22,000 confirmed breaches, found that exploiting a software vulnerability was the most common way in, at 31% of breaches. A third party was involved in 48% of them.
Drupal security risk decisions only leadership can make
Some Drupal decisions are technical and belong with the team that does the work. Others set how much risk the business accepts, and those belong with leadership. The National Cyber Security Centre’s Cyber Security Toolkit for Boards asks whether the board has “clearly set out what types of risks it would be willing to take, and those which are unacceptable”.
For a Drupal website, that question turns into four decisions:
- How fast security fixes go live: for example, critical fixes within days and lower-risk fixes in the next planned release.
- Whether to run an unsupported version: Drupal 10 reaches end of life on 9th December 2026, and after that date the Drupal project makes no new Drupal 10 releases, including security fixes.
- Who approves a change: this could be the agency, an internal product owner or a named director.
- How upgrades are paid for: either as planned running costs or as a project that needs a new business case each time.
Each choice has a cost. A fast approval route uses more support time. Running an unsupported version for a few months saves money now, while the business takes on the risk for those months. Both can be sound decisions when someone with the authority makes them on purpose.
Two ways to manage Drupal updates
There are two common ways to run Drupal updates, and leadership should choose between them with the trade-offs in view:
- Trigger-based updates: the site changes when something requires it, such as a security advisory that affects it or a version that is close to end of life. This keeps support costs down and changes fewer things at once. The downside is that each upgrade gets bigger, because Drupal doesn’t let a site skip a major version.
- Scheduled updates: the site moves to each new release on a fixed calendar. This keeps every step small and predictable. It costs more support time each month, including for releases that change nothing the business would notice.
Our Drupal support follows the trigger-based model. We check each Drupal security advisory against the modules your website uses, and tell you when one affects it. We track end-of-life dates for Drupal core, for PHP, the programming language Drupal runs on, and for other key software your website depends on, and give you an upgrade plan well before each deadline. You decide when we act, and we apply a security fix once you approve it, so the risk decision stays with the people accountable for it.
What a good Drupal risk report to the board looks like
A board needs a short report that turns technical status into business decisions, with no module names. A useful quarterly report answers five questions, and leadership teams can use them as its agenda:
- Which support end date comes next for our Drupal platform, and is the upgrade funded?
- Which security advisories affected us this quarter, and did each fix meet our agreed target time?
- Which fixes or upgrades are waiting for approval, and since when?
- What custom code and external libraries do we run that the Drupal Security Team doesn’t cover?
- What decision do we need from the board this quarter?
The fourth question is the one most often missed. The Drupal Security Team only issues advisories for projects hosted on Drupal.org. Even then, it only covers contributed modules, the add-ons built and shared by the Drupal community, when they’re stable releases and their maintainers have opted in to its coverage. Custom code written for your website sits outside that coverage, so someone in your team or at your agency has to own it.
An example came on 21st October 2026, when the PHP project released fixes for two critical flaws that can let an attacker run code on a web server without logging in. The National Cyber Security Centre told organisations using any version of PHP to update. PHP 8.1, the oldest version Drupal 10 supports, no longer gets official fixes, so websites still on it should move to a supported PHP version. Leadership needs to know who owns PHP updates, and how fast they happen, before an alert like this arrives.
What to put in place first
Most organisations sit at one of three stages, and the stage decides where to start:
- No owner: nobody at board level owns website risk. Start with step 1 below.
- An owner but no rules: someone owns the risk, but fix times and update choices are agreed case by case. Start with steps 2 and 3.
- An owner, rules and a report: leadership gets a regular report and makes decisions from it. Check that the report covers the five questions above.
Start with ownership, then agree the rules, then set up the reporting:
- Name one director who owns website risk, and add the website to the cyber risk register.
- Agree target times for applying security fixes, set by how severe each one is.
- Choose trigger-based or scheduled updates, and record why.
- Put the next end-of-life date in the budget plan. For Drupal 10 websites, that date is 9th December 2026.
- Ask your agency for the quarterly report above, written in plain words.
The question for your next board meeting
Most of this uses tools the business already has, such as the risk register and the board pack. The technical work stays with the people who do it, while the risk decisions move to the people who answer for them.
If your website runs Drupal 10, the next decision has a fixed date. Support ends on 9th December 2026, and an upgrade needs time to plan, test and approve before then. Our support work runs under ISO 27001, the international standard for information security management, so book a Drupal Platform Review and we’ll show you which decisions your leadership team needs to make before that date.
Who on your leadership team could say today which version of Drupal your website runs, and when its support ends?
Frequently asked questions
Who is responsible for Drupal security in an organisation?
The agency or development team is responsible for finding and applying Drupal security fixes, and leadership is responsible for deciding how much risk the business accepts. The National Cyber Security Centre’s Cyber Security Toolkit for Boards says boards should set out which risks they are willing to take and which are unacceptable. In practice, a named director should own website risk and approve the rules the agency works to.
Can a business keep running Drupal 10 after end of life?
A business can keep a Drupal 10 website running after 9th December 2026, but the Drupal project makes no new Drupal 10 releases after that date, including security fixes. Running an unsupported version is a decision to accept risk. A named director should approve it, record it in the cyber risk register and set a date for the upgrade.
Is Drupal secure?
Drupal has a dedicated security team that publishes advisories and fixes for Drupal core and for contributed modules that have opted in to its coverage. How secure a Drupal website is depends on how quickly those fixes are applied. It also depends on custom code and external libraries, which the Drupal Security Team doesn’t cover.
Who should approve Drupal security fixes?
The agency or development team should check each Drupal security advisory and recommend whether and when to apply the fix. Leadership should agree target times for each level of severity in advance, so routine fixes go ahead without a new decision each time. A named person should approve anything outside those rules, such as delaying a critical fix.
What should a Drupal risk report to the board include?
A Drupal risk report to the board should include the next support end date for Drupal and PHP, and whether the upgrade is funded. It should list the security advisories that affected the website, whether each fix met its agreed target time, and any fixes still waiting for approval. It should also name the custom code outside Drupal Security Team coverage and end with the decisions the board needs to make.
Sources
- Cyber Security Breaches Survey 2025/2026, Department for Science, Innovation and Technology, published 30th April 2026 (2,112 UK businesses, fieldwork August to December 2025)
- 2026 Data Breach Investigations Report, executive summary, Verizon (more than 22,000 confirmed breaches, October 2024 to November 2025)
- Cyber Security Toolkit for Boards, risk management, National Cyber Security Centre
- Critical security issue affecting PHP, National Cyber Security Centre, 21st October 2026
- PHP news: critical security release, PHP.net, 21st October 2026 (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, CVE-2026-109618 and CVE-2026-109619, no official fix for PHP 8.1 and older)
- Drupal core release schedule, Drupal.org (Drupal 10 end of life, monthly security window)
- Security advisory process and permissions policy, Drupal Security Team
- Upgrading from Drupal 8 or later, Drupal.org
- PHP requirements, Drupal.org