Open source platform for petitions and citizen initiatives

Open source platform for petitions and citizen initiatives: what changes when signatures have legal weight

For a public body that must accept citizen initiatives once they reach a signature threshold, Decidim's initiatives space is the open-source fit for this flow, because it models the stages an initiative passes through, from creation and signature collection to validation and committee review. The harder question is what the platform must prove afterward. A petition with legal effect differs from a consultation in three ways: every signature must be tied to a verified, eligible person, the deadlines are binding rather than advisory, and the record of who signed, when, and how the result was reached must hold up under review by an auditor, a court or an oversight body.

Those three requirements shift the build. Signature verification depends on the authorization handlers and any census or identity integration you configure, so you need to confirm which handlers your jurisdiction accepts and what verification data you are allowed to keep. Deadlines, threshold logic and committee decisions must be tested against your statute, not against default settings, and the initiative's audit trail (exports, logs, and retained database records) must be preserved as part of the public record. Because Decidim upgrades change database structures, the version you run in production also becomes part of the evidence, so plan upgrades and backups as controlled changes.

For this topic, the deployment and host context that matters most is where identity data and signatures are stored, who can administer the database and logs, and how the platform is kept on a supported release. Confirm with your legal team which data protection regime and identity source apply, check the current Decidim security support window in the project's SECURITY.md file before choosing a version, and ask any implementation partner to define in writing how verification, retention and audit exports will be tested before the first initiative opens.

Which requirements shape a petition or initiative build

This table maps each legal or policy requirement to the build decisions it affects for signature collection, identity checks, hosting and records. Read each row as a question to put to counsel and your own compliance lead, since applicability depends on who the body is, what data it holds and where it operates. The main takeaway is that accessibility applies to every initiative page regardless of data type, while FedRAMP, CJIS and CUI rules apply only when specific data or contracts trigger them.

Requirement	What it means for the build	What to confirm
ADA Title II web and mobile rule (WCAG 2.1 AA)	Signature forms, initiative pages, committee documents and any custom theme must meet WCAG 2.1 Level AA, including content supplied through contracts or licenses.	Whether your body serves 50,000 or more people (compliance date 26 April 2027) or is smaller or a special district (26 April 2028).
NIS2 public administration scope	If your body falls in scope, hosting, access control, incident handling and supplier security for the petitions platform are part of the organization's cybersecurity risk measures.	Whether your Member State extends NIS2 to local public administration, and whether the initiative system falls under a national security or law enforcement exclusion.
FedRAMP (cloud services for federal information)	Only a cloud service that processes federal information on behalf of an agency as a shared service falls in scope. A self-hosted build in your own infrastructure is usually outside this scope.	Whether any federal agency data enters the platform, and whether a hosting provider offers the platform as a shared service.
FBI CJIS Security Policy v6.1	Applies only if criminal justice information is stored or processed. Encryption in transit and at rest would need FIPS 140-3 validated modules or AES with at least 256-bit keys, and vulnerability scanning at least monthly.	Whether signatories, committee records or attachments could include criminal justice information, and whether a CJIS agency agreement applies.
32 CFR 2002.14(h)(2) (CUI on non-federal systems)	Where a federal agency sets requirements for controlled unclassified information on a non-federal system, NIST SP 800-171 is the default baseline unless the CUI category prescribes other safeguards.	Whether any initiative data is designated CUI under an agency contract or agreement, and which safeguards the contract requires.
Records and audit trail	Signature counts, verification outcomes and committee decisions need to be retained and reproducible for review. Keep verification data to the minimum the rules permit.	The retention period for signatures and identity evidence, and who may access verification records.

How Decidim's initiatives space models each step

Decidim models a petition or citizen initiative as an *initiatives space*, one of the participatory spaces alongside processes and assemblies. The space is where the initiative lifecycle lives: an initiative is created, moves through a signature collection window with a deadline, and then reaches a review step where the body decides what happens next. Each stage is a state the platform tracks, so the team running the process should map the body's own steps to those states before configuring anything. The point to settle first is whether every initiative type follows the same path or whether some types skip or add a review stage.

Several parts of the build depend on how the body answers questions that Decidim does not answer for it. The signature threshold, the number of signatures needed for each initiative type, the length of the collection period, and who sits on the committee that reviews a successful initiative are all set in the installed version's configuration and administration screens, and they must follow the body's own rules. Confirm these values against the exact Decidim release in use, since the initiatives workflow has changed between releases, and test each state transition on a staging copy with dummy initiatives before opening the space to the public.

