Decidim security hardening guide

Why Decidim security hardening starts with a supported version

Hardening a Decidim deployment starts with running a release line that still receives security fixes. Until version 1.0, the Decidim project supports only the last two minor versions with security updates, which at the time of writing means 0.32.x and 0.31.x. Anything at 0.30.x or earlier is outside that window, so no hardening work on it can close the gap that matters most. After the supported line is confirmed, the remaining layers are the Rails application, the web and application server, file storage, administrator access, background jobs, the database, and the process for responding to advisories. Decidim is harder to harden than a typical Rails application because it is a large, multi-component product. It ships its own administration interface, its own authorization and identity verification flows, and social login surfaces for Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 that can be configured globally or per organization. It also depends on ActiveJob for background work and ActiveStorage for uploaded files, so each of those needs its own configuration and monitoring. Generic Rails hardening guidance covers the framework, but it will not tell you which Decidim surface a given setting affects.

Ownership is divided, and the division should be written down before work begins. The client's cloud account, data center or network team owns the operating system, network boundaries, backups storage, certificates and access to the hosts. The Decidim codebase is maintained upstream, and any custom modules or theme changes are owned by whoever wrote them, which is often the implementation partner during the build and the client's own team afterwards. Settings for admin accounts, authorization handlers, social providers and job queues sit in the application configuration, so someone must hold the change record for them. Ask your partner to name the owner of each layer in the scope document.

The upgrade path is part of the hardening work, not a separate project. The Decidim update guidance asks operators to move one minor version at a time, following each release's upgrade instructions and taking a database backup first, because some releases change database structures. A deployment that skips a line cannot be brought back into the supported window in one step. Plan to confirm which Ruby and Node versions each supported line requires, since the Ruby requirement differs between 0.32 and 0.31, and to check that your PostgreSQL version meets the manual installation guide.

This page covers the hardening controls and the decisions behind them. It does not repeat the step-by-step upgrade procedure, which is covered in the upgrades and support section, or the configuration of single sign-on and identity verification, which is covered in the SSO section. Read those alongside this page when you plan the work, and treat the advisory response process described later as an input to your patch calendar, since the project gives implementers a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed.

Which Decidim and Rails components carry the attack surface

A Decidim deployment is a Rails application sitting on PostgreSQL, with background workers, file storage, outbound mail, login providers and organization-specific code around it. Each of these exposes a different path into the platform, so hardening starts by listing them and confirming which setting or extension point governs each one in your installation.

Rails application and environment configuration

The Rails application reads its secrets, host settings, logging and error handling from environment configuration, and in production these choices determine what an outside visitor can see when something fails. Confirm that secret keys are supplied from your secret store rather than the repository, that debug output is disabled in production, and that the allowed hosts list matches your public domain. Review these settings against the Decidim installation guide for the version you run.

PostgreSQL database access

Decidim stores participant accounts, proposals, votes and audit-relevant records in PostgreSQL, so the database is the most valuable target in the stack. Restrict network access to the application and worker hosts only, use a dedicated role with the privileges the application needs, and confirm that the database version you run is supported by your Decidim release. Take a backup before any migration, as the update guide requires.

ActiveJob background workers

Notifications, exports, imports and other slow tasks run through ActiveJob, and the worker processes often run with different credentials and network reach than the web tier. Check which queue backend is configured, that worker hosts are not reachable from the public internet, and that job failures are logged without exposing personal data. Confirm the queue adapter and worker setup against the production configuration in the Decidim installation documentation.

ActiveStorage upload handling

Participants can attach files to proposals, comments and other content, and ActiveStorage decides where those files are kept and how they are served. Confirm the storage service, whether files are served through the application or directly from object storage, and which content types and sizes are accepted. Uploaded files are a common route for malicious content, so review the storage configuration and the file handling rules before opening participation to the public.

SMTP and outbound mail settings

Decidim sends account confirmations, password resets and notifications through the SMTP settings you define, and misconfigured mail can expose tokens or let the platform be used to send spam. Confirm that SMTP credentials are stored outside the code base, that transport encryption is enabled as your mail provider supports it, and that sender domains have the email authentication records your organization requires. Test password reset and confirmation flows after any change.

Admin interface and organization-specific themes

The admin interface controls spaces, components, moderation and user roles, while custom modules and themes add code that the upstream project does not review for your organization. Restrict admin access to named staff accounts with multi-factor authentication through your identity provider where possible, remove unused admin roles, and track every custom module and theme as part of your upgrade inventory so that patches to the core framework do not silently break local code.

