How GDPR for citizen participation platforms shapes the build
A public body that runs proposals, votes and assemblies on a platform is the controller under the GDPR (Regulation (EU) 2016/679, applicable since 25 May 2018), and the regulation does not certify software. No platform makes a participation process compliant on its own. The controller must map each processing activity to a lawful basis, decide how political opinions are handled as special category data, set retention for proposals and votes, and show how participant rights are honored. Those decisions then have to be translated into Decidim settings, user roles, mail and storage configuration, and written operating procedures. Where a host or vendor processes data for the body, the processor terms must cover the same ground and say who does what in a breach.
Enforcement sits with national supervisory authorities (Article 51), and the regulation sets administrative fines of up to EUR 10 million or 2% of worldwide annual turnover for infringements such as those of Articles 25 to 39, and up to EUR 20 million or 4% for breaches of the principles, lawful basis and data subject rights (Article 83, whichever is higher in each case). The text had not been amended as of October 2026, although the Omnibus IV and Digital Omnibus proposals are still moving through the EU legislative process. Confirm with your data protection officer which versions of the guidance and national rules apply to your body on the day you go live, and record that check in the file. Certification under Article 42 is voluntary and does not transfer responsibility, so ask any partner what evidence they will prepare for your assessments and what remains your own duty.
Which GDPR obligations map to which platform settings
This table maps each GDPR obligation relevant to a Decidim participation site to what the function must do and which settings or process decisions deliver it. Read the third column as the division of labor: some items are Decidim configuration, others are decisions your organization must make and document before launch.
| Obligation (GDPR article) | What the function must do | How Decidim and the process address it |
|---|---|---|
| Lawful basis and public task (Article 6) | Name the basis for each process, such as a public task set by law, and limit collection to what that task needs. | Process decision. Record the basis and the legal source per space, and add only the registration fields each process requires. |
| Political opinions as special category data (Article 9) | Recognize that votes, proposals and signatures can reveal political opinions and apply a stricter condition for handling them. | Process decision. Confirm the Article 9 condition with your data protection officer before collecting opinion-revealing data beyond what the process needs. |
| Data minimization and storage limitation (Article 5) | Collect only needed fields and keep personal data no longer than the purpose requires. | Configuration plus process. Limit registration and authorization fields, and set a documented retention rule for accounts, votes and verification data. |
| Pseudonymous participation (Articles 5 and 25) | Show participants under a display name while keeping identity data protected and separate from public content. | Configuration. Review public profile and nickname settings, and test that authors, comments and votes do not expose direct identifiers. |
| Participant rights of access, rectification and erasure (Articles 12 to 22) | Answer requests within the required time, export a person's data and erase or correct it where the law allows. | Partly configuration. Confirm how user data export and account deletion behave, and document how public contributions are handled when erased. |
| Processor contracts (Article 28) | Put a written agreement in place with every party that processes data for you, including the host and mail or map providers. | Process decision. Name each subprocessor, such as the hosting provider, SMTP relay and geocoding service, and record it in the contract. |
| Security of processing (Article 32) | Protect confidentiality, integrity and availability with measures suited to the risk. | Configuration plus operations. Set up encrypted transport, restricted admin access, tested backups and timely patching under Decidim's supported release lines. |
| Breach notification (Articles 33 and 34) | Detect incidents, assess them and notify the supervisory authority and, where risk is high, affected people within the set deadlines. | Process decision. Set logging and alerting, and agree who assesses and who notifies. Decidim's security reporting channel supports vulnerability intake. |
| Transfers outside the EU or EEA (Chapter V) | Identify where data goes, including social login, maps and email, and document the transfer mechanism for each destination. | Configuration plus contract. Review social login providers and external map or geocoding calls, and disable those that send data abroad without a basis. |
Why political opinions and pseudonymous votes change the design
A participation platform handles more sensitive data than its public task suggests. A proposal, a support signature or a vote on a participatory budget can reveal a person's political opinions, and the GDPR treats political opinions as special category data under Article 9. That changes the design. A lawful basis for the public task, such as Article 6(1)(e) for a council running a consultation, does not by itself cover every processing step. Sending a signature to a third-party map or geocoding service, storing login provider tokens, or exporting full vote histories for analytics each needs its own necessity check and, where the processing goes beyond the task, its own basis or an explicit condition. Before launch, the controller should map each Decidim component, such as proposals, votes, initiatives and surveys, to the data it creates, who can read it, and which external services it touches, then record the basis and the special category condition for each line.
Pseudonymous participation is a sound design choice because it reduces exposure. Public display names, hidden author fields on proposals and aggregated vote counts shrink what a casual visitor or a leaked export reveals. It does not take the data outside the GDPR, though. Under the regulation, data remains personal if the controller, or anyone with reasonable means, can link a pseudonym back to a person. Decidim still holds the account, verification records and authorization data behind every pseudonym, so the operator can re-identify participants. The practical questions for the controller are who holds the keys to that link, which roles can query it, whether the database backups and logs contain the same link, and whether the team can document that a re-identification would only happen under a defined procedure. Confirm these answers with the controller's data protection officer before the public description of the platform is written.
Self-hosted platforms that fit a GDPR-scoped participation build
Decidim is the platform this hub builds on, and its GDPR exposure comes from the stack around it: where the database, files, mail and maps run, and which login providers receive participant data. Each card below is a choice or check that changes who holds personal data and who must sign up to process it.
Decidim as the primary platform
Decidim is a free, open-source participatory democracy framework licensed under AGPL-3.0, built on Ruby on Rails and PostgreSQL, and used by more than 500 organizations according to its maintainers. Because the code runs in your infrastructure, the controller decides where participant records live. Confirm which Decidim version you will deploy and whether your team can apply security patches within the grace periods the project publishes.
Version support and patch windows
Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x. Versions 0.30.x and earlier receive no security fixes, so running them leaves personal data exposed to known flaws. Ask your implementer how they will track the project's security advisories and apply patches inside the grace periods, and confirm who is accountable for patching under your controller obligations.
Self-hosted database and file storage
Decidim keeps proposals, votes, comments and authorization records in PostgreSQL, and uploaded attachments in file storage configured through ActiveStorage. Both must sit in infrastructure you control, inside the jurisdiction and location you have documented. Confirm encryption at rest, backup locations, and that backups follow the same retention rules as the live data. Take a database backup before every upgrade, as the update guide requires.
SMTP and notification mail
Production Decidim sends account confirmations, notifications and password resets through an SMTP service configured in the platform. If that relay is a third-party mail provider, it processes participant email addresses and message content, so it becomes a processor that needs a data processing agreement. Confirm the sending domain, the provider's data location, and how bounce and suppression records are kept.
Maps and geocoding services
Assemblies, meetings and proposals often use maps and geocoding to place a location. Many hosted map and geocoding services receive the address or coordinates a participant enters, which can reveal where someone lives or works. Where a map or geocoder is external, record it as a processor or recipient, check where requests are processed, and consider whether a self-hosted tile and geocoding service meets your needs.
Default social login providers
Decidim ships with Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login, configurable globally or per organization. Facebook, Twitter and Google receive data from participants who use them, so each login reveals participation to a foreign or US-based controller. Before launch, either run a transfer and processor review for each provider or disable it, and document the decision. Any other OmniAuth strategy you add needs the same review.
Evidence a supervisory authority or auditor will ask for
This table maps the records a supervisory authority or auditor is likely to ask for against the component that produces each one. Read it as a checklist for the build: if a row has no owner, the evidence will be hard to produce on request. The GDPR itself issues no audit report or certificate, so the file is assembled by the controller from its own records and its host's contracts.
| Evidence | What it shows | Component that produces it |
|---|---|---|
| Record of processing activities | Each purpose, data category, recipient, retention period and transfer for the platform (Article 30) | Organization's data protection policy and processing register, updated when spaces or components change |
| Lawful basis and special category assessment | Why public-task processing applies, and the extra condition relied on for political opinions in proposals and votes | Legal memo or DPO assessment kept with the processing register |
| Data protection impact assessment | Risk analysis for large-scale processing of political opinions and identifiers, with mitigations (Article 35) | DPIA document, reviewed before launch and after material changes such as new login providers |
| Retention schedule and deletion logs | Agreed retention for accounts, proposals, comments and votes, and proof that data was removed on schedule | Organization's retention policy, Decidim admin actions, database backup retention settings and host deletion records |
| Processor agreements with host and subprocessors | Terms covering instructions, security, subprocessors, breach support and return or deletion of data (Article 28) | Contracts with the hosting provider, DeployOpen if engaged, and any maps, geocoding, SMTP or social login providers |
| Rights request log | Access, rectification, erasure and objection requests received, the response dates and actions taken | Organization's request register, with Decidim admin and account tooling used to carry out actions |
| Breach response records | Detection, assessment, internal decisions and any notification to the supervisory authority (Articles 33 and 34) | Incident log maintained by the organization, supported by server, application and mail logs from the host |
| Access control and backup test records | Who holds admin and database access, and evidence that backups restore on test (Article 32) | Decidim admin role lists, host access reviews, PostgreSQL backup job logs and restore test notes |
| Transfer documentation | Where data is stored and which third-country transfers exist, with the safeguard relied on (Chapter V) | Host contract and data location statement, plus provider terms for any service that sends data abroad |
How a GDPR-ready participation build is sequenced
The sequence fixes the processing decisions first, then configures the platform to match them, so that the legal basis, pseudonymity, retention and processor terms are settled and tested before any citizen data enters the system.
Scope the processing for each process type
List every participatory process the organization will run, such as budgets, consultations, petitions and assemblies, and record for each one what personal data is collected, from whom, for what purpose, and who in the organization is the controller. Include login data, verification data, proposals, comments, votes, signatures and any optional profile fields. The output is a processing register entry per process type, reviewed by the data protection officer or legal team. The step is done when every data field on the platform maps to a named purpose and an owner.
Decide lawful basis and special category handling
With legal counsel, establish the lawful basis for each process, which for public bodies often rests on the performance of a task carried out in the public interest, and confirm whether any content could reveal political opinions, which the GDPR treats as special category data. Decide whether participants may post such content, how moderation handles it, and what explicit consent or other condition applies where it is processed. Record the decisions in writing. The step is done when each process has a documented basis and a stated rule for special category content.
Configure authorization and pseudonymous participation
Set the authentication and authorization model so that only the data needed for each process is requested, and decide where pseudonymous participation is allowed, such as public display names that do not reveal the verified identity. Keep verification records separate from public-facing profile data and limit staff access to them. Ask the implementation partner to show which Decidim authorization handlers and social login providers are enabled, and which fields they store. The step is done when a test account shows public pages reveal no verification data and the access roles match the written decisions.
Set retention, anonymization and deletion rules
Define how long proposals, comments, votes, signatures and account data are kept after each process closes, and what happens to them at the end of that period, including whether votes are anonymized before archiving. Build these rules into scheduled jobs or manual procedures and document who runs them. Confirm with the controller how backups and logs are purged on the same schedule. The step is done when a test process can be closed, anonymized and deleted according to the written schedule, with evidence of each run.
Sign processor terms with the host and third parties
Execute a data processing agreement with the organization or partner that hosts the platform, and with every third-party service the build depends on, such as email delivery, maps and geocoding, social login providers, storage and monitoring. For each service, record what personal data it receives, where it is processed, and any transfer mechanism. Ask each provider for its own processing terms and sub-processor list. The step is done when a register lists every processor, its data flows and a signed agreement on file.
Test rights requests and breach runbooks
Run rehearsals of the participant rights the GDPR grants, including access, rectification, erasure, restriction and objection, and confirm the platform can locate and act on a participant's data across proposals, votes and comments. Run a tabletop exercise of a personal data breach to test the notification steps the controller must take within the timelines set by Articles 33 and 34. Assign named owners for each role. The step is done when each rehearsal produces a written record of time taken, gaps found and fixes assigned.
Go live with a documented review cycle
Launch the first process only after the earlier decisions are signed off, and publish the privacy notice that matches the configured data flows. Schedule a recurring review of the processing register, retention schedule, processor list and access roles, and add a check after each Decidim upgrade, since upgrades can change data structures. Keep the evidence in one controlled location for internal audit or supervisory authority requests. The step is done when the review calendar, owners and evidence store are approved by the organization.
What tooling alone does not satisfy
Decidim gives you the settings, components and update path, but it cannot decide what the law requires for your organization. The cards below name the gaps that remain after the software is installed and who must close each one before participants arrive.
Lawful basis and necessity
The platform does not choose the legal basis for each process. Your organization, usually its legal or data protection function, must document the public task or other basis for every consultation, budget vote and petition, and confirm that collecting each field is necessary for that purpose. Political opinions are special category data, so the necessity test applies with extra weight to free-text proposals and profile fields. Check every form field against the documented purpose before launch.
Retention periods for proposals and votes
Decidim's settings do not decide how long proposals, comments, votes or account data are kept, or when they are anonymized. The data protection officer or records owner must set a retention schedule per space type, decide what remains public after a process closes, and configure a deletion or anonymization routine that the platform team runs and records. Ask the implementation partner to show how that routine is tested on a restored backup.
Transfers through social login and maps
Facebook, Twitter and Google login, and external maps or geocoding services, can send participant data outside the EU when they are enabled. The platform owner must list every external provider, confirm where each one processes data, and document any transfer mechanism before enabling it. Disable providers that cannot meet the requirement, and keep the list current when settings change.
Owned patch and upgrade process
Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x. Implementers have a 2-month window for standard vulnerabilities and a 4-month window for critical ones before details are disclosed. The operator must own a monitoring process, a staging test, a database backup and a one-minor-version-at-a-time upgrade plan, with a named person accountable for each step.
Cross-border enforcement procedures
Regulation (EU) 2025/2518 sets additional procedural rules for complaints and investigations in cross-border GDPR cases and applies from 2 April 2027. Your legal team should map how complaint handling and supervisory authority requests would reach your team, and who answers them within the timelines in your own procedures. The regulation does not change the controller's duties, but it changes how cases move between authorities.
Pending Omnibus proposals
The GDPR text has not been amended as of October 2026, but the Omnibus IV proposal (2025/0130(COD)) has a text agreed in negotiations and awaits Parliament's first-reading vote, and the Digital Omnibus proposal (2025/0360(COD)) awaits committee decision. Assign a legal owner to track both procedures and review your retention, consent and processor records when either text is adopted. Confirm the current status with counsel rather than relying on earlier summaries.
Questions buyers ask before they hire help with GDPR for participation platforms
How much does GDPR work add to a participation platform project, and what drives it?
GDPR work is a set of separate costs, not one fee. Your organization pays its own legal and data protection officer time, a partner or consultant may be paid for mapping processing, drafting records and configuring the platform, and hosting providers and other vendors may have their own contract terms. The main drivers are the number of processes that touch personal data, how many third-party services send data (login providers, maps, geocoding, email), how much legacy data must be reviewed, and how much legal review the lawful basis needs. Ask any partner for a quote built from a written scope that lists each process, each external service and each deliverable, and check which items are one-time and which recur, such as annual reviews and retention purges.
How long does GDPR preparation take for a Decidim site?
No fixed duration can be stated without the scope, so ask for a timeline tied to written deliverables. The timing depends on how many participation processes, assemblies and initiatives you run, how many external services you connect, whether historical data must be cleaned or migrated, and how quickly your legal, data protection and IT teams can approve decisions. Lawful basis and retention decisions usually wait on internal sign-off, so plan that review into the schedule rather than treating it as a final step.
What do our legal, data protection officer and IT teams need to provide?
Each team owns a different part of the work. Legal should confirm the lawful basis for each public task, the treatment of political opinions as special category data and the wording of notices. The data protection officer should review the records of processing, retention periods, participant rights procedures and any data processing agreement with the host. IT should provide the hosting architecture, access controls, backup and logging arrangements, and the list of external services. Agree who signs each decision before work starts, because unresolved decisions are the most common cause of delay.
Can our team handle GDPR for a Decidim platform without a partner?
Yes, a capable internal team can do much of this work, provided it has the time and the legal input. The GDPR does not require an audit, attestation or certificate, so the work is about documented decisions and working controls. Internal teams often struggle with configuring the platform's data flows, keeping evidence current through upgrades and testing the controls. A partner can take on the platform configuration, integration review and documentation while your teams keep the legal decisions. Whichever route you choose, the controller remains responsible for compliance.
Is Decidim GDPR certified?
No. Certification under Article 42 of the GDPR is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and applies to processing operations, not to software as such. Certification also does not reduce the responsibility of the controller or processor. Decidim is free, open-source software licensed under the AGPL-3.0, so the question for your organization is whether your own deployment and processing meet the GDPR, which you can document and, if you choose, have assessed by an independent party.
Does the Decidim upgrade and patch cadence change the compliance work?
Yes. Each release can change database structures, so the update guide asks you to move one minor version at a time and to back up the database first. Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x, and 0.30.x and earlier are not supported. Security reports go to security@decidim.org or GitHub Security Advisories, and implementers have a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed. Your security and retention documentation should record the version in production, the patch dates and the upgrade tests, and your processes should cover how quickly a patch is applied.
What should we check in a partner's proposal for GDPR scope?
Look for a written scope that names each deliverable, such as a record of processing, a data flow map, a lawful basis analysis for each process, a retention schedule, participant rights procedures, a review of external services and a checklist for the data processing agreement with your host. Ask which items are outside scope, including the legal opinion itself, which must come from your counsel. Also ask how changes to the law are handled. As of October 2026 the GDPR text has not been amended, while the Omnibus IV and Digital Omnibus proposals are still in the legislative process, so confirm with your legal team how pending changes would be reviewed.
What DeployOpen prepares and what stays with the controller
DeployOpen plans, configures, hardens, documents and supports the self-hosted Decidim platform inside your own cloud account, data center or network, and prepares the systems, controls and evidence that a compliance assessment will ask for. That includes the hosting baseline, PostgreSQL and file storage settings, SMTP and background job configuration, access controls for administrators and moderators, logging, backup and restore records, and the processing records that feed your Article 30 register. DeployOpen does not issue audit reports, attestations or certifications, and certification under Article 42 is issued by accredited bodies, not by an implementer. The decisions about why you process participant data, which lawful basis applies to each process, whether a poll asks for political opinions, how long proposals and votes are kept, and how data subject requests are answered remain with the controller. Those calls belong to your legal and data protection team, and they should be recorded in writing before configuration begins.
Engagements run as fixed-scope work. Before any build or hardening starts, the written scope should name the Decidim version, the components and spaces in use, the hosting location, the login providers, the retention rules your team has approved, and the evidence to be delivered, such as configuration records and test results. Ask any partner to state which items are excluded, including legal review, data protection impact assessments and the authoring of privacy notices. Ongoing support, upgrades and continuous security testing are available as retainers, which suits a platform that must keep pace with supported Decidim releases. Confirm with the vendor which versions receive security updates at the time you sign, because the maintainers' support window applies to your installation for as long as you run it.
How DeployOpen scopes, delivers and supports GDPR-ready participation platforms
DeployOpen plans, implements, hardens, documents and supports self-hosted Decidim platforms inside your own cloud accounts, data centers or air-gapped networks. For GDPR, that means turning your lawful basis, special category data decisions, retention rules and processor terms into configured settings, documented evidence and a handover your team can run. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.
How we scope
- The written scope lists which participatory spaces, components and login methods are in and out of the build.
- Scope records the lawful basis and the data categories each process collects, including political opinions.
- Retention periods for proposals, votes and account data are agreed in writing before configuration starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Configure pseudonymous participation, display names and profile fields so only necessary personal data is stored.
- Review third-party login, maps, geocoding and SMTP providers for where they send participant data.
- Test data subject access, rectification and erasure workflows against the agreed retention and deletion rules.
- Apply hardening, backup and access controls aligned with Article 32 security of processing expectations.
How we hand over
- Documentation covers the processing record, data flows, retention settings and the list of sub-processors used.
- Your team receives runbooks for account deletion, export requests, backups and breach response steps.
- Evidence packs list configured controls and test results so your assessor or auditor can review them.
- Handover includes a checklist of the processor terms and data processing agreement items to confirm with your host.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- Security patches follow Decidim's supported release lines, so the platform stays on a supported version.
- Each Decidim minor version upgrade is planned with a database backup and the release's upgrade instructions.
- Support reviews retention settings and new components before they handle more personal or political data.