Signature collection is where verification and records meet the lifecycle. Each signature should be tied to an identity check that the body has approved, and the deadline must close collection consistently for all signers. Ask the implementation partner to demonstrate what happens at the deadline, how a signature is recorded and whether a signer can withdraw support, and confirm how the committee's decision is published and archived. Plan for the risk that a deadline or threshold is misconfigured after launch, because changing an initiative's rules mid-collection can invalidate support already given.

Which open-source platforms fit petitions and initiatives, and why

Petitions and citizen initiatives combine public forms, signature thresholds, deadlines and committee review. The platforms below differ mainly in whether they model those steps natively or leave them to custom build. Confirm licence obligations and version support before you choose.

Decidim initiatives space

Decidim is the primary fit because its initiatives space models the petition lifecycle as a native participatory space: creation, signature collection, a threshold, and committee review. Its processes, assemblies and budgets sit in the same instance, so one identity layer covers every participation type. Check how the initiative types you need map to its configuration, and test signature collection with your own verification rules before launch. Ask your implementer which steps need custom work.

AGPL-3.0 licence obligations

Decidim is licensed under the AGPL-3.0, a copyleft licence whose network clause can apply when you modify the software and let users interact with it over a network. A public body that changes Decidim, for example with a custom initiative workflow or theme, should have counsel confirm what source must be published and how. Record the modifications from day one so the obligation is manageable.

Version support before selection

Decidim supports only its last two minor versions with security updates until version 1.0, so the 0.32.x and 0.31.x branches are the ones currently covered. Earlier branches such as 0.30.x are not. Confirm the branch you select, the patch windows for critical and standard vulnerabilities, and the upgrade path to the next minor release, which must be taken one minor version at a time.

Drupal or WordPress front end

Drupal or WordPress can host a separate petition front end, such as a campaign site with explanatory content and a link into the participation platform. They do not track signatures, verify identities or enforce thresholds on their own, so a signature count on a CMS page is not evidence of a valid initiative. Keep the signature record in the dedicated platform and treat the CMS as presentation only.

When a dedicated platform is required

A dedicated participation platform is the better fit whenever signatures must be tracked, deduplicated and verified against eligibility rules. Custom forms on a generic CMS or survey tool can collect names, but they struggle with one person one signature controls, audit trails and committee decisions. Ask any candidate how each signature is verified, where the record is kept and how it is exported for review.

Where the hosting decision changes the build

When Decidim runs in a data center that your body owns or contracts directly, cloud-specific rules such as FedRAMP scope mostly fall away. Your team still operates the full stack: the Rails application, PostgreSQL, background jobs, file storage, SMTP and the operating system beneath them. The control baseline is set by your own risk assessment. NIST SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively, and the choice should follow the sensitivity of signature, identity and census data.

FedRAMP scope: A platform that serves only your own body, on infrastructure you control, is generally outside FedRAMP's cloud scope. Confirm this with your national or federal authority if a shared service model is ever introduced.
Baseline selection: Record which baseline you chose and why, so an assessor can trace each control back to the risk decision.
Patch cadence: Decidim supports only the 0.32.x and 0.31.x lines until version 1.0, and gives implementers 2 months to patch standard vulnerabilities and 4 months for critical ones. Your change calendar must fit those windows.
Login providers: The built-in Facebook, Twitter and Google providers send sign-in activity to those companies. Decide whether your rules allow that, or limit sign-in to government SSO and authorization handlers.

Before launch, confirm with your data center operator who owns patching, backups, log retention and physical access, and whether the facility's accreditation covers the platform's data classes.

How a petition platform rollout runs, phase by phase

The sequence turns a legal and policy brief into a Decidim initiatives space that has been configured, verified, tested for accessibility and reviewed after its first signature cycle, with each phase closed by a written output the owning team signs off.

