Open source platform for public consultations

Why an open source platform for public consultations depends on who is consulting

A government body that consults on plans, laws or policies must run a process that is lawful, accessible and published, and the legal regime that applies to that body shapes the build more than any feature list does. The short answer for most consultation work is that Decidim is the main open source option with a consultation-specific model, built around processes, phases, comments, proposals, surveys and meetings. Whether it fits your body depends on who you are, where you can host it and which duties follow from that, so confirm those points before you choose it.

Start by identifying the regime. A US federal agency works under control catalogs such as NIST SP 800-53 and, if it uses a cloud service to hold federal information, under FedRAMP scope rules, while a US state or local body must meet the ADA Title II web rule, which requires WCAG 2.1 Level AA from April 26, 2027 for entities serving 50,000 or more people and from April 26, 2028 for smaller entities and special districts. EU public administrations face NIS2 for central government and possibly local bodies, and the GDPR for participant data. Each regime sets requirements for hosting location, identity handling, retention, accessibility statements and evidence, and those requirements decide the architecture before any component is switched on. Ask your counsel and security office to write these duties down as a requirements list before you compare platforms.

Hosting is the second constraint. Decidim is licensed under the AGPL-3.0, is built on Ruby on Rails and PostgreSQL, and is maintained by the Decidim Association with Barcelona City Council, so you can run it in your own cloud account, data center or air-gapped network. Confirm which maps, geocoding and social login services your configuration calls, because those external services can send participant data outside your jurisdiction. Also confirm which Decidim release line your security team will support, since only the last two minor versions receive security updates before version 1.0, which currently means 0.32.x and 0.31.x.

Which legal and operational requirements shape a consultation build

This table maps each legal or operational requirement to its source and shows what it changes for hosting, identity and the release calendar. Read each row as a question to answer before the architecture is fixed, since several rows set hard dates or limits that reach into procurement. The main takeaway is that the Decidim release and patch cadence, not only the law, sets the ongoing operating workload.

Requirement	What it asks for	Effect on hosting, identity and releases
ADA Title II web accessibility	State and local government web content and mobile apps must meet WCAG 2.1 Level AA; dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts	Custom themes, consultation forms and survey pages must be tested before each release; confirm which compliance date applies to your body and whether contractors' content counts
NIS2 for EU public administration	Covers central government entities regardless of size and lists public administration as high criticality; Member States may extend it to local bodies; national security, defense and law enforcement are excluded	Confirm whether your body is in scope and which national transposition applies; this can add incident reporting and supplier security duties that shape hosting contracts and logging
Decidim security support window	Until version 1.0, only the last two minor versions (currently 0.32.x and 0.31.x) receive security updates; 0.30.x and earlier are unsupported	Plan the release calendar so production stays on a supported minor line; confirm the upgrade path with your implementation partner before any major change
Patch grace periods	Implementers get 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed	Staging must be ready to receive patches quickly; set an internal patch process and an owner who subscribes to security@decidim.org or GitHub Security Advisories
One minor version at a time, with database backups	Upgrade one minor version at a time, for example 0.29 to 0.30 before 0.31, following each release's instructions, and back up the database first	Hosting must support a staged upgrade path with a tested restore; schedule consultation launches away from upgrade windows and avoid running live phases during migrations
NIST SP 800-53 Rev. 5 baselines	The federal control catalog; SP 800-53B baselines select 149 controls (low), 287 (moderate) and 370 (high), including enhancements	Use the baseline as a reference for federal bodies to map hosting, identity and logging controls; a self-hosted Decidim instance is assessed within your own system boundary, so confirm the baseline with your assessor
FedRAMP scope limit for single-agency systems	FedRAMP covers cloud products that handle federal information on behalf of an agency; systems used only for one agency's operations on cloud infrastructure and not offered as a shared service are out of scope	A single agency running its own Decidim instance on its own cloud account usually falls outside FedRAMP scope; a hosted shared service for several agencies may not, so confirm the model in writing
Identity method for verified participation	Verification and login use Decidim's social providers and OmniAuth strategies; confirm which methods your rules accept for each space	Plan government eID or SSO integration as a custom OmniAuth provider; check the identity data kept and whether social login sends data outside your jurisdiction

Which open source platforms fit a government consultation

Government consultations need phases, comments, proposals, surveys, recorded meetings and published outcomes. Decidim models most of these natively, while general CMS options can host simpler consultation pages but need custom work for the participation logic. Confirm each option against your own process rules before you choose.

Decidim as the participation platform

