Open source CMS for the public sector

Why an open source CMS for the public sector needs more than a platform choice

A public body running dozens of agency or department sites has to meet accessibility deadlines while it keeps publishing. Drupal or WordPress can serve most public web estates, but the platform is rarely the deciding factor. The deciding factors are accessibility evidence, multi-site governance, the hosting boundary and release discipline, and each of them needs its own decision and its own owner before the build starts.

Drupal has no paid edition, and Drupal and its contributed modules are licensed under GPL-2.0-or-later, so the license is not the cost line in the budget. The cost sits in design and build, multi-site architecture, accessibility remediation, hosting, and ongoing support and security updates. Ask any partner to split its quote along those lines, and confirm which items are one-time and which recur each year. Drupal 10 reaches end of life on December 9, 2026, so any estate still on it needs a dated upgrade path in that quote.

For US state and local governments, the ADA Title II rule requires web content and mobile apps, including content supplied through contracts or licenses, to meet WCAG 2.1 Level AA. Entities serving 50,000 or more people must comply from April 26, 2027, and smaller entities and special districts from April 26, 2028. EU bodies face their own accessibility evidence duties, and federal and contracted work under NIST SP 800-53 adds control evidence for the hosting boundary. Confirm which of these regimes apply to each agency before you write the requirements, because they ask for different records.

Which accessibility, security and hosting rules shape a government CMS build

This table maps the accessibility, security, hosting and migration rules that most often shape a government Drupal or WordPress build, showing where each comes from and what it means for design, hosting and procurement. Read each row as a question to settle with your legal and procurement teams before scope is fixed, because applicability depends on your jurisdiction, population served and whether a cloud service holds federal information.

Requirement	Where it comes from	What it means for the build
WCAG 2.1 Level A and AA for web content	28 CFR 35.200 under ADA Title II, with compliance from April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts	Set WCAG 2.1 AA as the template standard, test theme components and editor output, and confirm which dates apply to your entity
Vendor-provided and contracted content	28 CFR 35.200 covers web content and mobile apps provided through contracts or licenses	Write accessibility terms into agency, contractor and third-party embed agreements, and require accessible content from editors and vendors alike
Hosting control catalog	NIST SP 800-53 Rev. 5 (Release 5.2.0), with SP 800-53B low, moderate and high baselines selecting 149, 287 and 370 controls and enhancements	Choose the baseline with your authorizing official or security office, then map hosting, logging, patching and access controls to the selected controls
FedRAMP scope for cloud services	FedRAMP Authorization Act (Pub. L. 117-263) and OMB M-24-15, covering cloud services that create, store or process federal information for an agency	Confirm whether a hosted CMS or CDN holds federal information on an agency's behalf before choosing a provider, since this can make authorization a procurement condition
Criminal justice information	FBI CJIS Security Policy v6.1, effective June 26, 2026, requiring FIPS 140-3 validated modules or FIPS 197 AES with 256-bit keys for CJI in transit and at rest outside physically secure locations	Keep CJI out of public-facing CMS content and forms unless the design meets the policy, and confirm encryption and vulnerability scanning cadence (at least monthly) with your CJIS officer
NIS2 public administration obligations	Directive (EU) 2022/2555 covers central government entities regardless of size and lists public administration as a high-criticality sector, with Member States free to extend it to local bodies	Confirm with your national authority whether your body is in scope, then document incident handling, supply chain and patching duties that the CMS hosting and support model must support
Drupal 10 end of life as a migration driver	Drupal 10 reaches end of life on December 9, 2026, per the Drupal core release schedule, and Drupal 10 requires PHP 8.1 or later	Plan the move to a supported Drupal line and PHP version before the date, and budget for theme rebuilds, since Drupal 6 and 7 themes cannot be migrated
Security release handling	Drupal security releases ship on the third Wednesday of each month, per the Drupal core release schedule	Write a patch window into hosting and support contracts so security releases are applied and evidenced on a predictable cadence

Which open source CMS fits public sector estates and why

Public sector web estates usually turn on multi-site governance, agency identity and a steady security release cadence. The options below differ mainly in how much of that governance the platform provides out of the box and how much your team must build and operate itself.

Drupal for multi-agency estates

Drupal is the usual choice when many agencies or departments share one estate and need separate editors, roles and content sections under central oversight. Drupal 11 requires PHP 8.3 or later, so confirm your hosting stack meets that before planning. Identity is handled through contributed modules: the SAML Authentication module lets the site act as a SAML service provider, and the OpenID Connect module can accept external providers and create accounts on first sign-in. Confirm that your agency identity provider and attribute mapping are tested against the exact module versions you plan to run.

