Why a student participation platform is a records problem, not only a voting problem
A student union, vice-provost or governance office that wants student budgets and consultations online is usually solving a voting problem first, but the moment verification relies on enrolment records or campus single sign-on, the platform starts handling education records. That shifts the question from how to run a ballot to whether the build fits the university's FERPA duties. Under 34 CFR Part 99, any institution receiving funds from a program administered by the US Secretary of Education must control who sees personally identifiable student information, keep a log of disclosures, and answer access requests within 45 days. A vendor or implementation partner that touches those records can only act as a school official if it performs a service the university would otherwise do with employees and stays under the university's direct control.
The short answer for most campuses is a self-hosted Decidim instance inside the university's own infrastructure, connected to campus SSO through OmniAuth, with a separate participatory space for each faculty and a moderation workflow that staff can audit. Decidim's processes, assemblies and budgets components can each be scoped to a faculty, and access should follow the legitimate educational interest of the people who administer them, which the institution must enforce with technological access controls. Before you commit, confirm with your legal and records office which student data fields the authorization step will store, who can export them, and how long they are kept. Confirm also whether your identity provider can release only the attributes the verification needs, since that choice determines how much of the student record ends up inside the participation database.
Two other obligations change the build as well. Where the platform collects information for a funded program or handles student financial data, the GLBA Safeguards Rule in 16 CFR Part 314 requires a written information security program and multi-factor authentication for anyone accessing an information system, and Title IV institutions are examined on it. Where Decidim's social login or map providers send data outside your environment, that transfer must be documented before launch. Ask your implementation partner to map each of these duties to a named setting, role or hosting decision in the written scope, so the records question is answered before the first student signs in.
Which education rules set the requirements for student participation
This table maps the US education and consumer privacy rules most likely to reach a student participation platform to what each one asks for in SSO, roles, logs and retention. Read each row as a question to confirm with counsel and the registrar: which rule applies depends on whether the university takes federal funds, holds Title IV aid agreements, and whether any participant could be under 13. The main takeaway is that FERPA access control and recordkeeping duties shape the platform build for almost every university.
| Rule | What it asks for | What it means for SSO, roles, logs and retention |
|---|---|---|
| FERPA school official exception (34 CFR 99.31) | A contractor may see education records only if it performs a service staff would otherwise do, stays under the university's direct control, and follows redisclosure limits. | Treat the DeployOpen or hosting partner as a school official under a written contract. Limit admin roles to that service, and confirm the university controls use and maintenance of any records. |
| FERPA access controls (34 CFR 99.31(a)(1)(ii)) | Staff access only the records tied to their legitimate educational interest, enforced by reasonable technical or physical controls. | Map SSO groups to faculty and office roles. Scope moderators and faculty admins to their own spaces, and review role grants each term. |
| FERPA disclosure record (34 CFR 99.32) | A record of each request and disclosure of personally identifiable information, kept as long as the records are kept. | Log access to participant records and exports with the actor, time and reason. Keep these logs on the same retention schedule as the records they describe. |
| FERPA inspection timing (34 CFR 99.10(b)) | Respond to a student's request to inspect education records within a reasonable period and no more than 45 days after receiving it. | Tag which participation records are education records. Confirm the platform can locate a student's submissions, votes and comments quickly enough to meet the 45-day limit. |
| GLBA Safeguards Rule (16 CFR Part 314), for Title IV institutions | A written information security program, multi-factor authentication for anyone accessing any information system, and FTC notice within 30 days of a qualifying event affecting 500 or more consumers. | Require MFA for all admin and moderator logins, not only for students. Add the platform to the written security program, the risk register and the incident response plan with a 30-day notice path. |
| GLBA annual compliance audit (FSA GENERAL-23-09) | The Department of Education examines GLBA compliance through annual compliance audits for Title IV participants. | Keep evidence of MFA settings, access reviews and change records for the platform. Ask the university which evidence its auditors request for connected systems. |
| COPPA (16 CFR Part 312), only if under-13 participants are possible | Operators collecting personal information from children under 13 need a written security program, annual risk assessments and a written retention policy with a deletion timeframe. | Usually not triggered on a university campus. If a campus program admits younger students, block sign-up below the age limit and confirm the operator duties with counsel before launch. |
What student data the platform touches and where it must stay
The first decision is to map every data flow before the platform holds a single record. On a Decidim build for a university, the flows usually include enrolment or census extracts used to check eligibility for a student budget or a faculty-only consultation, attributes returned by campus single sign-on, proposals, votes and comments, moderation reports, and accounts for student union officers and faculty staff who administer spaces. Each flow needs an owner, a stated purpose and a retention rule. Census extracts in particular often hold more fields than eligibility needs, so the reader should ask the registrar's office to limit the extract to the attributes the verification step actually uses.
Under FERPA, a contractor such as an implementation partner may receive education records only as a school official. The contractor must perform a service the institution would otherwise use employees for, operate under the institution's direct control for the use and maintenance of those records, and follow the redisclosure limits in 34 CFR 99.33(a). In practice, this affects who hosts the platform, who holds administrator rights, and whether the institution can see and log every access. The reader should confirm, with counsel, that the hosting arrangement, administrator roles and access logs can be shown to be under institutional control, and that access is limited to the faculties and staff with a legitimate educational interest, as 34 CFR Part 99 requires.
Some third-party services can send data abroad. Social login providers that are not the campus identity provider, and map or geocoding services used on proposal or meeting pages, are the usual cases. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box, and custom OmniAuth strategies can be added, so the reader should disable any provider the university has not approved and list every external service in the data map. For each one, confirm where the data is processed, what it receives, and whether a data processing agreement and transfer documentation exist before launch. Students under 18 and institutions that also serve as Title IV participants may bring additional rules, which should be confirmed with the compliance office.
Which platform fits which governance model
A single student budget on one campus is the simplest case. Students propose projects, the community discusses them, and eligible members vote on how a fixed pot is spent. Decidim's participatory budgets component handles this flow, and a single participatory space with one budget usually covers it. Verification is the main design task, because the vote must be limited to enrolled students without storing more student data than the rule needs.
- Component fit: A participatory process with a participatory budgets component and a proposals component covers submission, discussion and voting.
- Scope of the space: One space with one budget keeps configuration, moderation and results reporting simple for a small team.
- Verification: Campus SSO can be connected through OmniAuth, so the vote depends on the student's institutional login rather than a manual census.
- Outcome publishing: Results and the status of funded projects can be published from the same space through the accountability tracking features.
- Course context: A Moodle or Open edX course is only needed when the budget is part of graded coursework, such as a student project that teaches budgeting. Confirm the scoring and records requirements with the academic team before adding it.
Before launch, confirm with the registrar which identity attributes the SSO provider can release and whether the university accepts the vote as a governance decision.
Multi-faculty governance needs several participatory spaces, each with its own members, moderators and rules. A faculty council may run its own budget, while the university senate runs a consultation that all faculties can see. Decidim's processes and assemblies components can model these separate spaces, and each space can carry its own components and permissions. The design question is which spaces are open to all students and which are restricted to one faculty.
- Separate spaces: Each faculty can have its own process or assembly, with moderators limited to that space.
- Shared consultations: A university-wide consultation can run as one process, with faculty-level comments and proposals kept visible in context.
- Eligibility by faculty: Restricting a space to one faculty depends on identity attributes from SSO, so confirm which faculty attribute the university identity provider can supply.
- Assemblies for structured deliberation: Assemblies suit councils and working groups that meet, decide and record positions over a defined term.
- Course context: Where faculty deliberation is taught as part of a curriculum, a Moodle or Open edX course can host the teaching material, with Decidim kept for the governance decision itself.
Ask the university to map each governance body to a space before configuration, so permissions and moderator roles are settled first.
A university-wide assembly may include students, staff, alumni, local residents and partner organizations. Its participants do not share one identity source, which changes both verification and moderation. Decidim's assemblies component supports members, meetings and structured positions, but external participants usually need a different login route from campus SSO. The assembly must also define who may vote and who may only comment.
- Mixed membership: Assembly members can be recorded with different roles, so students, staff and external members do not share identical rights.
- Login routes: Campus SSO covers students and staff, while external members may need a separate OmniAuth strategy or an invitation flow. Confirm both routes with the implementer.
- Meetings and records: The meetings component can document sessions, and the assembly record should show how decisions were reached.
- Accessibility of meetings: Assemblies often involve in-person sessions, so accessibility of venues and online streams sits outside Decidim and needs its own plan.
- Course context: A Moodle or Open edX course is rarely the right home for an open assembly, but it can prepare members through briefing material.
Confirm with the university legal office whether an assembly decision is advisory or binding, because that answer sets the verification and record-keeping standard.
Which open-source platforms fit student governance and why
A student governance build usually combines a participation platform with a learning system and a public site, each doing a different job. Decidim carries the consultations, budgets and assemblies, while the other platforms handle training and information. The connections between them, and the licence and support windows that govern each one, decide how much work the university takes on.
Decidim for participation spaces
Decidim provides the participatory spaces a student body needs: processes for consultations, assemblies for deliberation, and components such as proposals, surveys, meetings and participatory budgets. Its AGPL-3.0 licence applies to modified versions you run for users, so confirm the obligations with the university's counsel before customizing the code. Plan upgrades around the support window: only the 0.32.x and 0.31.x branches receive security updates, and each upgrade should move one minor version at a time.
Separate spaces per faculty
Each faculty, student union or committee can run its own participatory space inside one Decidim organization, with its own components, moderators and budgets. This keeps votes and proposals scoped to the right community while the university keeps one set of administrators and one security baseline. Confirm with IT how roles are granted to faculty staff, since broad administrator access is the most common source of accidental publishing.
Moodle for student representative training
Where student representatives or moderators need certified training before they run a process, Moodle can host the course, quizzes and completion records. Moodle is licensed under GPL-3.0, and its 5.3.0 release is designated the next long-term support release, with security fixes until October 1, 2029. Ask IT whether the training records need the same access controls as governance data, because they hold personal information about students.
Drupal or WordPress for the public site
A public information site explains how to take part, publishes calendars and links into the Decidim hub. Drupal suits a multi-site estate with formal accessibility and editorial workflows, while WordPress suits smaller teams with a simpler publishing model. Either way, the site should not hold votes, signatures or verification data. Keep the site separate so an editorial change cannot affect the participation platform, and link to it from the hub rather than embedding it.
Why participation is not a general CMS
A content management system publishes pages, while a participation platform manages a process with phases, identities, votes and results that must be recorded and retained. Decidim's processes and budgets model those steps directly, so the university does not have to rebuild voting logic on a CMS. The two systems connect through links, shared branding and single sign-on, but they should have separate databases, administrators and backup schedules.
Confirm licences and support windows
Licence obligations and support windows change the build. Confirm with the university's counsel how AGPL-3.0 applies to any custom modules and what must be published when the code is modified. Confirm with IT which Decidim branch, Moodle release and CMS version are in support on the planned go-live date, and who applies security patches within the disclosure window. These are decisions for the university, and they should be recorded in writing before the fixed scope is agreed.
How a university rollout moves from pilot to ongoing governance
The sequence moves a student governance platform from a documented legal and records baseline to a tested pilot with one student budget, then to a supported go-live. Each phase closes with a written output so the university can approve the next step before more work begins.
Assess requirements and education records with legal and the registrar
The university's legal counsel and registrar define what the platform will hold, including whether any participant data counts as education records under FERPA, and which student groups, roles and votes need to be recorded. DeployOpen maps the data flows, the school official arrangement for any outside party that will administer the platform, and the access rules that limit staff to the records they have a legitimate educational interest in. The phase closes with a signed requirements register and a data inventory that the university approves in writing.
Deploy hosting and SSO in a test environment
The team installs Decidim in a non-production environment inside the university's own cloud account, data center or network, then connects it to campus single sign-on through OmniAuth so that students authenticate with their university credentials. The team also configures PostgreSQL, background jobs, file storage, email and backups as the installation documentation describes. The phase is complete when test students can sign in, the university's identity team has reviewed the attribute mapping, and a restore from backup has been tested.
Design spaces and roles for each faculty
Working with student union staff and faculty administrators, the team sets up one participatory space per faculty or student body, with separate processes, budgets and assemblies where the rules differ. It defines administrator, moderator and participant roles so that each faculty team can manage its own space without seeing other faculties' private data. The output is an approved space and role matrix, with a record of who can publish, moderate and export content in each space.
Set moderation and outcome publishing rules
The university agrees the moderation policy, including who reviews reported content, response times the governance body accepts, and the grounds for hiding or removing proposals. It also agrees how voting results, budget decisions and the response to each proposal will be published and archived. The team configures these rules, writes the participant guidance, and runs a tabletop review with moderators. The phase closes when the policy is approved and every moderation action is logged in the platform.
Test accessibility against WCAG 2.1 Level AA
The team tests the sign-in flow, proposal and voting forms, budget pages and any custom theme against WCAG 2.1 Level AA, using both automated checks and manual testing with assistive technology. Findings are logged with severity, owner and fix date, and retested after fixes. Public-facing university sites may also fall under the ADA Title II web rule, so the university should confirm which of its entities are in scope and when the compliance date applies. The phase closes with an accessibility test report and a list of accepted residual issues approved by the university.
Run a pilot with one student budget
The university runs a limited pilot with a single student budget, with real participants, a fixed set of proposals and a defined voting period. The team monitors sign-in success, moderation load, email delivery and support requests, and records any defects against the requirements register. Results are reviewed with the student union, the registrar and the legal team against the approved requirements. The pilot is complete when the governance body signs off on the results and on any changes required before go-live.
Go live and hand over to ongoing support
The team moves the approved configuration to production, completes a final backup and restore test, and publishes the participation guidance and privacy notice. It hands over runbooks for upgrades, which must move one minor version at a time with a database backup first, and for security patches, plus the access review schedule and the record of disclosures. Ongoing support, upgrades and testing can run under a separate retainer that the university agrees in writing. The phase closes with a signed go-live acceptance and an operations handover.
Evidence a university auditor or regulator will ask for
This table maps the records a university auditor, FERPA reviewer or Title IV compliance examiner is likely to request to the Decidim component or institutional system that produces them. Read it as a preparation checklist: DeployOpen prepares systems, controls and evidence for assessment, but independent auditors and certification bodies issue any audit report or attestation.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Written information security program | Scope, owner, risk assessments and controls for student data on the platform | Institution policy plus DeployOpen hardening and test documentation for the Decidim deployment |
| MFA configuration evidence | Multi-factor authentication enforced for staff and administrators, as the GLBA Safeguards Rule requires | Campus SSO identity provider settings exported and reviewed alongside Decidim login configuration |
| Access logs for school official accounts | Who viewed or changed student-linked records, and whether access matched a legitimate educational interest | Decidim and PostgreSQL logs, forwarded to the institution's central log store |
| Record of disclosures | Each request for and disclosure of personally identifiable information, with parties and interests, kept as long as records are kept | Institution disclosure register, populated from access requests and export logs |
| Retention schedule and deletion records | Retention periods for verification data, votes and proposals, and proof of deletion when due | Institution retention policy plus scheduled deletion jobs and their run records |
| Backup and restore tests | Recent verified database backups and a tested restore before any upgrade | Backup tooling for PostgreSQL and ActiveStorage files, with restore test logs |
| Patching and upgrade records | Dates and versions applied, showing supported Decidim minor versions and timely security patches | Change tickets, upgrade logs per minor version and the Decidim release record |
| Accessibility conformance records | Testing against WCAG 2.1 Level AA for public spaces, forms and voting pages, with remediation tracking | Accessibility audit reports, custom theme test results and the published accessibility statement |
What do universities ask before running student voting on Decidim?
What does a university pay for when running student voting on Decidim?
Costs fall into two groups: one-time work and recurring work. One-time work covers scoping, installation, configuring the campus single sign-on, building faculty spaces, migrating any existing data, testing and training staff. Recurring work covers hosting, backups, security patching, Decidim minor-version upgrades, monitoring and support during voting periods. Hosting and staff time are paid by the university directly, while an implementation partner is paid under a written fixed scope. The main cost drivers are the number of faculty spaces, the number of identity sources, whether the university hosts in its own data center or cloud account, and how many processes run each year. Ask any quote to separate these lines and state which items are included after go-live. DeployOpen does not publish a price list, so the written scope sets the figure.
How long does it take to launch a student participation platform?
Time to launch depends on how much is custom and how quickly the university can make decisions. The biggest variables are the campus single sign-on integration, the number of separate faculty spaces, the moderation and publishing rules, and the accessibility review of any custom theme. Hosting approvals and security reviews by the university's IT and information security teams often take longer than the build itself. Decidim's installation guide lists the production components that need configuring, including background jobs, file storage, SMTP, maps and login providers, so each one adds work to the schedule. No duration is set here because none is supplied for this use case. Ask for a timeline in the written scope that lists the approval gates and the date by which the university must supply access.
What must the university's IT and legal teams provide before the build starts?
The university must supply decisions and access before work can be planned. IT needs a hosting location, network access, database and file storage choices, SMTP details, and a test identity provider with the attributes the platform will read. Legal and data protection staff need to confirm the purpose of each process, the retention period for student data, and whether any data leaves the institution. The records office should confirm which parts of the process touch education records under FERPA, since an outside contractor may act as a school official only under the conditions in 34 CFR 99.31(a)(1)(i)(B). The university also needs to name an owner for moderation and outcome publishing. Confirm each item with your own counsel and information security team.
Can a university run a Decidim student platform without outside help?
A university team can run it without outside help if it has staff with Ruby on Rails, PostgreSQL and Linux operations skills, a tested backup routine, and capacity to read each release's upgrade instructions. Decidim is free and open source under AGPL-3.0, so the software cost is zero, but the work of installing, configuring, securing and operating it is not. Outside help is most useful for the first build, the identity integration, the security review and the first upgrade cycle. Many universities use a mix: internal staff own content and moderation while a partner covers infrastructure and patching under a written scope. Decide which tasks are kept in-house before asking for a quote, so the scope matches the team you actually have.
How can a university verify students without storing extra personal data?
The safest pattern is to check eligibility at login and keep only the result. Decidim supports login through OAuth 2.0 and any other OmniAuth strategy, so a campus single sign-on can supply a student identifier and a faculty attribute at sign-in. The platform can then assign the student to the right faculty space without copying the full student record. Configure the attributes you request to the minimum needed, and confirm with the registrar which fields are education records. Avoid uploading full enrolment lists unless the rules require it, and if they do, define a deletion date. Under the GLBA Safeguards Rule, multi-factor authentication is required for anyone accessing an information system, so the identity provider should enforce it. Check the detailed design with your data protection officer.
How are Decidim security updates and upgrades handled?
Updates follow a fixed routine: track releases, apply security patches within the grace period, and upgrade in sequence. Decidim supports only the last two minor versions with security updates before version 1.0, currently 0.32.x and 0.31.x, so older branches receive no fixes. Implementers get 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed. Upgrades must go one minor version at a time, for example 0.30 before 0.31, following each release's instructions, and the database must be backed up first because some releases change database structures. Ask the partner for the patching process, a test environment and the owner who approves each upgrade in the written scope. Check the current support status on the Decidim releases page before each planning cycle.
Questions to put to an implementation partner before signing
Start with the compliance questions, because a partner that cannot answer them in writing will not be able to prepare the evidence a university needs. Ask for examples of written FERPA and GLBA work, and ask who wrote it and whether it covered a Decidim deployment. Ask how the partner documents each school official designation under 34 CFR 99.31(a)(1)(i)(B): the named roles, the services performed, the institution's direct control over the records, and the redisclosure limits. Ask how role-based access to faculty spaces is configured and recorded, since the institution must use reasonable access controls under 34 CFR 99.31(a)(1)(ii). Ask also who keeps the access and disclosure log that 34 CFR 99.32 requires, and how long it is retained.
Next, pin down hosting and administrator rights. Ask in which cloud account or data center the instance will run, who holds root, database and Rails console access on day one, and how those rights are removed at handover. Ask how SSO is integrated: which identity provider and OmniAuth strategy will be used, how student identifiers are mapped to Decidim authorizations, and whether any social login provider will send data outside the institution. For moderation, ask how many named moderators the partner expects to staff in the first term and whether the partner will moderate at all or only train campus staff. Ask for the accessibility testing method and whether the results will be shared before launch.
Finally, settle the commitments that will outlast the launch. Ask which Decidim minor versions the partner will patch, how it will apply the security patch windows that Decidim's security policy describes, and how it will take each minor-version upgrade in sequence with a database backup first. Ask how student personal data is deleted at the end of a student budget vote, which tables and file attachments are included, and who signs off that deletion. Last, ask for the fixed scope in writing, with a named list of deliverables, acceptance criteria and a defined handover of documentation, credentials and runbooks. Any scope that leaves these items open is a cost risk for the institution.
How DeployOpen scopes and supports student participation platforms
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the university's own infrastructure. For student participation on Decidim, that means agreeing a written scope for each faculty space, identity integration, moderation and outcome publishing before any build work starts.
How we scope
- Written scope lists which faculties, student bodies and governance spaces the Decidim platform will host at launch.
- Scope records how campus SSO verification maps to Decidim authorization so only eligible students can vote or sign.
- Scope defines which data the platform keeps, where it is hosted, and the retention rules agreed with the university's data office.
How we build
- Build covers separate Decidim spaces per faculty, with participatory budgets, proposals and moderation roles configured to the agreed rules.
- Integration work connects campus identity providers through OmniAuth, with testing of login, role assignment and access controls.
- Hardening, backups and a documented upgrade path are built in, with every Decidim minor version applied one step at a time.
How we hand over
- Handover includes configuration records, runbooks for moderators and administrators, and the access-control and audit logging evidence the university requested.
- Staff training covers publishing outcomes, handling moderation decisions and recording the requests for disclosure the university must keep.
- Acceptance testing against the written scope closes the project, and the open items are listed by name and owner.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous security testing are available as a retainer.
- Retainers cover security patches within the grace periods Decidim publishes, and version upgrades after each release is tested.
- Support requests, incident response and periodic review of the platform's compliance evidence are defined in the retainer scope.