Decidim is a free, open-source participatory democracy framework built on Ruby on Rails and PostgreSQL, licensed under AGPL-3.0 and maintained by the Decidim Association with Barcelona City Council. It provides participatory spaces such as processes, assemblies and initiatives, and components including meetings, surveys, proposals, participatory budgets and accountability tracking. For consultations, a process with phases can carry the full lifecycle from draft to closing comments. Confirm that its phase and component model matches your legal consultation steps before committing.

Decidim's public-sector track record

Decidim reports that more than 500 organizations use it, including Barcelona, the European Commission's Citizens' Engagement Platform, New York City, Helsinki and the Brazilian federal government's Brasil Participativo. That reach matters for procurement, because it shows the framework has been run at national, city and supranational scale. Ask any implementation partner for references from deployments with a comparable consultation volume and legal setting, and check how those sites handled upgrades.

Drupal for structured consultation sites

Drupal can host consultation pages with strong content workflows, role-based editing and mature accessibility practice. It does not provide phases, public comments or proposal voting out of the box, so those must be modelled through custom content types, modules and workflow configuration. This adds build and maintenance effort that recurs with each Drupal upgrade. Use Drupal when the consultation is mostly a document and survey site with light interaction, and confirm the module set you would depend on.

WordPress for simple consultation pages

WordPress suits short, low-volume consultations where the main need is a publishing page, a document library and a basic survey form. Comments, proposal logic, phase control and moderation audit trails need plugins or custom code, and each plugin adds a maintenance and security review obligation. Only the most recent release in the 7.1 series is actively maintained, so plan for regular updates. Confirm whether your legal process needs records that a plugin set can produce and retain.

Choosing between platforms

The deciding question is whether the consultation is a process with phases, public input and recorded outcomes, or a set of pages with a form attached. Decidim fits the first case without custom build, while CMS options fit the second with less up-front scope. Write your process rules, including statutory deadlines, comment handling and reporting duties, before you run a fit test. Ask each vendor or partner to demonstrate those rules on a working instance rather than a slide.

How the deployment pattern changes for public bodies

A Decidim consultation platform is a set of components, each of which can sit in a different place. For a public body, the hosting choice for each one decides who can access participant data, which law applies and what evidence the body must keep. The cards below cover the parts that need a deliberate decision before build starts.

Rails application hosting

Decidim runs as a Ruby on Rails application, installed manually or with Docker. Choose between the body's own data center, a government cloud account and an EU-hosted provider based on where the application servers, logs and backups sit. Confirm which personnel can reach the server, where application logs are retained and whether the provider can access the hosts. The hosting choice also sets who patches the runtime, which matters because Decidim supports only its last two minor versions with security updates.

PostgreSQL database placement

The manual guide uses PostgreSQL 17.4 or later on Ubuntu 24.04.3 LTS. The database holds proposals, votes, comments and participant accounts, so it is the component most likely to contain personal data. Ask where the primary and replicas run, whether backups are encrypted and where they are copied. Upgrades change database structures, so the body must also plan a tested backup before each minor version step.

File storage for uploads

Proposal attachments, uploaded documents and images are stored through ActiveStorage. A consultation on a planning document can attract large files, and some of them may contain personal data from residents. Decide whether files stay on the body's own storage, move to a government cloud bucket or go to an EU-hosted object store. Confirm encryption at rest, access logging and how deleted files are purged from storage and backups.

Email delivery through SMTP

Notifications, confirmation emails and password resets go through an SMTP service that the production setup must configure. Mail often carries a participant's name, address and the title of the process they joined, which makes the relay a personal data processor. Confirm where the relay operates, whether message content is stored by the provider and what retention the provider applies to delivery logs. Also confirm that the sending domain and records are controlled by the body.

Maps and geocoding services

Consultations on land use, transport or local services often place proposals on a map. Geocoding turns addresses into coordinates, and many default map providers are hosted outside the EU. Each address typed by a participant can reveal where they live. Decide whether to run tile and geocoding services inside the body's infrastructure or use a provider under a documented data processing agreement, and confirm what coordinates are stored with each proposal.

Login and social providers

Decidim includes Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login, and other OmniAuth strategies can be added. Social logins send participant identity to a third party and may transfer data outside the EU, which conflicts with many public sector policies. Decide which providers are enabled per organization, whether a government eID or staff SSO replaces them and who holds the client secrets. Confirm what attributes each provider returns and whether the body can disable a provider without a code change.

How phases, comments and in-person meetings become a recorded consultation

A Decidim consultation is built as a participatory process made of phases, and each phase decides what residents can do: read the draft, submit proposals, comment on text, answer a survey or attend a meeting. Within a process, the proposals and comments collect in the components you enable for that phase, so the content of each phase is set by configuration rather than by a separate site. Before the build starts, write down the phase map with its dates, the components active in each phase and the moment the process closes. Decidim's process and component settings decide what appears when, so a phase that is announced but not configured will leave residents with a dead end. Also decide who creates and moderates content, since that role assignment is what the platform enforces.