Drupal CMS for content teams

Drupal CMS is a distribution built on Drupal core for marketers and content teams, bundling recipes, site templates and the Drupal Canvas visual page builder. It can shorten setup for agencies that want standard page layouts without custom front-end work. The trade-off is that a distribution adds its own configuration and update path on top of core, so you need a clear rule for how distribution updates reach each site. Ask your partner how recipes are reviewed before they are applied to production sites and which accessibility checks run on Canvas-built pages.

WordPress for smaller estates

WordPress suits smaller public estates with simpler editorial needs, such as a single department site or a handful of public information pages managed by a small team. Its editing experience is familiar to most staff and content is quick to publish. The main risk is the release cadence: WordPress.org states that only the most recent release in the 7.1 series is actively maintained, so each site must follow that series closely. Confirm how plugins are vetted, who owns updates during change freezes, and how multi-site governance would work if the estate grows.

Headless options for custom front ends

Strapi, Payload and Directus fit when a government team builds its own front end and needs the CMS to serve content through an API. Teams keep full control of templates and accessibility markup, but they take on responsibility for rendering, search and the public accessibility statement. Licence terms differ: Strapi publishes its Enterprise Edition under separate terms for components in ee directories, and Directus uses a Monospace Sustainable Core License that permits internal use and professional services but bars competing use. Read the licence with counsel before procurement, since a headless build changes who owns which accessibility obligations.

Matching the CMS to governance needs

The choice of platform matters less than whether it supports the governance model your agencies already run. Map each agency to its sections, editors, approvers and publication rights before comparing platforms, and record which roles can publish without review. Drupal supports this natively through its permission model, while WordPress and headless setups usually rely on plugins or custom code for the same control. Ask any partner to show a working role matrix for two agencies with different approval paths.

Patch cadence and version currency

Security fixes arrive on a fixed rhythm that your team must absorb, so the platform choice also sets your operating load. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, and Drupal 10 reaches end of life on December 9, 2026. Confirm which Drupal version each estate runs, when its upgrade is funded, and who signs off on emergency patches outside the normal cycle.

How security release cadence and end-of-life dates set the maintenance calendar

Drupal 11 is the branch most public sector estates should target. The core team publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so the monthly calendar is predictable. Feature releases for Drupal 11 arrive every six months, which lets version changes be scheduled into planned work.

Bugfix cadence: Apply bugfix releases on the first Wednesday of the month, first through staging, with a fixed test period before production.
Security cadence: Security releases arrive on the third Wednesday. Your written approval path should say who can approve an out-of-cycle deployment within the day.
PHP requirement: Drupal 11 requires PHP 8.3 or later. Confirm the hosting image supports it before any core update.
Next major version: Drupal 12 is scheduled for the week of December 7, 2026 and requires PHP 8.5 or later, so plan a dependency check for contributed modules and themes early.

Confirm that your written patch window names the release days, the staging test period and the individual who signs off on production changes.

Where the hosting boundary, identity and integrations sit in an agency estate

An agency web estate is split across several components, and each one has an owner, a data path and evidence that an assessor will ask for. Deciding who runs the shared hosting platform, who controls identity, and where form and case data travel is what determines the compliance scope before a single site is built. The cards below set out those boundaries in the order a review team usually walks through them.

Shared hosting platform and CDN

Central IT usually owns the cloud account, the Drupal or WordPress runtime, the database tier and the content delivery network that fronts public sites. Ask who holds administrative access to each layer and whether the hosting provider or the DeployOpen team can reach tenant data. The FedRAMP scope question starts here: a cloud service that creates, stores or processes federal information for an agency falls in scope, while a system used only for one agency's own operations on cloud infrastructure, not offered as a shared service, may fall outside it. Confirm the provider's authorization status and the region where caches and logs are written.

Central identity through SAML or OIDC

Editor and staff sign-in should run through the agency identity provider rather than local Drupal or WordPress accounts. The contributed SAML Authentication module lets a Drupal site act as a SAML service provider, and the OpenID Connect module can create accounts on first sign-in. Agencies should decide who owns the identity provider, how deprovisioning reaches the CMS within a set window, and which attributes map to roles. Confirm the module version and Drupal core version are supported together before you commit to a design.

Editor and publishing environment

Editors, approvers and vendor developers work in the authoring environment, which holds draft content that may include unpublished policy text or personal data entered into forms. Central IT typically owns the platform roles, while each agency owns its content and section permissions. Check whether staging and preview environments run in the same boundary as production, whether drafts are replicated outside it, and how contractor accounts are scoped and removed after each engagement. Keep a record of who can publish to which site.

