Blog
No CMS is legally mandated.
Six requirements that weigh more heavily for government and education than elsewhere, from accessibility to multilingual support.
No CMS is a legal requirement for government and education.
The choice comes down to six requirements that weigh more heavily in this sector than elsewhere: accessibility with a statement that holds up, multilingual support, rights and editorial workflows, procurement rules, vendor independence and the long-term maintenance rhythm.
You need to be able to account for those requirements publicly, not just meet them.
Drupal does well on those six points, but not better than every alternative on all six.
I have written out the general comparison between the two best-known systems separately in choosing Drupal or WordPress for your website, here I look at what the public sector adds on top.
Accessibility: the statement makes it checkable
For government sites, accessibility is not an ambition but an obligation with public accountability.
Directive (EU) 2016/2102 has been transposed in Belgium at several levels.
Federal bodies are covered by the act of 19 July 2018, with FOD BOSA as the supervisory authority.
Flemish authorities and institutions fall under the Bestuursdecreet of 7 December 2018, and Wallonia and Brussels have their own regulations with their own oversight.
Which regime and which authority apply to you is best checked with a lawyer.
In the Netherlands it runs through the Besluit digitale toegankelijkheid overheid, which was called the 'Tijdelijk besluit' until 1 July 2023 and has had its legal basis in the Wet digitale overheid since that date.
In both countries every site needs an accessibility statement and a channel for reporting a problem, who needs such a statement and what it should contain is covered in a separate article.
The standard is EN 301 549, which refers to the WCAG success criteria, and in practice you work towards WCAG 2.2 level AA.
Since 28 June 2025 the European Accessibility Act, directive 2019/882, also applies, covering a defined group of products and services.
An institution with a webshop or e-books can therefore fall under two regimes, so have a lawyer check what applies to you.
For the CMS choice, what matters most is what you get for free.
Drupal has had accessibility as a core principle for years, and the editorial environment itself is also operable by keyboard and screen reader.
You can read exactly what that covers in why Drupal is more accessible than most CMSes.
It is not automatic: theme, custom components and content determine most of the result.
The difference between CMSes lies mainly in whether the accessible choice is also the easiest one for your editor.
See digital accessibility.
Multilingual support: the configuration has to keep up
Multilingual support is the point where Drupal differs most clearly from most alternatives.
Four modules in the core do the work: Language, Interface Translation, Content Translation and Configuration Translation.
That last one is why government sites end up here, because it also lets you translate your views, menus, field labels and system text.
In many other systems that is a paid extension or manual work in the code, and you only notice when the French version has to go live.
What it does not solve: translation stays human work and costs time and budget per language.
If you only need one language, this is not an argument in Drupal's favour.
Permissions and workflows: who can do what, and who signs off
Drupal handles permissions and editorial approval in the core, without third-party modules.
You define roles, assign permissions per action, and use Workflows and Content Moderation to set up a chain from draft to review to published.
Every change is kept in the revision history.
For a university college with editors per faculty, that is the core of the system.
That model is built for many editors with separate responsibilities.
If you have two people who publish everything, you are mostly paying for the complexity.
Procurement and vendor independence
In a procurement process, open source mainly lowers the barrier to entry: no licence that ties you to one vendor, no user count that sets the price.
Drupal is released under the GPL, and multiple parties can bid on the same codebase.
That is why you see Drupal so often at governments, universities and colleges in Flanders and the Netherlands.
Five things that belong in your tender.
- The code sits in a repository owned by your organisation, not the vendor.
- Hosting, domain name and DNS are in your name, with your own administrator access.
- The configuration is stored as exportable configuration in Git, not only in the database.
- A new party can run the site locally using the repository and the documentation.
- An exit clause with a notice period, a handover file and a final knowledge transfer.
No licence cost does not mean cheaper.
The costs sit in the build and the maintenance, and upfront Drupal is usually more expensive than an off-the-shelf system.
What you get in return is that you will not have to migrate again at the next procurement round.
Open source is no guarantee against vendor lock-in
Lock-in is almost never in the CMS itself, but in what has been built on top of it.
A Drupal site can be just as locked in as a closed platform: an agency's own distribution, private modules without public source code, or custom code without tests or documentation.
The test for that is simple: give an independent party the repository and measure how much time they need to get the site running locally.
If that takes a day, your dependency is limited.
If it does not work without people from the current vendor, you know where you stand, whatever CMS sits underneath.
Long-term support: the rhythm from now to 2028
For a new project in the public sector, you build on Drupal 11 today.
The state of play on 12 September 2026:
| Version | Status |
|---|---|
| Drupal 7 | Out of support since 5 January 2025 |
| Drupal 8 | Out of support since November 2021 |
| Drupal 9 | Out of support since November 2023 |
| Drupal 10 | End of life on 9 December 2026, 10.6.0 is the last minor release |
| Drupal 11 | Current stable version, 11.4.x |
| Drupal 12 | Not yet released, planned for the week of 7 December 2026 |
Starting a new project on Drupal 10 therefore no longer makes sense: its end of life falls in the same week as the release of Drupal 12.
If your current site runs on Drupal 10, what the end of support on 9 December 2026 means is the first question to answer.
The version you build on is also not the version your site will run on in three years, so budget for an upgrade in your multi-year plan.
If you are still running an older version, that is a migration project.
When another CMS is the better choice
Drupal is the wrong choice as soon as the requirements above do not apply to you.
That happens more often than vendors admit.
- A small site in one language: ten pages and two editors are finished faster elsewhere.
- A well-defined product: for a learning platform or a library catalogue you buy existing software.
- No capacity for maintenance: without a maintenance budget every custom-built platform ages, and with Drupal that shows sooner because of the minor releases twice a year and a new major roughly every two years.
- A fully headless setup: Drupal can serve as the backend, but then you take on accessibility, SEO and performance of the frontend yourself.
So the question is not which CMS is better, but whether your organisation has the requirements Drupal was built for.
If you do not, you are paying for capabilities nobody uses.
How I can help
I have worked with Drupal for more than ten years, mainly for universities, government and industry: from the architecture of a new platform to reviewing an existing site before you renew.
An example from that field is the platform that connects Flemish universities with the Global South for VLIR-UOS.
My rate is 75 to 95 euros per hour and 650 to 800 euros per day, excluding VAT.
Facing that choice, or do you have a tender that could be sharper? Tell me about your situation.
I will look at your request and give you an honest picture of what is needed within 24 hours.
Frequently asked questions
Is Drupal mandatory for government sites?
No.
No CMS is legally prescribed for government or education.
What is prescribed are the requirements: the EN 301 549 standard with the WCAG success criteria, an accessibility statement, and a reporting channel for anyone who spots a problem.
Which system you choose is your own trade-off around accessibility, multilingual support, permissions and workflows, procurement rules, supplier independence, and the long-term maintenance rhythm.
Why do many universities and colleges choose Drupal?
Mainly for three things that are in core and therefore don't need to be bought or built separately: multilingual support all the way down to configuration, so views, menus, field labels and system text get translated too; roles with permissions per action; and editorial approval with Workflows and Content Moderation, where every change ends up in the revision history.
For an institution with editors per faculty or department, that's the core of the system.
On top of that, the GPL license doesn't bring per-user costs, and multiple parties can bid on the same codebase.
Which Drupal version do you choose for a new project in the public sector?
Drupal 11, today's stable version in the 11.4 series.
Drupal 10 reaches end of life on 9 December 2026 and 10.6.0 is the last minor release, so starting a new project on it already lands you an upgrade within a few months.
Drupal 12 comes out in the week of 7 December 2026, the same week as that end of life.
So build on 11, and factor an upgrade to 12 into your planning for the year after.
What do you put in a tender to stay supplier-independent?
Five points.
The code sits in a repository in your organisation's name, not the supplier's.
Hosting, domain name and DNS are in your name, with your own admin access.
The configuration sits as exportable configuration in Git, not only in the database.
A new party can run the site locally using the repository and the documentation.
And there's an exit clause with a notice period, a handover file and a final knowledge transfer.
Choosing open source doesn't arrange this on its own.
Does open source protect you against vendor lock-in?
Not automatically.
Lock-in almost never sits in the CMS itself, but in what's been built on top of it: an agency's own distribution, private modules without public source code, or custom code without tests or documentation.
The test for that is simple: give an independent party the repository and measure how long it takes them to get the site running locally.
If that happens within a day, your dependency is limited.
If it doesn't work without people from the current supplier, you know where you stand, regardless of which CMS is underneath.
When is Drupal the wrong choice for a school or local authority?
As soon as the requirements it was built for don't apply to you.
A small single-language site with two editors is finished faster elsewhere.
For a well-defined product, such as a learning platform or a library catalogue, you buy existing software.
Without a maintenance budget, every custom-built platform ages, and with Drupal that's felt sooner because of the minor releases twice a year and a new major roughly every two years.
In those cases you're paying for capabilities nobody uses.
A question about this topic?
Briefly describe your situation, and I'll let you know what's going on and what it would cost. No sales pitch.