Comment rules are the part most often left vague, and they carry legal and reputational risk. Decide in advance whether comments are visible immediately or after moderation, whether residents may comment on proposals or only on the draft text, whether authors appear under their names or a pseudonym, and whether comments can be edited or withdrawn after posting. Moderation is a separate step: staff review reported or flagged content against a published policy, hide or remove what breaks it, and log the reason. Write that policy and the appeal route before launch, because they will be tested by the first contested comment. Surveys and in-person meetings can be recorded in the same process, so the record of a town hall sits next to the online comments it generated.

The duty to publish how input changed the outcome is the reason the workflow must be designed backward from the report. Decide which proposals and comments feed a decision, who signs the response, and how each outcome is published against the original input, so that a resident can trace a comment to a result. Confirm with your legal team which consultation rules apply to your body, such as minimum consultation periods and the format of the published response, because these are set by your own law and not by the platform. DeployOpen can configure and document these settings in the written scope, but the rules themselves should come from your organization.

What changes for federal, state and local, and EU public bodies

Federal agencies running a consultation platform generally need to show that the system meets the security controls assigned to it. NIST SP 800-53 Rev. 5 is the control catalog that federal systems draw from, and SP 800-53B selects control sets into three baselines. Those baselines are a reference for scoping the build, not a certification, and the agency's authorizing official decides what applies to its system.

Control baselines: SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. Use them to map which controls the consultation system must address and which the hosting layer inherits.
FISMA oversight: FISMA places agency system security under independent assessment by Inspectors General, who report to OMB. Expect evidence requests on access control, logging, change management and incident response for the Decidim instance.
FedRAMP scope limit: FedRAMP covers cloud products and services that handle federal information on behalf of an agency. A system used only for one agency's operations on cloud infrastructure and not offered as a shared service falls outside that scope, so confirm the hosting and service model before assuming FedRAMP applies.
Hosting choice: Self-hosting in the agency's own accounts or data center changes which controls are inherited and which the agency owns. Confirm this boundary in writing before the build.
Agency-specific requirements: Some agencies add their own overlays or policies. Ask the agency's security office for them early.

Before scoping, confirm with the agency's authorizing official and privacy office which baseline applies, whether FedRAMP scope is triggered by the hosting model, and which inherited controls the hosting provider documents.

What auditors and oversight bodies ask for after a consultation launches

This table lists the evidence an oversight body or auditor is likely to request once a Decidim consultation is live, the component that produces each item, and what the reader should confirm against the Decidim version in use. DeployOpen prepares this evidence, while independent auditors and certification bodies assess it. Use it to decide what to build into logging, testing and release routines before launch.

Evidence item	Component that produces it	What to confirm against the version in use
WCAG 2.1 AA test results	Automated and manual accessibility testing of the public site, including custom themes and proposal and voting forms	Confirm which Decidim release and theme version were tested and whether custom components were included
Accessibility statement and feedback route	Published statement page and a contact or feedback mechanism linked from every page	Confirm wording and the feedback channel with the legal team and the responsible office
Security patch and upgrade log	Change records from the Decidim release cycle, deployment pipeline and host package updates	Confirm the installed minor version is still in the supported 0.32.x or 0.31.x branch
Database backup before each upgrade	Pre-upgrade PostgreSQL backup with recorded restore test	Confirm the upgrade path follows each release's instructions, moving one minor version at a time
Moderation and audit records	Decidim admin action logs, moderation decisions on comments and proposals, and retained reports	Confirm which actions are logged by default and how long logs are retained in your environment
Data flow inventory	Map of personal data entering through registration, authorization, maps, geocoding, SMTP and social login	Confirm which external services are enabled, since social login and maps can send data outside your infrastructure
Control mapping to the chosen baseline	Matrix linking hosting, identity, logging, backup and access controls to selected NIST SP 800-53 controls	Confirm the baseline (low, moderate or high) with the body that sets your requirements
Access and role records	Admin role assignments, staff account reviews and separation of moderator and administrator duties	Confirm how staff accounts are provisioned and removed through your identity system

How a consultation platform rollout runs in phases

The sequence turns a consultation the body must run into a configured, tested and publicly accountable Decidim site, with each phase closing on a named output the body signs off. Legal mapping comes first because it decides what the build must do.