Map legal and rule requirements
The council or public body's legal team, the clerk, and the DeployOpen solution lead go through the statute, bylaws and local rules that govern petitions and citizen initiatives. They record who may start an initiative, what signature threshold applies, which types exist (for example, petitions to the council versus binding or consultative initiatives), what personal data must be collected, how long collection runs, and who decides on outcomes. Output: a signed requirements register that every later step traces back to. Confirm with your counsel whether any data retention or publication rule applies before anything is configured.
Configure initiative types and thresholds
Working from the register, the team maps each initiative type to a Decidim initiatives space configuration, including signature thresholds, collection periods, required fields, and the stages an initiative passes through from creation to validation, collection, and committee review. DeployOpen implements these settings in the codebase or configuration as agreed in the written scope, and the business owner reviews a walkthrough of each type. Output: a configuration matrix that lists every type, threshold and state transition, approved by the business owner.
Design identity and signature verification
The security lead and the civil registry or identity team agree how a signer is proven to be eligible, whether through an existing SSO or eID integration, an authorization handler, or a census check. They also define what verification data is kept, how duplicate signatures are blocked, and what is published. Each integration is tested against the agreed data flow and documented. Output: a verification design record that names each data source, the attributes it returns, and the retention period set by the controller.
Stage with test initiatives
DeployOpen deploys the configured platform to a staging environment that mirrors production in its database, storage, mail, and background job setup. Test initiatives run through every state, including signature collection at and around the threshold, expiry of the collection period, duplicate and ineligible signature attempts, and committee review. Testers record defects and the team fixes them until the scripted scenarios pass. Output: a signed test report with each scenario's result and any accepted risks.
Test accessibility against WCAG 2.1 AA
The team tests the signature form, initiative creation pages, sign-in flow, and any custom theme against WCAG 2.1 Level AA, using automated checks and manual keyboard and screen reader testing with representative users where possible. Each finding is logged with its success criterion and fixed or formally accepted. The US ADA Title II rule sets WCAG 2.1 Level AA as the standard for state and local government web content and mobile apps, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. Output: an accessibility test report and a remediation log that the accountable officer signs before launch.
Launch and review the first cycle
Before going live, the team confirms backups, monitoring, and a tested rollback. Launch is followed by a review of the first initiative cycle: signature counts, verification failures, support tickets, email delivery, and any accessibility complaints. Changes go through the normal change process. Output: a first-cycle review note that lists defects, the owner of each, and any configuration changes for the next cycle.
Keep Decidim upgrades disciplined
Decidim's update guide says to back up the database before any upgrade, to move one minor version at a time (for example 0.29 to 0.30 before 0.31), and to follow each release's upgrade instructions because some change database structures. Decidim supports only the last two minor versions with security updates until version 1.0, currently 0.32.x and 0.31.x, so the operator should plan a path onto a supported line. Output: a dated upgrade plan with a tested restore point and a staging run before each production step. Confirm the current support window with the Decidim project before scheduling work.

Integration points that carry signature and identity data

A petition or citizen initiative platform touches identity, registries, email, background jobs, file storage and location data at the same time. Each connection either keeps signature data inside the boundary of the organization or sends part of it to a provider, so each one needs an owner and a documented decision.

Identity provider through OmniAuth

Decidim authenticates users through OmniAuth strategies. Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 are available out of the box, and a custom OmniAuth strategy can connect the organization's own identity provider. For signature collection, the login method is the first control on who can sign, so check which attributes the provider returns, whether it asserts that the person is a resident, and whether it can be hosted in the organization's own infrastructure. Social providers send login events to their own services, which must be assessed before launch.

Census or registry lookup

When an initiative needs a residency or eligibility check, the platform compares the signer against a census or registry. Decidim's authorization handlers can run such checks, but the lookup must be specified with the registry owner: which fields are matched, whether the check returns a yes or no answer or a full record, and how often the data is refreshed. Ask the registry owner whether the check can run inside the boundary and what it logs, because a record returned to the platform becomes personal data the organization must retain and protect.

SMTP for confirmation emails

Signature confirmation, verification codes and deadline notices all leave the platform through SMTP. Mail often passes through a relay operated by a third party, which can see the recipient address and the subject line, which may reveal that a person signed a specific initiative. Confirm whether the relay is hosted in the organization's jurisdiction, what the message content contains, and how bounces are handled. Do not include the signed initiative title in messages unless the organization has decided that disclosure is acceptable.

ActiveJob for deadline and threshold checks

Deadlines, signature thresholds and committee review triggers depend on scheduled work. Decidim uses ActiveJob for background processing, and production setups need a queue backend running reliably so that a closing deadline is not missed or processed twice. Check which queue adapter is configured, how failed jobs are retried and monitored, and who is alerted when a threshold is reached. Missed or duplicated threshold events are a governance problem as well as a technical one, so record each automatic status change.

ActiveStorage for supporting documents