Decisions to make before changing any configuration

This table compares the five or six choices that shape a Decidim hardening project and the operational cost of each option. Read it before touching configuration, because several choices decide how much patching, monitoring and access control you will carry for the life of the platform. The main takeaway is that the install method, upload storage and admin path set your exposure more than any single setting does.

Decision	Option	Trade-off	When to choose it
Install method	Manual Rails application	Full control over Ruby, Node, PostgreSQL and server packages, but your team owns every dependency upgrade and OS patch	Your platform team already runs Rails services and needs to align Decidim with existing hardening baselines
Install method	Docker	Repeatable images and simpler rebuilds, but you must track image rebuilds for each security release and verify what the image contains	Your team operates containers well and wants reproducible environments across staging and production
Upload storage	Local disk on the application host	Simple to set up and back up with the host, but uploads sit on the web tier and complicate scaling and restores	A single-host deployment with a small, well-understood volume of uploaded documents
Upload storage	Object storage through ActiveStorage	Separates files from the web tier and supports access controls and backups at the storage layer, but adds credentials, bucket policies and a second system to monitor	Multi-node production or when retention and access rules for participant uploads must be enforced outside the application
Admin interface path	Public network path	Lowest setup effort, but the administration login is reachable from any network that can reach the public site, which widens the attack surface	Rarely appropriate for production; only where other compensating controls are documented and reviewed
Admin interface path	Restricted network path (VPN, allowlist or separate host)	Reduces exposure of administrative functions, but adds access requests, network changes and support work for staff who work remotely	Organizations that manage processes and moderation from known offices or networks and can run a VPN or reverse proxy
Social login scope	Enabled globally	Simple for all organizations, but every provider adds an external identity trust relationship and a configuration to maintain for each one	A single organization or a platform where all participating bodies agree to the same providers
Social login scope	Enabled per organization	Limits each provider to the organizations that need it, but requires per-organization configuration and clear rules for account linking	Multi-organization instances where some bodies must not accept third-party accounts
Custom modules	Reviewed and pinned to a commit or version	Predictable behavior and a clear upgrade trigger, but each pin needs review whenever Decidim moves to a new minor version	Any custom component or integration that will be kept beyond the next upgrade cycle
Custom modules	Installed from a floating branch	Quick to adopt new fixes, but changes can land without review and break builds or introduce unreviewed code into production	Only in throwaway test environments, never in production
Security reports and patching	Named owner and a fixed review cadence	Requires a designated contact for security@decidim.org and GitHub Security Advisories, plus scheduled time for patch testing	Any organization that must meet its own patch deadlines within Decidim's grace periods for disclosed advisories
Security reports and patching	Ad hoc patching when staff have time	Lower planning effort now, but risks missing the two-month and four-month grace periods that Decidim gives implementers	Rarely suitable; confirm the owner and cadence before go-live

How to harden a Decidim deployment step by step

This sequence moves a Decidim instance from a default install to a documented baseline that stays within the supported release line. Each step ends with a check you can repeat later, so the team can show what was changed and what was verified.