Form, payment and case-system integrations

Forms on agency sites often pass citizen data to case management, payment or records systems. Each outbound connection is a data flow the agency must document, and it is the point where criminal justice information may enter scope. Where the case system handles CJI, the FBI CJIS Security Policy applies, and version 6.1 took effect on June 26, 2026 with stronger encryption and monthly vulnerability scanning expectations. Confirm which fields are sent, whether third-party form or payment scripts run on public pages, and which party holds the encryption keys.

Site search and indexing

Search on a public estate often runs on a separate index that copies page text, documents and sometimes form fields. Whether that index is self-hosted, managed by the hosting provider or a third-party SaaS decides where that copy lives and who can query it. Ask whether the indexer receives only published content, whether non-public pages are excluded, and how the index is rebuilt after a restore. Confirm the search product's hosting location and retention settings in writing, since these are not established by the CMS itself.

Logging, monitoring and backup

Access logs, audit trails, backups and security alerts each hold a copy of agency data, so each one needs an owner and a retention rule. Central IT usually runs the log pipeline, while the partner supports patch-level monitoring and restore testing. Ask where logs are stored, who can read them, how long backups are kept, and whether a restore has been tested in the same region as production. These records are often the first evidence an assessor requests when checking that the boundary behaves as documented.

Evidence accessibility and security reviewers ask a government web team for

This table lists the evidence reviewers usually request from a government web estate, what each item shows and which component or process produces it. Read it as a checklist to build during delivery rather than something to assemble when an assessor arrives. DeployOpen prepares these artifacts for independent assessors; it does not issue audit reports, attestations or certifications.

Evidence item	What it shows	Produced by
Accessibility conformance report against WCAG 2.1 AA	Which success criteria each template and page type meets, partially meets or fails, with the test date and method	Accessibility testing in the release pipeline plus manual audit by qualified testers
Public accessibility statement and feedback mechanism	The published conformance status, known exceptions, contact route and response process that the public can use	Content owner for each site, reviewed by legal and accessibility leads before publication
Audit results and remediation records per site	Defects found on each site, severity, owner, fix version and retest outcome	Site audit tooling, issue tracker and the remediation workflow agreed per agency
SSO configuration and access review records	How editors and administrators authenticate, which groups map to which roles, and periodic reviews of who still has access	Identity provider configuration, the SAML or OpenID Connect module settings and scheduled access reviews
Patch and release log with security update dates	When each Drupal or WordPress core and contributed module update was applied, and which advisories it addressed	Change records from the deployment pipeline, aligned to Drupal security releases or the current WordPress maintenance release
Backup and restore test records	That backups ran, were restored to a non-production environment and the recovery time and data state were checked	Hosting operations runbook and periodic restore exercises with signed results
Vulnerability scan records	Scan scope, tool, date, findings and closure status for the web application, server and dependencies	Scheduled scans and authenticated application testing performed under the agreed scope
Hosting boundary diagram with NIST SP 800-53 control mapping	Where site data, editor accounts and logs sit, which components are in scope and which control families each component addresses	Solution architecture, mapped to the baseline the agency selects, for example low, moderate or high in SP 800-53B

How a government web estate moves to a supported release in phases

The sequence takes an agency web estate from an unknown inventory to a supported, patched and accessible platform that the agency's own staff can run. Each phase ends with a written artifact that the agency signs off before the next phase starts.

