Why Drupal for government websites changes the build
A public body running a web estate under legal accessibility deadlines, across several departments or municipalities, with rules on where citizen data may sit, needs a platform it can govern and host itself. Drupal is licensed under GPL-2.0-or-later and has no paid edition, so the agency can run it in cloud accounts, data centers or sovereign infrastructure it controls, and it does not need a license decision to change where the site lives. The build changes because the requirements change: the platform choice matters less than the operating model around it.
Scope grows in three directions. First, content governance: a multisite or multi-department design needs decisions on which sites share a codebase, which roles can publish in which section, how shared components such as footers, emergency notices and language switchers are owned, and who signs off changes to them. Second, WCAG 2.1 Level A and AA work is no longer a final QA pass. The ADA Title II rule sets WCAG 2.1 A and AA as the target for state and local government web content, with the compliance date depending on population served, so the team should confirm its own date with counsel and build accessibility checks into templates, the theme and editorial forms from the start.
Third, the upgrade path must be planned rather than reactive. Confirm which Drupal major version each site runs, when that version leaves support, and which PHP version the hosting stack supports, since each major release raises the PHP minimum. Ask the vendor or internal team for a dated plan covering core and contributed module updates, the security advisory response process, and a test environment that mirrors production. Sites still on Drupal 7 need a migration into a new site, because themes must be rebuilt and the in-place upgrade path does not exist.
Which government requirements shape the Drupal build
This table maps four regimes to the parts of a Drupal build they affect. Read each row against your entity's legal status, since applicability depends on whether you are a state or local body, a national authority, an EU public body, or a contractor handling criminal justice information. The main takeaway is that accessibility applies to nearly every public site, while the other three apply only when specific conditions are met.
| Requirement | What it asks for | What it means for the Drupal build |
|---|---|---|
| ADA Title II web accessibility (28 CFR 35.200) | State and local government web content and mobile apps must meet WCAG 2.1 Level A and AA, including content delivered through contracts or licenses. Dates: 26 April 2027 for entities serving 50,000 or more people, 26 April 2028 for smaller entities and special districts. | Audit themes, editorial tools and contributed modules against WCAG 2.1 AA, and include vendor-supplied content in scope. Confirm your population category with counsel, since it sets the deadline. |
| NIS2 for public administration | Covers central government entities regardless of size and lists public administration as a high-criticality sector. Member States may extend it to local public administration. Excludes national security, public security, defense and law enforcement. | Determine whether the site sits behind an in-scope entity's network and incident process. Plan logging, patch timelines and incident reporting for the hosting stack, not only the CMS. Confirm national transposition. |
| GDPR Chapter V transfers | Every transfer of personal data to a third country, including remote access from abroad and storage outside the EEA, must meet Chapter V conditions. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover. | Host forms, user accounts and analytics in the EEA, restrict vendor support access from outside it, and review sub-processors and their support locations. Verify any reliance on the Data Privacy Framework against the current adequacy decision and pending appeal. |
| CJIS Security Policy encryption and scanning | For criminal justice information in transit and at rest outside physically secure locations, requires FIPS 140-3 validated modules or FIPS 197 AES with keys of at least 256 bits. Vulnerability scanning at least monthly (controls SC-13, SC-28, RA-5). | Applies only if CJI touches the site, such as police or court forms that collect case data. Keep such data off public Drupal pages, use validated cryptography in the stack, and schedule scans. Confirm version 6.1 obligations with your CJIS Systems Agency. |
Modules and integrations agencies typically configure
Government Drupal sites usually combine a small set of core features and contributed modules: language and site structure, staff and citizen sign-in, review workflows, public forms and search. Each one carries its own configuration and upgrade risk, so confirm every module version against your installed Drupal core before scoping the work.
Multilingual and multisite configuration
Agencies often run one Drupal codebase for several departments, regions or languages. Decide early whether each site gets its own database or shares one, how language content is translated and reviewed, and how hreflang and URL aliases behave across sites. Confirm the language and translation modules included with your Drupal core version, and test language switching and shared theme updates on a staging copy before launch.
SAML and OpenID Connect sign-in
The samlauth module lets Drupal act as a SAML service provider, and the openid_connect module authenticates users against an OpenID Connect or OAuth 2.0 provider and creates accounts on first sign-in. Use SAML where your identity provider already speaks it, and keep staff and citizen accounts in separate roles. Confirm that your identity provider and the module version match your Drupal release before you plan account provisioning.
Editorial workflows for multi-department review
Content from one department often needs legal, accessibility or communications sign-off before it goes live. Map each content type to its reviewers, define which states can be published, and decide who can override a review during an emergency notice. Confirm which workflow module or core moderation configuration fits your Drupal version, and check whether reviewers can see drafts from other departments.
Webform for public forms
Webform builds public forms for permits, complaints and service requests without custom code. Where possible, send submissions to the agency system of record through a handler and purge stored submissions on a set schedule, so personal data stays out of the CMS database. Confirm the Webform version against your Drupal core, and test spam defenses and file upload limits before opening the form to the public.
Search across departments
Public sites need search that respects language, department and content status. Choose between the core search module, Search API with an external engine, or a managed search service, and confirm which engine your hosting model supports. Index only published, public content, and test that restricted pages and draft workflow content never appear in results.
Core update and security advisory handling
Agencies need a dated process for applying Drupal core and contributed module updates, because security releases follow a fixed Wednesday window. Confirm which Drupal major version your site runs and its end-of-life date, and check each contributed module against its advisory before the next release. Plan a staging environment and a documented rollback step for every update.
Hosting options for government and sovereign infrastructure
Hosting in a government-operated data center gives the agency the most direct control. The agency or its parent department owns the racks, the network boundary, the physical access log and the staff who administer the hosts, so the Drupal site, its database and its backups stay under one chain of custody. The trade-off is that the agency also owns capacity planning, patching of the underlying platform and the cost of running a second environment for staging and recovery.
- Operational ownership: the agency decides how Drupal is deployed, which web server and database engine it uses, and how updates for core and contributed modules are scheduled.
- Remote support access: if a DeployOpen engineer or a vendor is abroad and views data on a screen during support, EDPB Guidelines 05/2021 treat that as a transfer, so access must be routed through approved, in-country jump hosts.
- Backups and storage location: storage of backups outside the EEA is also a transfer, so the off-site copy must sit in an approved location under the same controls.
- Recovery capacity: a second site is an agency decision and a recurring cost, so ask what the agency's own data center can supply for failover.
- Legal exposure: because the provider is the government itself, the CLOUD Act and Article 48 questions mostly do not arise, but any third-party hardware or support contract may bring them back.
Confirm with your data protection officer which staff and contractors may view personal data, and from where, before the support model is written down.
A sovereign or national cloud is operated by a provider under national jurisdiction, usually with a contract that fixes where data and administrative access sit. It can offer elastic capacity without the agency running hardware, while keeping the legal chain inside the country. Before choosing one, the agency should confirm the operator's own ownership, the nationality of staff with privileged access and whether any non-national parent company can compel access.
- Jurisdiction of the operator: check whether the operator, its parent and its subprocessors are subject to foreign law with extraterritorial reach, since EDPB Example 12 says that complying with a third-country authority request would itself be a transfer.
- Administrative access: ask where support engineers sit and whether they can see data in the clear, because remote display from a third country is a transfer under the EDPB guidance.
- Storage and backups: confirm that object storage, snapshots and disaster recovery copies all remain in the sovereign region.
- Exit terms: under the EU Data Act, customers of data processing services have a right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. Write these terms into the contract.
- Sector rules: NIS2 may apply to public administration entities depending on the Member State, so confirm applicability with legal counsel.
Ask the operator for its written list of subprocessors and the locations of each.
A commercial cloud region can host a Drupal site under a contract that names the region, the support boundary and the data processing terms. It brings managed services and fast scaling, but the provider is a private company, so the agency's exposure to foreign legal demands depends on the provider's ownership, its contracts and where its staff and systems are. Selecting a region inside the country does not, on its own, settle the question of foreign access.
- CLOUD Act exposure: 18 U.S.C. 2713 requires US-based electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever it is stored, so a US-parented provider can be compelled regardless of region.
- Article 48 limits: GDPR Article 48 allows a third-country disclosure order to be recognized only if it rests on an international agreement, such as a mutual legal assistance treaty, so ask how the provider handles such requests.
- Transfer assessment: EDPB Recommendations 01/2020 state that where a cloud provider must access data in the clear and foreign authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure is envisioned, so the assessment may fail regardless of encryption.
- Data Privacy Framework status: adequacy for US organizations depends on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending, so track the outcome.
- Key management: customer-held keys reduce some risk but do not remove the access question, so get a written legal assessment.
Ask the provider for its government access request policy, its transparency reports and its written support locations before signing.
How a government Drupal rollout runs in phases
The sequence moves from an honest picture of the current estate to a supported, patched site, with the agency approving scope, accessibility position, identity design and go-live at fixed decision points. Each phase produces evidence the next phase depends on.
Audit the estate and inventory content
DeployOpen reviews the existing sites, Drupal versions, hosting, integrations, forms, and content volumes, and works with department owners to classify each page as keep, rewrite, merge, or retire. The agency signs off the inventory and the list of sites in scope before any design work begins. The step is complete when every site has a version, owner, traffic note, and disposition recorded in a shared register.
Set the accessibility baseline
The team runs automated and manual checks against WCAG 2.1 Level A and AA on representative templates and high-traffic pages, then records the defects by template and by department. The agency confirms its compliance date under the ADA Title II rule, which depends on population served, and decides whether remediation happens before or during the build. The output is a remediation plan with owners and a re-test point for each template.
Design the department information architecture
Content types, taxonomies, menus, and URL patterns are drafted with department editors, including how multilingual versions and shared services pages are modeled. Decisions cover which sites share one Drupal instance and which run as separate sites in a multisite layout. The agency approves the content model and governance rules, including who may publish what. The step closes when a signed content model and a page-type catalog exist.
Build custom modules and the accessible theme
DeployOpen builds the agency-specific modules, the base theme, and the editorial components against the approved content model, with code review and automated tests kept in version control. Accessibility checks run during build rather than only at the end. The agency approves a working staging environment on representative content. The step is complete when the components pass the agreed checks and the code is documented for the agency's own developers.
Migrate from Drupal 7 and other sources
Drupal 7 sites cannot be updated in place to a current major version, so content is moved into a new site with the core Migrate modules, and themes are rebuilt rather than migrated. The team maps fields, redirects, files, and user accounts, then runs repeated test migrations and reconciles counts and samples with editors. The agency signs off the mapping and the cutover plan, and the step closes with a reconciliation report and a tested redirect map.
Integrate citizen and workforce identity
The agency confirms which identity provider will sign in editors and, where needed, citizens, and whether it uses SAML or OpenID Connect. DeployOpen configures the chosen contributed module, tests role mapping, account creation on first sign-in, and sign-out behavior in staging. Decisions on account provisioning and where personal data is stored are approved by the agency's security and privacy owners. The step is complete when test sign-ins for each role succeed and the design record is approved.
Test security and accessibility before launch
Security testing covers the custom code, the site configuration, and the integrations, and the findings are triaged with the agency's risk owners. Accessibility re-testing confirms the remediation plan items closed. The agency decides which open findings are accepted, with a named owner and a fix date, and which block go-live. The output is a test report, a findings register, and a written go-live decision signed by the accountable officer.
Go live and run the patch routine
The cutover runs from the approved plan with redirects, DNS, and monitoring checked before and after the switch, and a rollback path kept ready for the window. After launch, the agency and DeployOpen agree on a routine that applies Drupal core and contributed security releases, which are published on a fixed Wednesday schedule, and on who approves each update. The step closes when the routine has run through at least one full cycle and the team has a runbook for security advisories.
Compliance considerations DeployOpen prepares for
Government Drupal projects are judged against several frameworks at once, and each one asks for different evidence. The cards below cover the items we prepare systems and records for, from accessibility to data location and switching rights. DeployOpen prepares systems, controls and evidence, but independent auditors and certification bodies issue any assessment or certification.
WCAG 2.1 AA evidence
Title II of the ADA requires state and local government web content to meet WCAG 2.1 Level A and AA, with a compliance date of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. For Drupal, we prepare the theme component library, content editor guidance, automated and manual test records, and a remediation log for contributed modules. Confirm with your counsel which date applies to your entity and whether vendor-provided content is in scope.
NIST SP 800-53 baseline mapping
NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects low, moderate and high baselines. We map the Drupal platform, hosting layers, identity integration and operational routines to the control IDs your authorizing official uses, so each control names a component, an owner and an evidence source. Expect gaps in inherited controls from the hosting provider, and ask your assessor which baseline and release apply to the system.
FedRAMP scope limits for cloud
FedRAMP applies to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system used only for one agency's internal operations on cloud infrastructure and not offered as a shared service may fall outside that scope. Before choosing a hosting provider, confirm with your agency whether the Drupal site is in scope, and ask any hosting provider for its current authorization status and the boundary it covers.
FIPS 140-3 and AES-256 for CJI
Where a Drupal site or its integrations handle criminal justice information, the FBI CJIS Security Policy expects encryption in transit and at rest outside physically secure locations to use FIPS 140-3 certified modules or AES with at least 256-bit keys. Drupal sites often add data stores through contributed modules, search indexes and backups, and each one needs the same check. Ask your CJIS Systems Agency which policy version applies and confirm the cryptographic module certificates your hosting stack uses.
GDPR transfer exposure
Under GDPR Article 44, any transfer of personal data to a third country, including remote access for support, must meet Chapter V conditions. EDPB guidance treats screen-level remote access from outside the EEA and cloud storage outside the EEA as transfers, so support contracts and backup locations belong in the transfer assessment. Map every administrator, vendor and backup location for the Drupal estate, and assess third-country legal exposure before selecting a processor.
Data Act switching rights
The EU Data Act, applicable since 12 September 2025, gives customers of data processing services the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. For a Drupal estate hosted with a cloud or managed provider, record the export formats for content, configuration and user data, and confirm the exit steps in the contract before signing.
What agencies and municipalities ask before hiring a Drupal partner
What does a government Drupal project cost, and what drives the quote?
The quote follows from the written scope, not from a standard package. The main drivers are the number of sites in the estate, how many languages each site publishes in, the content model and templates, the number of integrations (identity, forms, payments, case management, search), the accessibility testing effort, and the hosting model, including whether the platform must run in government or sovereign infrastructure. Costs split into one-time work (discovery, build, migration, testing, launch) and recurring work (security updates, hosting operations, support). Ask any partner for a quote that lists these components separately, with the assumptions behind each one. DeployOpen does not publish a price list.
How long does a Drupal 7 migration take, and why is it not an in-place update?
Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. Drupal.org documentation describes migrating them into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and the themes must be rebuilt because they cannot be migrated. Duration depends on the content volume, the number of content types and fields, the custom modules that need replacing, the theme rebuild, and how many sites share the estate. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so sites still running it may need interim cover from a certified Extended Security Support provider while the migration proceeds. Ask for a migration inventory before agreeing to a timeline.
What must the agency's team provide before a build starts?
The agency team provides the decisions and access that no partner can make on its behalf. Typical inputs are:
- Named business owners who approve content models, workflows and launch criteria
- Accessibility, legal and records owners who review requirements and sign off on evidence
- Access to existing sites, content exports, analytics and the identity provider or directory that will sign users in
- Hosting accounts or data center access, and the security policies that apply to them
Delays usually come from slow decisions and missing access rather than from build work. Agree these responsibilities in the written scope so that each dependency has an owner and a date.
Can our own team run the Drupal site after launch?
Yes, if your team has the skills and capacity to own the platform, and many agencies keep operations in-house after a build. Running Drupal in-house means someone must apply core and contributed module updates, which are published on a fixed schedule: bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. The team also needs staff who maintain backups, monitoring, the deployment pipeline and custom code. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so the team needs a plan for that cycle. A retainer with a partner is an alternative for the recurring work, and the split should be decided before launch.
How does a Drupal partner handle security advisories?
Drupal's Security Team resolves reported vulnerabilities in core and contributed projects, publishes advisories with CVE identifiers and risk scores, and releases fixes in the Wednesday security windows. Your partner or internal team should subscribe to these advisories, check which ones touch the modules in your estate, and apply patches in a test environment before production. Ask the partner for its response process: who triages advisories, how fast a critical patch is tested and deployed, how changes are logged as evidence, and how custom code is reviewed when core or a contributed module changes underneath it. Confirm these steps in writing rather than assuming them.
Does a government Drupal site need identity integration with citizen login?
Many agencies need citizen or employee sign-in, and the approach depends on the identity provider already in use. Drupal can act as a SAML service provider through the contributed SAML Authentication module (samlauth), whose latest stable release 8.x-3.14 supports Drupal 10.3 and later and Drupal 11. The contributed OpenID Connect module can authenticate users against external OpenID Connect providers and creates accounts on first sign-in. Cost and effort depend on the number of identity sources, the attribute mapping to roles, the handling of account lifecycle, and the testing needed for each login path. Confirm your identity provider's protocol support and your policy for account creation before choosing a module.
Is Drupal CMS a good fit for agency content teams?
Drupal CMS can suit content teams that want guided setup, and it is a distribution built on Drupal core with recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. Drupal CMS 2.0 is the current major release. Fit depends on the governance model. Agencies with many sites, strict accessibility review, multilingual publishing and custom integrations usually need the content model and workflow designed first, whichever distribution is chosen. Ask whether the features your teams need are included, which parts are contributed and how upgrades between distribution releases will be handled.
How government sites differ from other Drupal projects
Government Drupal projects differ mainly in who decides, who pays and how long the site must stay supported. Many agencies or municipalities share one estate, so a single Drupal codebase may serve several departments, each with its own content owners, branding and approval chain. Before the build starts, decide which settings, modules and themes are shared platform decisions and which belong to a department, and record that split in a governance charter. Without it, one department's request for a custom module becomes a dependency for every other site on the estate, and upgrades stall while owners negotiate.
Public procurement also shapes scope. In most public bodies, work must be defined in a tender or contract before the vendor starts, and changes go through a formal variation process. Ask for a fixed, written scope that names the modules, integrations, environments, hosting location and support hours, and separate one-time build work from recurring support and security patching. Confirm with your procurement and legal teams how the contract handles source code ownership and licensing. Drupal core and most contributed projects are GPL-2.0-or-later, so the license is open, but the contract still needs to say who owns the custom code and who may maintain it after handover.
Government sites also outlast the people who built them. A site launched for a campaign or a service may run for many years under staff who did not write it, so documentation, a tested upgrade path and a named owner for each module matter more than in a commercial project. Legal accessibility duties add a further layer: under the ADA Title II rule, state and local government web content and mobile apps must meet WCAG 2.1 Level A and AA, including content provided through contracts or licenses. Confirm with counsel which compliance date applies to your entity, and make sure any third-party embeds, form tools and purchased components are covered in acceptance testing, not only the pages your team wrote.
How DeployOpen scopes and supports government Drupal work
DeployOpen plans, builds, hardens, documents and supports Drupal inside your own infrastructure, whether that is a cloud account, a data center or an air-gapped network. Each government engagement starts from a written scope that sets out accessibility, identity, hosting and patching responsibilities before any build work begins.
How we scope
- Agree a written, fixed scope covering sites, languages, content types and the Drupal modules each site needs.
- Map which WCAG 2.1 Level AA criteria your entity must meet and when, and who verifies them.
- Record hosting location, data classes and third-country access questions before choosing any service provider.
How we build
- Build custom modules and themes that follow Drupal coding standards and keep future core upgrades inexpensive.
- Configure SAML or OpenID Connect sign-in against your identity provider, with account provisioning agreed up front.
- Test accessibility, security headers and multisite isolation in a staging environment that mirrors production.
How we hand over
- Document architecture, deployment steps, configuration exports and the module inventory for your own team.
- Provide an evidence pack of test results, patch records and control settings that your assessors can review.
- Run knowledge transfer sessions so your staff can apply security releases and content changes independently.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
- Track Drupal security advisories and apply patches on the Drupal Security Team's Wednesday release windows.
- Plan core upgrades ahead of end-of-life dates so each site stays on a supported version and PHP release.