Confirm the running version is supported
Identify the exact Decidim version in production and confirm it is on the 0.32.x or 0.31.x branch, since only the last two minor versions receive security updates before version 1.0. Compare your running release with the latest patch on that branch, such as v0.32.1 or v0.31.7, and note any gap. Ask the team that operates the instance to confirm the deployed tag, not only the version in the code repository. The step is done when the running version, its branch and the latest available patch are written down and match the support policy.
Match Ruby and Node to the release
Check the runtime against the release requirements: Ruby 3.4.7 with Node 22.14.x for 0.32, and Ruby 3.3.4 with Node 22.14.x for 0.31. Confirm the versions reported on the application host match these values, including the Ruby and Node binaries that the process manager actually loads. Remove unused runtimes from the path so a different interpreter cannot run the application by accident. The check is a short script run on the host that prints the Ruby and Node versions and the Decidim version, with the output saved next to the baseline.
Run the application as a non-root user
Create a dedicated system account for the Rails application, own the application directory with that account, and start the web and worker processes under it. Set the production environment variables, and supply secrets such as the Rails secret key base, database passwords and OAuth client secrets from the host environment or a secrets manager, never from files committed to the repository. The check is to confirm the process owner with a process listing, confirm no secret appears in the repository history or deployed configuration files, and confirm the application starts in production mode.
Limit PostgreSQL to application hosts
Run the database on PostgreSQL 17.4 or later, as the manual installation guide specifies, and restrict network access so only the application and worker hosts can connect. Use a database role that owns only the Decidim schema, and avoid superuser access for the application. Any change that touches database structure, including the schema changes made during an upgrade, follows the update guide for that release and starts with a verified database backup. The check is to test a connection from an unapproved host and confirm it is refused, and to confirm a restore from the latest backup succeeds in a separate environment.
Lock down ActiveStorage uploads
Configure ActiveStorage so uploaded files, such as proposal attachments and documents, are stored in a location that is not browsable and is not listed publicly. Confirm the storage service credentials are scoped to the bucket or directory Decidim uses and nothing broader. Review how file URLs are generated and whether they expire, and decide with your security team how sensitive uploads are served. The check is to upload a test file, then try to reach its direct URL and any directory listing from an unauthenticated session, and confirm access is denied or expires as designed.
Restrict admin access and trim social providers
Limit the administration interface to trusted networks or an authenticated access gateway, and confirm with your team how the chosen version exposes admin routes. Review the social login configuration, which supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 out of the box, and disable every provider the organization does not use, both globally and per organization. Confirm that admin accounts use strong authentication and that the number of administrators is limited to the people who need it. The check is to request an admin route from an untrusted network and confirm it is refused, and to list the enabled providers and match them to an approved list.
Isolate ActiveJob workers and outbound mail
Run ActiveJob workers as a separate process with the minimum credentials they need, separate from the web process where your setup allows. Configure SMTP and other outbound connections with a dedicated sending account that can only send mail, and restrict the hosts the workers can reach to the mail relay, the database and the storage service. Confirm that mail sending uses encrypted transport and that sender domains are authenticated according to your mail provider's guidance. The check is to trigger a test job and a test notification, confirm both complete, and confirm the worker cannot reach hosts outside the approved list.
Record the hardening baseline
Write down the final configuration in one place: the Decidim version and branch, runtime versions, process owners, database and network settings, storage access rules, admin access controls, enabled social providers, worker and mail settings, and the date of the last backup restore test. Store the record with the infrastructure documentation and reference it in your change process, so every later update starts from known values. Subscribe the team to the Decidim security channels, security@decidim.org or GitHub Security Advisories, so disclosed advisories are reviewed within the patch grace periods. The step is done when a second engineer can rebuild the configuration from the record alone.

Access control, secrets and data protection in Decidim

Most Decidim exposure comes from who can reach the admin area, where credentials live, and who can open uploaded files and personal records. The cards below are controls you can check on a running instance, each with a clear owner and a clear test. Identity provider setup is covered in the SSO and identity verification topic.

Separate admin and participant accounts

Keep staff administrator accounts separate from ordinary participant accounts, so no one who debates proposals also holds rights to change configuration. Require strong authentication for every administrator, such as a second factor enforced at the login layer. To check this, list admin users, confirm each has a named owner, and confirm that a participant account cannot reach the admin routes.

Scope admin roles to organizations and spaces

Decidim can run several organizations and many participatory spaces on one installation, so role assignments need to stop at the boundary they were meant for. Review which roles can reach each organization, process, assembly and component, and remove grants that were made for a single event. Test by signing in as a space-level admin and attempting to open a space owned by another team.

Keep secrets out of code and repositories

The Rails secret key base, database credentials, SMTP passwords and OAuth client secrets should be injected at runtime from a secrets store, not committed to the repository or written into configuration files shipped with the application. Confirm that the repository and container images contain no credentials, that rotation has an owner, and that a rotated secret does not require editing source code. Decide how old secrets are revoked when staff change.

Restrict access to uploads and personal data

Uploaded documents, attachments and exported participant data are often more sensitive than the public pages around them. Confirm that ActiveStorage files are served through the expected access rules rather than through predictable public URLs, and that the storage bucket or directory is not publicly listable. Review who can download exports, and test with a logged-out browser and an unrelated participant account.

Minimize personal data in logs

Application, web server and background job logs can capture email addresses, IP addresses, names in request parameters or document titles. Decide which fields must be filtered, configure Rails parameter filtering, and set a retention period for logs held by the hosting team. Verify by triggering a password reset and a proposal submission, then searching the logs for the test email address.