Initiative promoters often attach statutes, legal opinions, support letters or scanned identity evidence. ActiveStorage stores these files, and the storage service decides where they sit. Confirm the storage backend, whether files are encrypted at rest, who can download them, and how attachments are removed when a retention period ends. Scanned identity documents should not be stored at all unless a legal basis and a retention rule require it.

Maps and geocoding for residence

If an initiative only counts signatures from a district or municipality, address-based checks may use maps or geocoding services. Many default geocoding and map providers are hosted outside the organization's country and receive address text on each request. Decide whether a boundary match can be done against a locally hosted dataset, what the provider logs, and whether the transfer needs contractual safeguards. Address fields should be collected only when the eligibility rule needs them.

Evidence a regulator or auditor will ask to see

This table lists the evidence artifacts a reviewer may request for a Decidim initiatives space, the component that produces each one, and what the reader should confirm before go-live. DeployOpen prepares this evidence for the client, but independent auditors and certification bodies issue any audit reports or certifications.

Evidence artifact	Component that produces it	What the reviewer checks
Signed configuration records	Decidim initiatives space settings, initiative type definitions and deployment configuration under version control	Signature thresholds, deadlines and committee membership match the approved rules, and changes are traceable to an approver
Signature audit log	Decidim initiative signature records and the application database, with server logs retained outside the application	Each signature maps to one verified identity, with timestamp, initiative and authorization method recorded
Verification outcome records	Decidim authorization handlers, census uploads or OmniAuth identity provider logs	Failed and successful checks are recorded, and the record shows which data was kept and which was discarded
Accessibility test reports	Custom theme tests and the accessibility review of initiative forms and signature pages	Results against WCAG 2.1 Level AA for the initiative flows, with open defects logged and dated
Backup and restore test results	PostgreSQL backups and the file storage used by ActiveStorage, tested in a separate environment	A restore completed from the most recent backup, with the time taken and any data gaps recorded
Patch and upgrade records	Decidim release tracking and the deployment change log, checked against the security support window	Running version is within the supported 0.32.x or 0.31.x line, and patches were applied within the disclosure windows
Data retention schedule	Operator retention policy applied to signature data, personal data and committee records in the database	Signature and identity data are kept only for the period the organization sets, with a documented deletion process

Which legal duties change signature collection and committee review

Three legal duties change how a Decidim initiatives space should be built: accessibility, data protection for signer data and records retention. The accessibility duty is the most concrete for public bodies. The ADA Title II rule requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. For an initiative, that means the signature form, the identity verification step, the committee review screens and any custom theme all need testing, not only the default pages. Confirm with counsel which rule applies to your body and whether it is a US state or local entity, since the EU Web Accessibility Directive and other regimes apply different standards.

Signer data is the second area. A signature list links a named person to a political act, so the team should map every field collected, where it is stored (database, ActiveStorage uploads, logs, email relays), and who can export it. Decidim's authorization handlers and any OmniAuth login, such as the Decidim-to-Decidim OAuth 2.0 option, determine what verification data is kept. Ask counsel for the lawful basis for collecting and processing each field and for the retention period for signatures, verification records and committee notes. Records retention rules also decide whether the initiative's database backups, which Decidim's update guide requires before every upgrade, can be kept after a signing window closes.

The body should also decide early whether NIS2 or a federal framework applies to the hosting. NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality, while Member States may extend it to local public administration. It does not apply to entities working in national security, public security, defense or law enforcement. For US federal or federally connected deployments, NIST SP 800-53 Rev. 5 and the FedRAMP scope rules in OMB M-24-15 determine whether a cloud host is in scope. Confirm your status with counsel and your oversight body before the hosting design is fixed, because it changes logging, vendor selection and the evidence you must keep.

How much work is a petitions platform, and what does it need from us?

What drives the cost of a petitions platform on Decidim?

The cost follows the written scope, and the largest drivers are the number of initiative types, the verification sources behind signature checks, the accessibility testing you require, and the hosting model you choose. Each initiative type carries its own signature threshold, deadlines, committee rules and export format, so every additional type adds configuration, testing and review work. Verification is usually the costliest line: a census upload is simpler than a live connection to an identity provider or government eID, which needs integration, security review and test accounts. Hosting in your own cloud account or data center adds infrastructure and operations work that a managed service would otherwise absorb. Ask any partner to price each initiative type and each verification source as separate line items, and to state which parts are one-time and which recur.

How long does it take to launch a petitions platform?