Map consultation rules and legal duties
Before any configuration, the body and the implementer map each consultation type to its governing rules: who must be consulted, minimum consultation periods, how comments must be answered, what must be published and what records must be kept. Decidim spaces, components and phases are then specified against that map, so each duty has a named place in the build. Legal and records staff from the body approve the map. The phase closes when the signed mapping lists every consultation type, its phases and its publication obligations, and flags anything the platform cannot do without a workaround.
Build hosting and environments
The implementer deploys Decidim inside the body's own infrastructure, whether cloud accounts, a data center or an air-gapped network, and sets up separate development, staging and production environments. The build covers PostgreSQL, background jobs, file storage, SMTP, maps and geocoding, and backups, using the installation path the team chooses (manual Rails or Docker). Infrastructure and security staff confirm where data sits and who can reach each environment. The phase closes when production and staging run the same tested configuration and a restore from backup has been demonstrated.
Configure identity and eligibility
The team sets up how participants sign in and prove eligibility, using Decidim's built-in login options, custom OmniAuth providers, or the body's own identity service. Authorization rules are then tied to each consultation, so restricted consultations accept only the participants the body defines. Staff document which personal data each check stores and for how long. The phase closes when test accounts pass and fail each eligibility rule as specified, and the data retained by each check appears in the written record.
Test accessibility and content
The team builds the consultation pages, forms, survey questions and document attachments, then tests them against WCAG 2.1 Level AA, the standard the ADA Title II rule names for state and local government web content and mobile apps. Testers use keyboard navigation, screen readers and the body's own content, including PDFs and maps. Compliance dates depend on the body's population size and jurisdiction, so the body should confirm its own date. The phase closes when a written accessibility report lists the defects found, their fixes and any items accepted with a documented reason.
Run security testing and set the patch process
The implementer runs application and infrastructure security testing against staging, then fixes findings before any public launch. The body agrees how it will track Decidim releases and apply patches, using the project's security policy: security reports go to the published address, and implementers have a stated window to apply patches for standard and critical vulnerabilities before details are disclosed. Vulnerability scanning covers the operating system, the application and dependencies. The phase closes when the findings log shows every high-severity item resolved or formally accepted, and a named owner is assigned to watch security advisories.
Pilot a consultation with staff
The team runs a complete internal consultation with staff acting as participants, moderators and analysts. The pilot exercises every phase in the legal map, from opening and commenting through answering, closing and publishing the results. Moderation rules, notification emails and the report on how input changed the outcome are tested end to end. Staff note every point where the process departs from the mapping. The phase closes when the pilot runs without unplanned manual steps, and each departure has either been fixed or added to the publication rules with an owner.
Go live with publication rules
The body publishes the consultation with written rules for moderation, response times, data handling and how results are reported. Launch uses the production environment and the configuration signed off after testing, with monitoring, backups and the support contact active. Staff confirm that the published pages match the legal map and that the feedback mechanism for accessibility problems is visible. The phase closes when the go-live checklist is signed and the first consultation's phases open and close as scheduled.
Follow the post-launch upgrade cycle
After launch, the body keeps Decidim current by moving one minor version at a time, following each release's upgrade instructions and taking a database backup first, because some releases change database structures. Each upgrade is rehearsed in staging, re-tested for accessibility and eligibility rules, and only then applied to production. The body must stay on a supported branch, since security updates cover only the two most recent minor versions before version 1.0. The cycle closes with a dated upgrade record and a test report for every production change.

Questions to put to an implementation partner before signing

Start with the version. Ask the partner which Decidim release line they will deploy and maintain, and how long they commit to applying security updates to it. Decidim supports only the last two minor versions with security updates before version 1.0, currently 0.32.x and 0.31.x, so a partner proposing 0.30.x or earlier is proposing an unsupported platform. Ask for the written support window, who watches the Decidim security channels, and whether that commitment is in the scope document or only in a sales deck. Confirm which Ruby and Node versions the partner will run for the chosen branch, since the install requirements differ between 0.31 and 0.32.

Next, ask how security patches will move through the grace periods. Decidim gives implementers 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed. Ask the partner to describe their patch workflow: how they receive advisories, how long a patch takes to reach staging and production, and who signs off on a change to a live consultation. Ask how custom themes and custom components are included in that cycle, because a patch to the core can break a local modification. For accessibility, ask whether testing covers the custom theme, forms and proposal pages, not only the default Decidim interface, and which WCAG 2.1 Level AA checks they run before go-live.

Finally, ask for the documents and evidence that must exist on the day you sign and the day you launch. Request the hosting location of every environment, a list of every external service that receives participant data (SMTP, maps and geocoding, social login providers, analytics), and the data processing terms for each. Ask how the upgrade path is documented, including the rule to move one minor version at a time and to back up the database first, and whether that runbook is delivered to your team. Ask what go-live evidence they provide, and how the fixed scope, change requests and post-launch support are priced and written into the agreement. Confirm that each of these items appears in the signed document.