Review custom modules and OmniAuth strategies

Custom Decidim modules, theme code and third-party OmniAuth strategies run inside the same process as the core platform and have the same access to data and secrets. Put them through the same code review, dependency checks and patch tracking as the core application, and record who owns each one. Before adding a strategy, confirm its maintenance status and how it validates tokens returned by the provider.

How to test that the hardened Decidim deployment resists misuse

The first test is an inventory, because a hardened deployment running an unsupported release has already lost ground. Record the Decidim version in use, the Ruby and Node versions, the PostgreSQL version, the operating system and the locked Rails version from the lockfile. Compare each one against the supported lines. Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x, so 0.30.x and earlier fail this check. For 0.32, confirm the runtime is Ruby 3.4.7 and Node 22.14.x. For 0.31, confirm Ruby 3.3.4 and Node 22.14.x. Run a dependency advisory scan against the lockfile and the container image, and keep a dated record of the result so the next review can show what changed.

Next, review configuration as it runs in production. Inspect the environment settings for debug output, verbose logging of request parameters, host authorization and forced HTTPS. Confirm that the secret key base and database credentials come from a secrets store and not from files in the repository. From outside the network, request the public site and read the response headers. Look for a content security policy, HSTS, frame restrictions, a content type setting and a referrer policy, and check whether the server banner discloses more than it needs to. Repeat the header check on any staging hostname, since staging environments often carry looser settings and are still reachable by someone who finds them.

The access tests should be written as attacks, each with an expected denial. For uploads, try to reach stored files by guessing or incrementing identifiers, and by requesting blob URLs after they should have expired or after the owning component was made private. Files attached to unpublished or restricted content must return nothing to an anonymous client. For admin routes, send requests from outside the approved network path, including requests with altered Host headers, and confirm that the load balancer, ingress or web application firewall refuses them before Rails handles the request. Then test role boundaries. Sign in as an account for each administrator role your installation defines and attempt actions reserved to other roles, such as editing another space, managing users or changing global settings. Check that each denial is written to the audit trail.

A restore test shows whether the backup you rely on can rebuild the platform. Restore the latest database backup into an isolated environment built from the same release, run the application against it, and confirm that participants can sign in, that processes and proposals display, and that attachments resolve to the file storage they reference. Compare record counts for key tables against the source at backup time. For background jobs, confirm that the worker runs under its own service account, that the queue backend listens only on internal addresses, and that any job dashboard is either disabled or protected by the same admin controls as the application. Document which components can enqueue jobs from the web tier, and confirm that no public request path can do so.

Failure should look like a refusal, and errors must reveal nothing about the system. Send malformed input, oversized requests, unexpected content types and deliberately broken parameters to forms and API endpoints. A safe deployment returns a generic error page with a correlation reference, while the full trace and any sensitive values stay in server-side logs with restricted access. Search responses and logs for stack trace frames, file system paths, the database connection string and the secret key base. Treat any match as a finding, fix the configuration, and retest. Independent application and infrastructure security testing can run these checks as a scoped engagement. DeployOpen offers it as an option, with targets, credentials and rules of engagement agreed in writing before testing begins.

How hardening differs for single-node, high-availability and air-gapped Decidim

On a single-node installation, the web application, PostgreSQL database, ActiveJob workers and file storage share one host. A compromise of any one component can reach the others, so the blast radius is the whole platform. Hardening here focuses on isolating what can be isolated on one machine and on keeping the host itself patched and tightly managed.

Hardening priorities

Restrict PostgreSQL to local socket or loopback access and use a dedicated database role with only the privileges the application needs.
Run the Rails application and background workers under separate, non-root service accounts with restricted file permissions on the application and upload directories.
Keep uploads in a storage location with its own access controls, and confirm that the web server does not serve files directly from application code paths.
Schedule regular database backups to a separate location, and test restoration on a non-production host.

Extra checks this model requires

Confirm that firewall rules expose only the public web ports and the administrative access path.
Verify that a worker failure or runaway job cannot exhaust memory or disk needed by the database.
Review the host's operating system update process, since kernel and package patches also affect the Decidim stack.

Confirm with the platform team: who patches the host, where backups are stored and who holds the keys to them, and whether the hosting provider's controls cover the shared machine.

What drives the effort of hardening a Decidim deployment

