Citizen participation platform RFP questions

Ask for a version on a supported minor line, currently 0.32.x or 0.31.x, and name the exact patch level in the written scope. Decidim's security policy supports only the last two minor versions until version 1.0, and 0.30.x and earlier are not supported. Version 0.32.0 was released on July 6, 2026, followed by v0.32.1 on July 30, 2026, and the 0.31 branch received v0.31.7 on September 3, 2026. Ask the vendor to explain why it proposes one line over the other, what Ruby and Node versions each requires, and how it will move you to the next minor release. A proposal that starts on an unsupported line should be rejected at this stage.

Confirm in writing that the proposed minor line receives security updates today, and ask how the vendor tracks Decidim's security advisories for that line. Decidim's SECURITY.md gives implementers a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed, so the vendor needs a process that meets those windows. Ask who receives security reports on your behalf, how patches are tested against your custom code, and what happens when a minor line leaves support. Ask for the date each step will be completed in the fixed scope, not a general commitment to keep the platform current.

Custom components and themes are the main source of upgrade effort, because they must be retested each time Decidim changes. Ask the vendor to list every custom component, theme, and override in a written inventory, and to state which party owns each one. Ask whether custom code lives in a separate repository or is patched into the core, since patching the core makes each upgrade harder to review. Ask how the vendor tests custom work against a new minor release before you approve the upgrade, and who pays for that testing under the support terms. The answer determines both the upgrade cost and the risk of a blocked upgrade.

Build a gap list before the RFP is issued, and ask each vendor to mark every item as included, configured, custom, or out of scope. Decidim provides participatory spaces such as processes, assemblies, and initiatives, and components including meetings, surveys, proposals, participatory budgets, and accountability tracking. Map each of your procedures to one of these spaces and components, then record what your rules need that the standard product does not provide, such as a specific vote rule, a signature workflow, or a reporting format. Ask the vendor to confirm each gap item against the version it proposes, since component behavior can change between minor releases.

Treat any answer that says the platform supports all features as incomplete. Ask the vendor to provide a feature matrix tied to the exact version, with each requirement marked as standard, configured, custom, or unavailable. Request a demonstration of your three most important workflows on a test instance running the proposed version, such as a participatory budget with phases and voting. Ask which features rely on third-party services, such as maps, geocoding, or social login, because those services affect data location and may need separate contracts. A vendor that cannot produce this matrix is unlikely to hold to a fixed scope.

Yes, if the gap list is complete before the vendor prices the work. Cost depends on the number of custom components, the depth of any change to the core, the number of themes, and the testing needed for each upgrade. Ask the vendor to price each gap item separately so you can remove items that a configuration change would solve. One-time costs include discovery, custom development, and the first full test cycle, while recurring costs include upgrade testing and support. Ask for the price split by these categories and the assumptions behind each line. DeployOpen does not publish a price list, and a quote follows from the written scope.

It depends on whether your team can follow Decidim's upgrade rules, which require moving one minor version at a time and backing up the database first. Decidim's update guidance notes that some releases change database structures, so each step needs its own upgrade instructions and a rehearsal in a non-production environment. Ask the vendor what documentation it will hand over, including the custom inventory, the upgrade runbook, and the test scripts. Then decide whether your staff can run these steps on schedule or whether a support retainer should cover them. The answer determines the staffing and budget you need after go-live.

A capable vendor should apply upstream security releases within the grace periods Decidim gives implementers, and show you a dated record of each one. Decidim supports only the last two minor versions with security updates until version 1.0, which means 0.32.x and 0.31.x at the time of writing, and 0.30.x and earlier are unsupported. Ask for a patch log listing each upstream release, the date it was applied to your environment, the test result and the person who approved it. Also ask which minor version you will run and what the plan is when that branch leaves support. Confirm the timing commitments in the written scope rather than relying on general statements.

Decidim gives implementers a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed. Your vendor should track each advisory from the point it is announced, record the deadline for your environment, and show when the patch was deployed. Ask for the vendor's internal escalation rule, for example who is alerted when a critical advisory arrives and how quickly a staging test starts. The evidence to request is the advisory tracker itself, with dates for notice, patch and production deployment. If the vendor cannot show that record for past advisories, treat its process as unproven.

Security reports about Decidim itself go to security@decidim.org or through GitHub Security Advisories, and your vendor should know both routes. Ask how it receives reports about your custom code, themes and integrations, and how those reports reach the Decidim upstream when the flaw is in the core. Request the written intake procedure, the triage owner, the target for acknowledging a report and the record kept for each case. Confirm whether the vendor will coordinate disclosure with the Decidim Association on your behalf or whether your organization must do so. Keep the report log as part of your security file.

The vendor should provide a written hardening baseline for the operating system, PostgreSQL, the Rails application server, the reverse proxy, file storage, background jobs, SMTP and any social login providers. Ask for the configuration keys and file names it changes from the defaults, the secrets handling method, and the access model for administrators and the database. Request a list of open ports, TLS settings and the logging scope. Manual installation guidance names PostgreSQL 17.4 or later on Ubuntu 24.04.3 LTS, so ask whether the baseline matches those versions or a later supported set. Ask for the baseline as a versioned document that is reviewed at each upgrade.

