How to use a citizen participation platform requirements checklist
A public body that must choose or build a participation platform needs a way to compare options before committing budget and staff time. This checklist turns three things into testable requirements: the legal duties the body carries, the expectations residents bring to a consultation or budget vote, and the operating capacity the organization can sustain after launch. Each row should be verified by a live demo, a document or a test, never accepted on a vendor's word. A row that says the platform supports verified voting is only useful once you have seen the authorization flow run against your own census data, or read the configuration that enforces it.
Work through the checklist in the same order for every shortlisted option. Start with functional must-haves such as spaces, components and voting rules, then move to hosting and data residency, identity and access, privacy and retention, integrations, and operations and support. Ask each vendor or partner to show the evidence in your environment or a sandbox that mirrors it. The examples in this hub assume a self-hosted Decidim deployment, since that is the platform this group covers, but the structure applies to any option on the shortlist. Where a candidate cannot produce evidence for a row, record it as an open risk rather than a pass.
Keep the checklist as a living document that the legal, security, records and communications teams all sign off. Confirm which Decidim release line the candidate would run, because the project supports only its last two minor versions with security updates, so the upgrade path is part of the requirement. Confirm, too, who owns patch windows and who answers security reports. Those answers belong in the checklist alongside the functional rows, because they decide whether the platform is still safe to run in year three.
Which functional must-haves a citizen participation platform needs
This table lists the functional requirements a self-hosted Decidim platform should meet, with why each one matters and how to verify it before you commit. Use the verification column to script a demo or run a test instance against your own participation processes, not the vendor's sample data. The main takeaway is that most gaps show up in voting rules, verification and results publishing, so test those first.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Participatory spaces (processes, assemblies, initiatives) | Each legal or policy route to participation, such as a consultation, an assembly or a citizen initiative, needs its own space with its own phases and rules. | Build one process, one assembly and one initiative from your own templates and confirm each keeps separate phases, visibility and permissions. |
| Meetings and surveys components | In-person meetings and structured questionnaires often carry the consultation record and must be published alongside online input. | Create a meeting with registration and a survey with a closing date, then check that results and attendance records export cleanly. |
| Proposals with comments and moderation | Proposals and comments are where most content risk sits, so reporting, hiding and moderator queues must match your house rules. | Submit test content as a participant and as a moderator, then confirm reports, hidden items and audit history behave as your policy requires. |
| Participatory budgets | Budget rules such as per-district allocations, minimum thresholds and vote limits define whether the outcome is lawful and defensible. | Configure a sample budget with your real rules, cast votes at the limit and above it, and check the rejection messages and totals. |
| Accountability tracking | Publishing what happened to funded or accepted proposals is what closes the feedback loop residents expect. | Attach statuses and updates to a funded project, then confirm the public page shows history and the status changes are timestamped. |
| Voting and signature rules | Eligibility, one-person-one-vote controls and signature thresholds decide whether results can be trusted and challenged. | Run each rule against edge cases: duplicate accounts, expired signatures, out-of-area users, and votes after deadline. |
| Multi-language content | Public bodies serving several languages must publish the same content in each, with fallbacks that do not leave readers stranded. | Publish one process in every language you serve, check locale-prefixed URLs, and confirm untranslated fields show a clear fallback. |
| Public results publishing | Results must be readable, exportable and linked to the decision they informed, so outcomes can be audited by residents and oversight bodies. | Close a voting phase, publish results, then export the data and confirm it matches the on-screen totals and the published record. |
Where the platform runs and where participant data stays
Set the hosting rules before you compare platforms. Decide which cloud accounts, data centers or air-gapped networks the organization permits for the application, its database and its file storage, and who may administer them. Write down where encrypted backups may be stored, including off-site copies and any replica used for recovery, because a backup in an unapproved region can breach the same residency rule as the live system. Decidim is a Ruby on Rails application on PostgreSQL, so every one of these components needs a named home in the approved hosting model before a quote is requested.
Map each external service that the installation depends on. Decidim production setups typically configure background jobs (ActiveJob), file storage (ActiveStorage), SMTP for notification email, maps and geocoding, and social login providers. Each of these can send personal data outside your network. For every one, confirm in writing where the provider processes and stores data, which sub-processors it uses, and what transfer mechanism covers any data leaving the region. Ask the provider for its data processing terms and check whether the chosen SMTP relay, map tiles or geocoding API can be self-hosted or replaced with a provider inside the approved jurisdiction. Note that social login sends participant identifiers to the identity provider, so it is often the first service to rule out for a sovereignty requirement.
Turn these decisions into a configuration inventory that an implementation partner can price and test. List each service, the environment variable or configuration file that points to it, the region of the endpoint, the data categories it receives and the owner who signed the transfer terms. Confirm the exact settings against the Decidim installation documentation for the version you plan to run, since defaults and optional providers change between minor releases. Then test the chosen mail, storage and map endpoints from inside the approved network before go-live, and record the results as evidence for your data protection review.
Which security controls to require before launch
A participation platform holds identities, votes and personal opinions, so the controls below should be agreed in writing before launch. Each card names a control, why it matters for this checklist, and what to confirm in your own environment.
Authentication hardening
Staff, moderators and participants should sign in through controls you can explain to an auditor. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box, and other OmniAuth strategies can be added. Confirm which providers are enabled per organization, whether the social providers are acceptable for your data rules, how admin accounts require multi-factor authentication, and how session timeouts and password rules are set.
Role-based access for staff and moderators
Moderators, process managers and administrators should each see only the spaces and actions their role needs. Map every role to a named duty before go-live, and confirm that a moderator cannot change vote settings or export participant data. Review who holds administrator rights in each participatory space, remove accounts when staff leave, and test the permissions with a non-admin account before launch.
Audit logging
You need a record of who changed a proposal, closed a voting phase, edited a budget or exported data, and when. Confirm that the platform's activity and admin logs are kept, forwarded to a central store you control, and protected from edits by the people they record. Agree the retention period for these logs with your legal team, since the logs themselves may hold personal data.
Encryption in transit and at rest
All participant traffic should use TLS, and database backups, uploaded files and mail queues should be encrypted at rest on infrastructure you control. Confirm the certificate process, the TLS versions and ciphers accepted at your load balancer, and where ActiveStorage files and PostgreSQL backups are written. Include backup copies in the same encryption and access rules as the live database.
Vulnerability handling and patch timing
Decidim's security policy is the reference point for patch planning. Until version 1.0, only the last two minor versions receive security updates, currently 0.32.x and 0.31.x, so 0.30.x and earlier are unsupported. The project gives implementers 2 months to patch standard vulnerabilities and 4 months for critical ones before details are disclosed. Report suspected issues to security@decidim.org or through GitHub Security Advisories, and confirm your own patch window, staging test and rollback steps against these dates.
How identity and verification requirements change by process type
Open consultations usually ask for a verified account to comment or support proposals, but they rarely need proof of residence or a national identity match. The main requirement is that one person is one participant in the discussion, and that the record of who spoke is kept in a form the organization can defend. Decidim's built-in accounts, with email confirmation, cover many consultations without a third-party identity service.
- Built-in accounts: Email confirmation and a password policy are often enough for low-stakes consultation. Confirm the minimum standard with legal counsel.
- Social login: Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 can be enabled globally or per organization. Each provider sends personal data to a company outside your control, so confirm the data transfer position before enabling it.
- Custom OmniAuth providers: A government or university identity provider can be added as a custom strategy if you need a stronger sign-in than social login.
- Pseudonymous participation: Decide whether public display names can differ from the account holder's legal name, and document the rule in the terms.
- Retention: Keep the account record for as long as the participant is active, and confirm with legal counsel how deleted accounts are handled for published comments.
Confirm with your legal team whether a consultation can be answered anonymously and with your identity provider which login methods it supports.
Participatory budgeting often restricts voting to residents of a district or to people on a census, so identity checks become a eligibility question rather than a sign-in question. The platform must confirm the voter is eligible, confirm they vote once, and keep only the evidence the rules require. Decidim provides authorization handlers for this purpose, and the choice of handler depends on what your eligibility data looks like.
- Eligibility source: Identify whether eligibility comes from a census file upload, a government identity service, or a campus or employee directory. Each source carries different accuracy and data protection obligations.
- Authorization handlers: Map each voting rule to a handler and test it with sample records before launch, so rejected voters receive a clear reason.
- One person, one vote: Decide how duplicate accounts are detected, and whether the check uses identity data that you may only hold for a short period.
- Verification data: Store the outcome of the check (eligible, district, date) instead of the raw identity document wherever the rules allow. Confirm this with legal counsel.
- Results audit: Keep enough evidence to show how a vote was counted without linking it back to a named individual.
Confirm with your legal team which data may be kept after voting closes, and with your identity provider which attributes it can release for the check.
Signature-based petitions and citizen initiatives carry the highest identity assurance requirement, because a signature may trigger a formal duty for the body receiving it. Signatures usually need to be verified against a signature threshold, and the verified count may be published or submitted to a committee. Decidim's initiatives space models these steps, but the assurance level must come from the legal framework that governs the initiative.
- Assurance level: Confirm the level of identity assurance the law requires, and whether a government eID or a census match is mandatory rather than optional.
- Login options: Built-in accounts or social login are usually insufficient for this purpose. A custom OmniAuth provider linked to an official identity service is the typical route, and it must be tested with your own identity provider.
- Signature records: Keep the fact that a signature was verified and the time it was made, and discard identity attributes that the verification no longer needs.
- Public display: Decide whether signatures are published with names, initials, or counts only, since this decision also affects retention.
- Challenge process: Plan how a signatory can dispute a rejected signature and how long those records are kept.
Confirm with your legal team the minimum assurance and retention rules for signatures, and with your identity provider what it can verify and what it will log.
Which integrations a participation platform must support
A Decidim deployment rarely stands alone. Identity, census data, mail, maps, storage and reporting feeds each move personal data across a boundary, so each one needs a named owner and a test before launch. The cards below cover what flows, who keeps the integration running, and what to verify.
Identity provider or government eID
Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box, and any other OmniAuth strategy can be added as a custom provider. Confirm which login providers are allowed for participation and which are only for account convenience. Before launch, test the full callback path, the attributes returned to Decidim, what happens when a user's identity is revoked, and that disabled providers stay disabled for every organization on the instance. Assign an owner for certificates, client secrets and provider changes.
Census and registry lookups
Where only eligible residents may vote or sign, the platform needs a way to check identity against a census or registry. Decide whether this is a live lookup, a periodic file upload or a manual check, and document which fields leave the registry and which are discarded after verification. Test with known eligible and ineligible records, duplicate names, address changes and expired registrations. Agree in writing who refreshes the data, how often, and who answers when a resident disputes a result.
SMTP and mail deliverability
Notifications, verification codes and password resets all depend on the SMTP service configured for the installation. Confirm the sending domain, SPF, DKIM and DMARC records, bounce handling and the volume a large consultation could generate in a single day. Test delivery to the major mailbox providers your residents use, and check that messages to people who have withdrawn consent are suppressed. Name who monitors the sending reputation and who holds the relay account after go-live.
Maps and geocoding
Participatory budgets and local proposals often tie to a location, so the platform may call a map tile service and a geocoding service. Each call can send addresses or coordinates to a third party, which matters for data residency and for the privacy notice. Decide whether to use a self-hosted tile and geocoding service, a provider inside your jurisdiction or no external call at all. Test that map features still work with the external service blocked and that the provider's terms allow your use.
File storage
Decidim uses ActiveStorage for uploaded files such as proposal attachments, supporting documents and images. Decide where those files live, whether on local disk, network storage or an object store in your own infrastructure, and how they are encrypted at rest and backed up with the database. Test large uploads, file type restrictions, malware scanning if your policy requires it, and restoring a file from backup alongside its database record. Confirm who can purge files when a participant asks for deletion.
Export and reporting feeds to records systems
Results from votes, budgets and consultations often must be filed in the organization's records management, council minutes or open data systems. Define the export format, the fields included, the frequency and the authority that receives each feed. Test that exports reconcile with the platform's totals, that personal fields are removed where required, and that re-running an export gives the same result. Assign the owner who maintains the export job when the records system changes.
How privacy and retention rules shape the requirements list
Before comparing self-hosted options, write down the privacy decisions the platform must support, because each one becomes a configuration, a process or a contract term. The first is the lawful basis for each participation activity. A budget vote, a consultation and a petition signature may rest on different grounds, and the requirements list should state which activity uses which basis, which personal data each activity collects, and which fields are mandatory. Decidim's authorization and registration settings decide what is asked at sign-up, so the list should name every field and mark it as required, optional or never collected.
Political opinions and other sensitive data need their own line items. A participant's position on a proposal can reveal political views, so the list should specify whether proposals, comments and votes are published with names, shown under pseudonyms, or kept visible only to moderators. Pseudonymous participation should be a stated requirement with a clear test: which screens, exports and API responses expose the author, and which do not. Retention periods also need explicit values for proposals, votes, verification records and deleted accounts, plus a rule for what happens to a voter's census or identity check after the vote closes. Participant rights, including access and deletion requests, need a named owner and a documented procedure, since the platform does not decide these alone.
Finally, record the data processing terms with any host, including where backups, logs, email relays and map or geocoding calls send personal data. Ask the hosting provider for its processing agreement and sub-processor list, and confirm the data location for every service the platform calls. The GDPR sibling topic covers the legal detail. Legal sign-off, not the platform vendor, should approve the lawful basis, retention values and transfer decisions, and the vendor's default settings should be treated as a starting point for that review, not as the answer.
How to verify operational and support requirements
This table lists the operational and support requirements a Decidim team should pin down before comparing hosting options, with the runtime versions each release asks for and the evidence to collect. Read each row as a question to answer in your own staging environment or in a written vendor schedule, and treat any gap as a blocker for go-live.
| Requirement | What to confirm | How to verify |
|---|---|---|
| Installation method | Manual Rails application or Docker, and who maintains the image or host configuration | Build a staging instance with the method you will run in production and record who owns each layer |
| Runtime versions for v0.32 | Ruby 3.4.7 and Node 22.14.x, plus PostgreSQL 17.4 or later for the manual guide | Install the stack on the target OS image and confirm the versions match the release documentation |
| Runtime versions for v0.31 | Ruby 3.3.4 and Node 22.14.x for the 0.31 branch still receiving security fixes | Confirm which branch you are deploying and that your base images pin these versions |
| Upgrade path | One minor version at a time, following each release's upgrade instructions because some change database structures | Rehearse the full upgrade sequence in staging, starting from your current version, before any production change |
| Database backup before upgrade | A verified backup taken immediately before each upgrade step | Restore the backup into a separate database and run the application against it |
| Backup and restore testing | Scheduled backups of the database and file storage, with a documented restore time and owner | Run a timed restore into an isolated environment and check that uploaded documents and votes are present |
| Security patch window | Ability to apply patches inside the grace periods Decidim gives implementers before disclosure | Confirm a named owner, a test environment and a patching runbook for standard and critical fixes |
| Monitoring and alerting | Health of the application, background jobs, SMTP delivery and database, with alerts routed to a staffed team | Trigger test failures for queued jobs and mail delivery and confirm alerts reach the on-call contact |
| Uptime and support terms | Any uptime commitment, support hours and response times, written into the contract | Request the written support schedule and compare it against the voting calendar of your processes |
How to score and narrow the shortlist
This sequence turns a long list of self-hosted options into a short list that has passed hard requirements, been tested against a real process, and been compared on evidence rather than marketing. Each step leaves a written record that the next step relies on.
Confirm must-haves as pass or fail
Take the functional and legal must-haves from this checklist and mark each option pass, fail or unknown. Anything marked unknown goes to the vendor or community as a written question with a response date set by your team. A candidate that fails a must-have is removed from the shortlist, with the reason recorded. The output is a pass or fail matrix signed off by the business owner and the security lead.
Run a scripted demo against one real process
Pick one participatory process your organization actually runs, such as a budget vote or a consultation with phases, and write a demo script that walks through it end to end. Include a moderator action, a participant with a restricted audience, an export and a results page. Run the same script on every remaining candidate, using the same test data and the same staff member where possible. The output is a dated script with pass, partial or fail notes for each step.
Check license and edition obligations
Confirm under which license each candidate ships and whether any feature you need sits in a separately licensed edition or add-on. For Decidim, the core framework is licensed under the AGPL-3.0, so your legal team should review what that means for any custom modules or themes you plan to publish or host for others. Ask each option for a written statement of its license terms and any paid components. The output is a licence review note filed with legal.
Verify hosting and external services
Map every external service the platform calls, including email delivery, maps and geocoding, social login providers, and file or media storage. For each one, record where the data is processed and whether it leaves your chosen jurisdiction. Confirm that the target hosting environment can run the candidate's required database and runtime versions. The output is a data flow diagram with each external service marked as in-house, in-region or out-of-region.
Request security and upgrade evidence
Ask each remaining candidate for its supported-version policy, its vulnerability disclosure process and the patch windows it gives implementers. Request the latest security advisories and the upgrade guide for the last two minor releases, and check whether upgrades require database changes and whether they must be applied one minor version at a time. Ask who on your side will receive security notices and how quickly they must be applied. The output is an evidence file per candidate, with the source and date of each document.
Score remaining options on operating fit
Score the candidates that remain on a fixed set of criteria: fit with the demo results, staff skills, upgrade effort, support model after go-live, and the internal and external people each option needs to operate. Use the same weights for every candidate and agree them before scoring begins. Record the reason for each score in one sentence so a later reviewer can challenge it. The output is a scored shortlist of two or three options, with the evidence reference for every score.
What buyers ask before hiring help for a participation platform
How much does it cost to run a self-hosted Decidim platform?
The running cost is mostly hosting, operations time and upgrade work, and none of these figures come from a supplied source, so ask for each line separately. Hosting depends on where the platform runs (your cloud account, a data center or an air-gapped network), the expected participant load, and the storage used for uploads and backups. Operations covers patching, monitoring, backups and restore tests, which recur every month. Ask any partner to split the quote into one-time setup and recurring support, and to state which infrastructure costs are billed to you directly.
How long does a Decidim rollout take?
The duration depends on scope, and no timeline figure is supplied for this page, so ask the partner to state one in the written scope. The main variables are the number of participatory spaces and components, custom themes, data migration from existing tools, and identity integration with your census or single sign-on. Acceptance testing by your own staff and any accessibility review also add time. A fixed-scope agreement should list each phase, its deliverables and the decisions your team must make before work starts.
What must our internal team supply before implementation starts?
Your team must supply decisions and access, because a partner cannot make policy calls for you. Typical inputs include the participation rules for each process (who may vote, how signatures are verified, what is published), the list of identity sources, the hosting account or network where the platform will run, and a named owner who approves content and accessibility fixes. Confirm in writing who signs off on the scope and who receives training at handover.
Can our own staff run Decidim after launch without a partner?
Some organizations run the platform in-house, but this depends on existing skills in Ruby on Rails, PostgreSQL, background jobs, mail and container operations. Decidim's documentation describes production needs such as ActiveJob for background jobs, ActiveStorage for files, SMTP, maps and geocoding, and social login providers, so these must be owned by someone. Ask whether your team can meet the security update window: Decidim's security policy gives implementers a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed.
How are Decidim upgrades handled without breaking live processes?
Decidim upgrades must go one minor version at a time, and each release's upgrade instructions must be followed. The update guide gives the example of moving from 0.29 to 0.30 before 0.31, because some releases change database structures. Back up the database first and test the upgrade on a copy of production. Only the last two minor versions receive security updates before version 1.0, so the 0.32.x and 0.31.x branches are the ones currently supported. Ask the partner who runs upgrades, how often, and whether upgrades sit inside a retainer.
Which version and runtime should a new Decidim install target?
Target the latest supported minor version, which is 0.32.x at the time of writing, unless your timeline requires 0.31.x. Version 0.32 requires Ruby 3.4.7 and Node 22.14.x, while 0.31 uses Ruby 3.3.4 and Node 22.14.x. The manual installation guide uses PostgreSQL 17.4 or later on Ubuntu 24.04.3 LTS. Confirm these against the release notes on the day you build, since minor patches change the requirements. Versions 0.30.x and earlier are not supported with security updates.
What should a fixed-scope quote for a participation platform include?
A fixed-scope quote should list the deliverables, the spaces and components in scope, the hosting model, the identity integrations, the data migration volumes, the acceptance tests and the post-launch support terms. Ask for exclusions in writing, such as third-party maps, geocoding or SMS services, which may carry their own fees. DeployOpen works from a written scope and does not publish a price list, so ask every bidder to price the same deliverables. Confirm whether accessibility testing, security testing and compliance evidence are included or priced separately.
How DeployOpen scopes and supports a participation platform selection
DeployOpen helps teams turn a participation platform requirements checklist into a written, fixed scope before any platform is chosen. We plan, implement and support self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, so residency and access decisions are made with the organization, not handed to a vendor.
How we scope
- We walk through each checklist area with the team: functional must-haves, hosting, identity, retention, integrations and support.
- We record which requirements are mandatory, which are preferred and which need confirmation from the platform maintainers.
- The written scope names deliverables, environments, responsibilities and acceptance criteria before any work starts.
- Engagements are fixed-scope, so the comparison and any follow-on build are agreed in writing with a quote.
How we build
- We prepare a proof of fit for the shortlisted option, testing core spaces, components and authorization against the checklist.
- We configure hosting, background jobs, file storage, email and login providers inside the client's own infrastructure.
- We test the deployment and any custom theme or integration, and record the results against the agreed requirements.
- We document the architecture, configuration decisions and data flows so the internal team can review and maintain them.
How we hand over
- Handover includes runbooks for installation, updates, backups and restore, written for the team that will operate the platform.
- We deliver the requirements traceability record, showing which checklist items were met, deferred or declined.
- Staff roles, administrator access and training sessions are agreed in the scope so ownership is clear at go-live.
- Compliance evidence, such as configuration records and test results, is prepared for the client's own auditors to review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Upgrade planning follows each platform's documented path, including backups before schema changes and minor-version sequencing.
- Security reports and patch tracking for the chosen release line are reviewed with the client's operations team.
- Ask any partner to confirm which support windows, response terms and escalation paths are written into the retainer.