This table lists the main factors that change how much work a Decidim security hardening project takes, with a way to keep each one under control. Use it to see which decisions in your scope move the quote most, and to ask a partner how each driver is priced.

Driver	Why it changes effort	How to keep it down
Organizations and participatory spaces on one instance	Each organization adds its own branding, roles, moderation settings, authorization rules and access paths to review and test.	Confirm the number of organizations at scoping and split hosting only where separation is required by policy or law.
Custom modules	Custom code sits outside the upstream release path, so each module needs its own review, dependency checks and patch handling when Decidim or Rails changes.	Keep one reviewed module set, document each module's purpose, and remove modules that are no longer used.
Enabled social providers and authorization handlers	Each OAuth or OmniAuth provider and each verification handler adds callback URLs, secrets, data flows and trust decisions to assess.	Enable only the providers and handlers the participation process needs, and configure them per organization rather than globally.
Size and sensitivity of uploaded files	Uploads stored through ActiveStorage need access control, malware and type checks, backup scope, and retention rules, and sensitive attachments raise the review level.	Limit accepted file types and sizes, define retention for attachments, and confirm which storage backend and encryption settings apply.
Environments that must match production	Staging, test and recovery environments need the same Rails, server and database settings to make test results meaningful, so each one is a separate build to verify.	Use reusable environment templates generated from the same configuration, and check drift against production before each release.
Hosting model and air-gapped operation	Air-gapped networks cannot pull packages, maps or geocoding services directly, so dependencies, updates and advisories must be moved in by a controlled process.	Decide hosting and network model early, and plan an offline update path with a fixed owner for each advisory and patch.
Compliance evidence requirements	Assessors expect documented controls, configuration baselines, change records and test results, and each framework adds its own evidence set.	Agree the evidence list in writing before work starts, and generate configuration and test records as part of the normal build.

What to monitor, back up and document after hardening

Most of a Decidim deployment's security risk arrives after go-live, so the first recurring task is making sure someone hears about problems early. Subscribe the operations team to the reporting channel at security@decidim.org and to GitHub Security Advisories for the decidim/decidim repository. Decidim's security policy gives implementers a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed. Those windows only help if your team knows an advisory exists on the day it is published. Confirm with your partner or internal owner who receives each notification, who triages it, and how the deadline is recorded against each environment.

Track the two supported minor lines, which are currently 0.32.x and 0.31.x. Versions 0.30.x and earlier no longer receive security updates, so any instance on those lines carries known exposure that patching alone will not close. Decidim publishes patch releases on each branch, such as v0.31.7 on the 0.31 branch, and the team should check the release notes for every patch rather than assuming a minor upgrade is the only route to a fix. Keep the Ruby, Node and PostgreSQL versions for each environment in view as well, because the application's runtime requirements change between minor lines and those components have their own patch schedules that you should confirm with the vendors.

Monitor the application and background worker logs for errors, failed jobs and unusual request patterns, and set alerts on the events your team has agreed to act on. Failed administrator sign-ins deserve their own alert and review, because admin accounts can change component settings, authorization rules, social login providers and file handling. Decide who reviews these events, how quickly, and how long logs are kept, and check the retention period against your records obligations. Also confirm where the worker queue is observed, since background jobs handle email and other work that can fail quietly if nobody watches the queue.

Verify backups on a schedule rather than trusting that the backup job reports success. Two stores need protection: the PostgreSQL database and the uploaded files held through ActiveStorage. A verification run restores both into a separate environment and checks that a sample of participant accounts, proposals, documents and attachments open and match production. Record the date, the backup used, the person who ran the check and the result. The update documentation also asks for a database backup before every upgrade, so a tested backup routine is part of your upgrade readiness, not only a disaster recovery control.

Keep a hardening register that records the configuration of each environment, the Decidim minor line and patch level, runtime versions, custom modules, accepted exceptions and review dates. Every exception should have an owner, a reason and a date when it will be reviewed again. The register is also the starting point for upgrade planning: it shows which minor line you are on, which modules may break and which settings need checking after each release. Ask your partner what the register will contain, who maintains it, and whether keeping it current is included in a support retainer or handled by your own team.

Questions teams ask before hardening Decidim

What does Decidim security hardening cost and what drives it?

Cost depends on the written scope, and DeployOpen does not publish a price list. The main drivers are the number of environments (production, staging, test), the number of custom modules and integrations to review, the hosting model (cloud account, data center or air-gapped network), how far your current version is from a supported branch, and whether you want a one-time baseline or ongoing patching.