Timing depends on how many initiative types you launch with, how many identity sources must be connected, and how quickly your legal and policy owners sign off on rules. Installation on a clean environment is typically the shortest phase. Identity integration, custom theming, accessibility testing and the legal review of signature thresholds and deadlines usually take longer, and they often wait on people outside the project. Decidim's own upgrade guidance also means you should plan for the version you start on, because each later minor upgrade needs its own testing window. Ask for a timeline in the written scope with milestones tied to your decisions, not just calendar dates, and confirm which dependencies on your side could move the schedule.

What must our team provide before implementation starts?

Your team needs to supply four things before build work begins. The first is the legal rules: the thresholds for each initiative type, the time windows for collection, the criteria for admissibility and the review steps the committee must follow. The second is census access, meaning the data source, its format, its update frequency and the authority to use it for verification. The third is a set of named sign-off owners for policy, legal, data protection and accessibility, each with a deadline for approval. The fourth is a decision on who holds administrator rights after launch. Missing any of these usually shifts work into late stages, where changes are expensive. Confirm these inputs in writing as part of the scope, so both sides know what triggers a change request.

Can our own staff run a petitions platform without outside help?

Some organizations run a petitions platform with in-house staff, but it depends on skills and capacity rather than on the software alone. Operating Decidim means managing a Ruby on Rails application, a PostgreSQL database, background jobs, file storage, email delivery and social login configuration. Upgrades must follow each release's instructions, back up the database first and move one minor version at a time. Security patches also have a limited window, so someone must monitor advisories and apply fixes promptly. Many teams keep configuration and content ownership in-house and bring in a partner for installation, identity integration, hardening, backups and upgrades. Ask a partner which parts they would hand over to your staff and which they would retain under a support agreement.

How is the fixed scope of a petitions engagement defined in writing?

A fixed-scope engagement lists the initiative types, components, integrations, languages, themes, environments and testing activities in scope, along with the deliverables and acceptance criteria for each. It also states what is excluded, such as new initiative types added after kickoff, custom features outside Decidim's standard initiatives space, or work on a second environment. Good scope documents name the sources of verification data, the accessibility standard and the level of testing agreed, and they state who signs off each milestone. Changes are handled through a written change request that records the effect on cost and schedule. Ask for a draft scope before any commitment and check that every assumption about your internal inputs is written down.

Which accessibility testing should we budget for a petitions platform?

The testing scope depends on the accessibility duties that apply to your body and on how much you customize the theme. For US state and local government, the ADA Title II rule requires web content and mobile apps to meet WCAG 2.1 Level AA, with compliance dates that depend on the population you serve. Custom signature and petition forms, identity prompts and export pages are the parts most likely to fail, so they need targeted testing with assistive technology. Testing scope should cover every initiative type's form flow, not only the home page. Ask a partner to define which pages, user journeys and browsers are tested, who performs the review, and how defects found after launch are handled. Confirm your own legal reading of the rule with counsel.

What engineering risks should we check before choosing a partner?

Start with version support, because Decidim supports only the last two minor versions with security updates until version 1.0, so the release you deploy must be one of those. Check the patch windows described in the project's security policy, and ask how the partner will apply them within those windows. Verify the partner's approach to database backups before each upgrade, since some releases change database structures. Ask how they will test signature counting, deadline logic and identity checks, because errors there affect legal outcomes. Finally, confirm who holds production credentials, where backups are stored and how access is logged. Request written answers to each point and keep them in the contract.

How DeployOpen scopes and supports a petition platform

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For petitions and citizen initiatives, we start from your legal thresholds and review process, then configure Decidim's initiatives space to match them.

How we scope

We confirm the initiative types, signature thresholds and deadlines your rules require before any configuration starts.
We define how verified signatures are collected, which identity sources are used and what verification data you keep.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and a quote follows from that scope.

How we build

We deploy Decidim in your cloud account, data center or air-gapped network, with background jobs, file storage, SMTP and maps configured.
We configure initiative types, signature stages and committee review steps, and test each transition against your written procedure.
We integrate the chosen identity provider or authorization handler and test signature validity, duplicate prevention and deadline handling.

How we hand over

We document the configuration, roles, review workflow and signature verification steps so your staff can operate and audit them.
We set up backups of the database and file storage and test a restore before handover.
We provide a runbook covering upgrades, which Decidim requires one minor version at a time with database backups first.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after go-live.
We track Decidim's supported release lines and patch cycles so your instance stays within the security support window.
We prepare the system, controls and evidence your compliance assessors need, while independent auditors issue any formal findings.

Open source platform for petitions and citizen initiatives