Inventory and classify every site
DeployOpen works with the agency's web owners to list every site, subdomain, template, plugin, theme, integration and form, along with its Drupal or WordPress version and PHP version. Each site is classified by audience, content type, personal data handling and public-facing risk so that the agency can decide which sites move first and which are retired. The output is a site inventory with a risk classification and a list of sites that run unsupported versions. The step is complete when the agency confirms the inventory is complete for its estate.
Run the accessibility baseline audit
DeployOpen tests a representative set of pages and templates per site against WCAG 2.1 Level AA, combining automated scans with manual testing by reviewers who use assistive technology. Findings are grouped by template, so that a shared component fixed once is recorded as one remediation item rather than repeated across every site. The output is an audit report with severity, affected templates, owners and a remediation backlog. The step closes when the agency accepts the audit scope and the backlog is prioritized. Confirm with the agency's accessibility office which conformance evidence it needs before testing begins.
Agree the governance and roles model
The agency and DeployOpen define who owns the platform, who approves new sites, which agencies or departments can publish, and which roles can edit templates, plugins, users and single sign-on settings. Content ownership, review dates, release approval and the escalation path for security patches are written into the model. The output is a governance charter with a roles matrix and a decision log. The step is complete when the named approvers sign the charter and the agency's legal and records teams have reviewed it.
Build the hardened platform in agency accounts
DeployOpen builds the target Drupal or WordPress environment inside the agency's own cloud accounts, data center or approved hosting contract, with the web server, database, cache, CDN, backups, logging and identity integration configured to the agency's security baseline. Staging, testing and production are separated, and infrastructure is defined as code so that changes are reviewed. The output is a hardened environment, its configuration documentation and a record of the security controls mapped to the agency's control framework. The step closes when the agency's security team accepts the build for testing.
Migrate and remediate wave by wave
Sites move in waves set by the risk classification, with each wave covering content, users, redirects, themes rebuilt on the shared design system, and remediation of the accessibility backlog for the templates it uses. Drupal 6 and 7 sites are migrated into new sites rather than upgraded in place, and WordPress sites are moved onto supported releases with their plugins reviewed first. The output is a migration log per site with content counts, redirect checks, known gaps and a signed acceptance by the site owner. A wave is complete only when its sites pass functional and accessibility checks and the owners accept them.
Complete security and accessibility sign-off
Before each site goes live, DeployOpen runs security testing against the application, its configuration and its hosting, and the accessibility checks from the baseline are repeated on the changed pages. Open findings are recorded with owners and deadlines agreed in writing. The output is a sign-off pack containing test results, the accessibility conformance statement draft, the open-findings register and the change approval. The agency's security and accessibility leads must approve the pack before the site is switched to production.
Hand over the run state with the patch calendar
DeployOpen transfers operation of the platform to the agency's or its support provider's team through a runbook covering deployment, backups and restores, monitoring, incident response and access reviews. A patch calendar is set against the upstream security release schedule so that core, contributed modules, themes and PHP are updated on a known rhythm and tested in staging first. The output is a runbook, a patch calendar and a handover record signed by the agency's operations owner. Ongoing support, upgrades and continuous testing can be contracted separately as retainers.

Questions to put to an implementation partner before a government contract is signed

Start with the release process, because that is where accessibility and security claims either hold up or fail. Ask the partner to show, in writing, how WCAG 2.1 AA is tested before each release: which automated checks run in the pipeline, which manual checks are done with assistive technology, and which named role signs off that a release meets the standard. Ask whether the sign-off is independent of the developer who built the change. Then ask how the agency's own accessibility statement and feedback mechanism will be kept in step with each release, and who is responsible for updating them. The ADA Title II rule requires state and local government web content, including content provided through contracts, to meet WCAG 2.1 Level A and AA, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts (ADA.gov Title II web rule). Confirm which of those dates applies to your agency before you accept any delivery schedule.

Next, ask how editor roles are separated from central administration across agencies. Request the role map for the proposed multi-site setup: which accounts can create sites, change shared themes or components, manage users and alter the SSO configuration, and which accounts can only edit content within one agency's section. Ask how the partner keeps those permissions from drifting over time, and how access reviews are run. On security releases, ask how the partner monitors the Drupal Security Team advisories and WordPress security notices, how quickly a patch is applied to a staging copy, which regression tests run against it, and what the emergency path looks like when a release lands outside the normal cycle. Drupal security releases follow the third Wednesday of the month, and WordPress 7.1 receives maintenance only on the most recent release in its series, so ask how the partner handles both cadences.

Ask how a Drupal 10 estate will move before December 9, 2026, the date Drupal 10 reaches end of life, and confirm which Drupal 12 timing the partner plans around. For any Drupal 7 site, ask whether it will be migrated into a new site, since in-place upgrades are not possible, and whether it will remain on an extended security support provider in the meantime. Ask where backups, logs and form submissions are stored, which countries and facilities hold them, and who holds administrative access to the hosting account. Ask how SAML or OpenID Connect will connect to the government identity provider, and which contributed modules the partner would use, such as samlauth or the OpenID Connect client module. Finally, require the written scope, the handover evidence (test records, configuration exports, runbooks, and accessibility audit results), and exit terms covering ownership and delivery of code, content and documentation. Use the written scope to confirm each of these answers in writing before signing.

What do government buyers ask about cost, time and staffing for an open source CMS?

Does Drupal or WordPress carry a license fee for government use?

Drupal has no license fee and no paid edition of Drupal itself. Drupal core and the contributed modules hosted on Drupal.org are licensed under GPL-2.0-or-later, so the agency pays for work and services, not for the software. The cost sits in design and build, accessibility remediation, content migration, hosting and content delivery, security updates and ongoing support. WordPress core is also open source, but the plugins and themes an estate depends on carry their own licenses and maintenance terms, so the agency should inventory them during scoping. Ask every bidder to list each component, its license and who maintains it.