One-time: the baseline review, configuration changes and documentation. Recurring: patching, upgrades and advisory response, which can run under a retainer.

Ask any provider for a quote that separates these items and states who performs each task, your team or theirs.

How long does Decidim security hardening take to complete?

Duration depends on scope and environments, so no single timeline fits every deployment. One production instance on a supported version with no custom modules is a different job from several environments, a fork carrying custom code, or an instance several minor versions behind, which must be upgraded one minor version at a time. Access approvals, change windows and the time your team needs to review findings also affect the schedule.

Decidim's grace periods of 2 months for standard vulnerabilities and 4 months for critical ones are deadlines for applying patches to disclosed issues. They do not measure how long hardening takes. Ask for a timeline built from a written scope, with dependencies listed.

Can our internal team harden Decidim without an implementation partner?

Yes, if your team has working skills in Ruby on Rails, PostgreSQL, Linux server administration, deployment tooling and security configuration. Start by checking your current version against the two supported minor branches, 0.32.x and 0.31.x. Then confirm that your team can follow each release's upgrade instructions, back up the database before every upgrade, and monitor security advisories.

Many organizations split the work. Internal staff keep ownership of accounts, data and approvals, while a partner handles configuration review or testing. Confirm your team's capacity before you commit, because patch deadlines follow the vendor's schedule, not your calendar.

What do we need to provide for a Decidim hardening engagement?

Expect to provide the following:

Access to the cloud accounts, hosting environment or data center systems where Decidim runs, through a method your security team approves.
A named administrator owner who can make decisions and approve changes.
A test environment close enough to production to validate configuration and upgrades.
The custom module list, including forks, patches and integrations with identity providers, mail, maps or storage.
Current backups, database details, infrastructure diagrams and the SMTP, ActiveStorage and ActiveJob setup.

Missing items usually extend the schedule, so agree the list in the written scope before work starts.

Is Decidim hardening a one-time task or ongoing work?

Both. The initial hardening is one-time work: reviewing the deployment, setting configuration for the Rails application, web server, file upload storage, admin access, background jobs and database, and documenting the result. Recurring work follows because Decidim publishes new minor versions, the supported branches move, advisories require patches, and Ruby and Node requirements change between releases.

Plan a recurring budget line for patching, upgrades and monitoring, whether that work is internal or handled through a retainer. Ask each provider which tasks sit in the quote and which move to a support agreement.

What happens when Decidim publishes a new security advisory?

Your first step is to check whether your version is on a supported branch, since Decidim supports only 0.32.x and 0.31.x until version 1.0, and 0.30.x and earlier receive no security updates. Decidim accepts security reports at security@decidim.org or through GitHub Security Advisories, and implementers have 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed.

After that check, assess your exposure, schedule the patch within the window, test it in staging, deploy it, and record the evidence. If your version is older, the fix may require a multi-step upgrade first, which takes more time than the patch itself.

Does DeployOpen issue security certifications for Decidim?

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and decide whether controls meet a given framework. DeployOpen prepares the system, the configuration evidence, the documented controls and the change records that an assessor reviews.

Before starting, confirm with your assessor which framework and scope apply, because the same Decidim instance may need different evidence for different frameworks. Ask the assessor for the list of evidence they expect, then agree it with DeployOpen in the written scope.

How DeployOpen scopes, hardens and hands over a Decidim deployment

DeployOpen plans, implements, hardens, documents and supports Decidim inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm the Decidim version and the supported release line before any hardening work begins.
Inventory hosting, Rails and server configuration, file storage, admin accounts and background job setup.
Record the written scope, deliverables and exclusions so the quote follows directly from agreed work.

How we build

Apply hardening to the Rails application, web server, PostgreSQL database and background job workers in the client's environment.
Configure ActiveStorage uploads, admin access controls and SMTP settings according to the agreed design.
Run security testing against the deployed instance and record findings with remediation status.

How we hand over

Deliver configuration documentation, an upgrade runbook and a record of how disclosed advisories will be applied.
Walk the client's team through admin access, backup and restore procedures and the patch process.
Provide evidence of controls for the client's own compliance assessor, noting that DeployOpen does not issue audit reports.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
Plan each upgrade one minor version at a time, backing up the database before every step.
Confirm with the client which patch timelines and escalation contacts their own policy requires.

Decidim security hardening