What do public bodies ask before hiring help for a consultation platform?

What drives the cost of a public consultation platform build?

The biggest cost drivers are the number of participatory spaces, the custom work on phases and proposal rules, the identity and census integrations, the theme and accessibility work, and the data migration from any existing site. Costs fall into one-time work (scoping, configuration, integration, testing, accessibility review, training and launch) and recurring work (hosting, backups, monitoring, security patching, upgrades and support). Ask each bidder to price these separately, to name who is paid for each line (the implementer, your hosting provider, or your own staff), and to state which items sit inside the fixed scope and which are optional extensions.

How long does a consultation platform take to deliver?

Timing depends mostly on how many consultation phases you need, how much the process rules differ from Decidim's standard flow, how many external systems must be connected, and how quickly your team can approve content and decisions. Accessibility testing and the review of any custom theme usually take longer than teams expect. Ask for a written plan that lists milestones, the decisions you must make at each one, and the acceptance tests. Avoid any timeline that is not tied to a written scope.

What must the public body supply before implementation starts?

The body must provide the written process rules for each consultation, including phases, comment and proposal rules, moderation policy, and how results will be published. It must name a product owner, a moderator team, a legal or records contact, and an approver for content and changes. If participants must be verified, it must identify the census or identity source, its owner, the data fields it holds, and the conditions under which it may be used. Missing any of these usually delays the build more than technical work does.

Can internal staff run a Decidim consultation platform alone?

Internal teams can run the platform after launch if they have Ruby on Rails and PostgreSQL skills, a patching routine, and a tested backup and restore process. Decidim's update documentation asks implementers to upgrade one minor version at a time and to back up the database first, so upgrades need planned effort. Many bodies keep moderation, content and process design in house and buy implementation, hardening and support. Decide this split before you request quotes, because it changes the scope of every bid.

Is Decidim the right fit for a simple consultation?

Decidim fits well when you run several consultations over time, need proposals, comments, meetings and published outcomes, or want a shared platform across departments. For a single short survey with no proposals or public comments, a simpler tool may be enough and cost less to run. Confirm whether your process needs the proposal and meeting components, and whether a survey alone would meet your legal duty to consult. Ask a bidder to show the components you would switch on and the ones you would leave off.

What happens when a new Decidim release comes out?

Decidim supports only the last two minor versions with security updates before version 1.0, currently 0.32.x and 0.31.x, so older lines fall outside security support. Implementers have a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed. Your support agreement should state who monitors releases, who tests the upgrade on a staging copy, how long a patch may wait, and who signs off the production change. Ask for the process in writing before you sign.

Which compliance evidence will a consultation platform need?

Evidence depends on your jurisdiction and the data you collect, but public bodies commonly need accessibility conformance records, a data protection impact assessment input, retention rules for comments and votes, and records of who holds administrative access. Accessibility duties may apply under the ADA Title II rule for US state and local government web content, which requires WCAG 2.1 Level AA from April 26, 2027 for entities serving 50,000 or more people. Confirm your own obligations with your legal team and any independent auditor before you collect evidence.

How DeployOpen scopes, builds and supports a consultation platform

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the Decidim-based consultation setups described on this page. We agree scope, deliverables and timelines in writing before work starts, so the consultation process, its evidence trail and its hosting boundaries are settled up front.

How we scope

Map each consultation type to Decidim spaces and components, such as processes, surveys, proposals and meetings.
Record which phases, comment rules and moderation roles the written scope will configure.
Confirm the hosting location, identity sources and any external map or login services before build starts.
Agree in writing how published results showing how input changed the outcome will be produced.

How we build

Install and configure the platform in your cloud account, data center or air-gapped network.
Customize themes, forms and consultation pages, then test accessibility against WCAG 2.1 Level AA.
Integrate email, file storage, background jobs and any agreed social login providers.
Run security testing on the application and its APIs before launch, and document the findings and fixes.

How we hand over

Deliver runbooks for installation, configuration, backups and the process for moderating and publishing results.
Provide evidence packs with configuration records and test results for your compliance assessors to review.
Train the staff who will run consultation phases, moderate comments and publish outcomes.
Document the upgrade path, including the one-minor-version-at-a-time rule and database backup steps.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
Track Decidim security advisories and plan patches within the disclosure windows the project publishes.
Keep the platform on a supported minor version before each consultation season begins.
Review each consultation's configuration and accessibility after changes to themes or components.