What drives the cost of a multi-agency web estate?

The main cost drivers are the number of sites, languages and content types, how much shared design system and component work is needed, how many editor roles and approval paths must be mapped, and how many integrations (identity, forms, search, payments, analytics) each site uses. Accessibility work scales with the number of templates and legacy pages that need remediation, not only with the number of sites. Multi-site architecture decisions, such as a single shared install versus separate installs, also change the build and the recurring operations load. Ask for a quote that prices each of these items separately so the agency can see which decisions move the total.

How long does a government CMS build take?

The duration depends on the written scope, and no fixed timeline applies to every estate. A single department site with a standard template set takes far less time than a multi-agency platform with a shared design system, governed content migration and accessibility testing built into the release process. Timing also depends on how quickly the agency makes decisions, approves content and provides access to identity and hosting. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask each bidder to show the phases, the dependencies and the decisions the agency must make at each phase.

Can agency staff run an open source CMS after launch?

Yes, if the agency assigns owners for the roles that keep the platform working. Editors publish and maintain content within their permissions. Site administrators manage sites, templates, users and workflows. Platform administrators handle hosting, deployments, updates and backups. Security owners approve the release cadence, review vulnerability findings and keep the evidence for assessments. Smaller agencies often combine the platform and security roles, but the responsibilities still need named people. Whether internal staff can carry all of this, or whether a support retainer covers part of it, is a decision to make during scoping, based on the staff available and the agency's own change control rules.

What does the agency need to provide for the work to succeed?

The agency needs to provide several things early. It should name content owners for each site and section, with authority to approve accessibility and content review before publication. It should name a sign-off authority for scope changes, design decisions and go-live. Delivery depends on access to the identity provider for single sign-on, the hosting environment or cloud account where the platform will run, DNS and certificate management, and the existing sites and content to be migrated. Security and compliance staff should review the hosting boundary and the evidence plan at the start, not at the end. Ask for a written list of these dependencies before any quote is accepted.

How does a Drupal 7 migration change cost compared with a current build?

A Drupal 7 site cannot be updated in place to a current version. Drupal documentation explains that Drupal 6 and 7 sites are migrated into a new site using the core Migrate modules or Drush, and themes must be rebuilt because they cannot be migrated. This adds content mapping, theme rebuilding, redirect planning and regression testing on top of the work a new build needs. Drupal 7 security support ended on January 5, 2025, so an agency that must keep a Drupal 7 site running for a period can look at the Drupal Association's extended security support provider program, which lists certified vendors. Ask bidders to estimate migration effort per site and to explain how they will protect the site during the transition.

What recurring costs should government buyers plan for?

The recurring costs are hosting and content delivery, security updates, accessibility retesting after content or template changes, support and upgrades, and the staff time to review and approve releases. Drupal core releases security fixes on a published schedule, and the release cadence should be built into the support contract and the agency's change control. WordPress security releases follow the WordPress.org release cycle, and only the most recent release in a series is actively maintained, so older versions must be upgraded promptly. Ask each bidder to describe the update window, the testing before each release, and what is included in the support fee compared with work billed separately.

How DeployOpen scopes, builds and supports public sector CMS estates

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For public sector web estates, that means fixed scope agreed in writing before work starts, with accessibility, governance and security release evidence built in from the first sprint.

How we scope

Written scope listing the agencies, sites, languages and templates covered by the engagement
Inventory of existing sites, including Drupal 7 or other end-of-life versions that need migration
Confirmation of the accessibility target, the compliance deadlines that apply and the evidence the client must hold
Agreed deliverables and timelines documented before any build work begins

How we build

Multi-site architecture on Drupal or WordPress, with a shared theme and design system for all agencies
Role and permission model that separates central governance from per-site editors
Single sign-on integration with the client's identity provider, using contributed modules where they fit
Accessibility testing and remediation within the release process, with results recorded for each release

How we hand over

Documentation of the hosting boundary, configuration, integrations and update procedure
Editor guidance and governance rules for content ownership, review dates and publishing approvals
Accessibility statement inputs, test records and remediation logs prepared for the client's own review
Runbooks for patching, backup, restore and rollback, tested before handover

How we support

Ongoing support, upgrades and continuous testing available as a retainer agreed in writing
Monitoring of Drupal and WordPress security releases, with patches applied in a documented change process
Scheduled planning for major version moves before end-of-life dates
Periodic accessibility re-testing and evidence refresh as content and templates change