A backup schedule is not enough. Ask for a restore test record that names the backup tested, the environment it was restored into, the duration measured, the data checked after restore and the person who signed off. Decidim's update guidance requires a database backup before each upgrade, so ask how that backup is verified before any change. Request the retention period, the encryption method for backups, where copies are stored and who holds the keys. Ask how file uploads stored through ActiveStorage are included in the backup, because a database restore alone can leave attachments missing.

Independent testing should cover the live deployed site, not only the code repository or a staging copy. Ask for the test report scope, which should list the applications, APIs, hosts, custom themes, integrations and authentication flows tested, along with the methods used and the dates. Confirm who performed the test, whether the tester was independent of the team that built the site, and how findings were tracked to closure. DeployOpen runs security testing of applications and APIs and of cloud and infrastructure, so ask for a scope document that your own assessor can review. Test reports are inputs to your assessment; they are not an audit opinion or a certification.

A vendor cannot provide a guarantee that the platform is free of vulnerabilities, and no legitimate evidence set will say so. It also does not provide an audit report, attestation or certification, because those come from independent auditors or certification bodies. Be clear about what sits outside the vendor's control: the upstream code, the hosting provider's controls, your identity provider and your staff's access practices. Ask the vendor to list in writing the evidence it does not produce, so gaps are visible before contract signature. Your own compliance team should decide which items must be obtained from another source.

Put each evidence item into the written scope as a named deliverable with a format and a delivery point. In practice this means the patch log, the advisory tracker, the hardening baseline, the restore test record, the test report scope and the list of exclusions. Confirm how often each item is refreshed, whether during implementation, at go-live or as part of a support retainer. Ask who signs each record and where it is stored for your assessors. Because most engagements are fixed-scope and agreed in writing before work starts, these items should be specified before work begins rather than requested later.

Scope drives most of the cost: how many participatory spaces, components and custom themes you need, and how much of the work is configuration versus code. Integrations with identity, census or mailing systems add effort because each one needs its own design, testing and failure handling. Migration volume matters when you bring in proposals, comments or voter records from an older tool. The hosting model also moves the price, since a platform inside your own cloud account or data center involves your infrastructure team and your change process. Ask each partner to split the quote into discovery, build, integration, migration, hosting setup, testing and training, so you can see which line moves when your scope changes.

The work needs named people on your side before it starts. Expect a project owner who can sign off scope and priorities, a legal or data protection contact who can confirm the participation rules, and a communications lead who supplies copy, branding and accessibility review. Your identity or IT team must provide test accounts, DNS, SMTP and hosting access, and someone must approve the change process for production. Content is often the slowest input: draft process descriptions, FAQs and sample proposals need to exist before testing begins. Ask the partner to list these roles and decisions in the written scope so that delays can be traced to a named dependency.

Yes, if your team has the skills and the handover is planned for it. Running Decidim means operating a Ruby on Rails application with PostgreSQL, background jobs, file storage and mail delivery, so your operators need those skills or a retained support arrangement. The upgrade path matters: Decidim's update guidance asks for one minor version at a time, a database backup first and the release's own upgrade steps, so someone must own that routine. Ask the partner what runbooks, monitoring, backup tests and admin training are included, which parts remain with your team, and whether ongoing support, upgrades and testing will be offered as a retainer.

Compare the written scope before comparing totals. Two quotes are only comparable if they cover the same spaces, components, integrations, data migration, hosting responsibilities and acceptance tests. Check who holds the hosting account and the secrets, how security patches are applied within the grace periods Decidim describes for disclosed vulnerabilities, and what happens to the work if a requirement changes mid-project. Look for named deliverables, acceptance criteria and the support period after go-live. Ask each partner for the assumptions behind the price, such as the number of test cycles and the volume of legacy data, and request the same written assumptions from every bidder.

A fixed-scope agreement should name the deliverables, the environments, the components enabled, the integrations and their test endpoints, the migration sources and the acceptance criteria. It should also state what is excluded, such as custom components not yet designed or new participation processes added after kickoff. Ask for the change request procedure, the approval step for production, the training and documentation handed over, and the terms of any post-launch support. DeployOpen plans and delivers most engagements as fixed scope, with scope, deliverables and timelines agreed in writing before work starts, so ask other bidders to state their scope model in the same terms.

Custom components and integrations usually add the largest share of effort and the most ongoing maintenance. A custom theme must be tested for accessibility and rebuilt when the platform is upgraded, and every authorization handler, OmniAuth provider or external service adds a dependency that can break after an update. Mail, maps, geocoding and social login each need configuration in production, and any service that processes data outside your jurisdiction needs its own review. Ask the partner to list each customization with its owner, test plan and upgrade impact, and to state which custom code will be published to your repositories.

Ask for evidence rather than assurances. A credible partner should explain how it handles hosting access, secrets, backups, vulnerability patching and logging inside your environment, and which tests it runs before go-live. Decidim publishes its own security policy with a reporting address and grace periods for patches, so ask how the partner monitors those notices and applies fixes within your change windows. Security testing by an independent team, if included, should be defined as a separate deliverable with its own scope and report. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, so confirm with your assessor which records they will require.

Ask for timelines in phases tied to decisions you control, such as design sign-off, integration readiness, migration rehearsal and acceptance testing. The total effort depends on the same drivers as cost, so a shorter timeline usually means a narrower scope or more client staff time. Ask each partner what it needs from you in each phase and what happens if those inputs arrive late. No public figure for implementation time or fees applies to this platform, so request a written quote based on your scope and the assumptions behind it.