Open source project management for the public sector

Auditors usually ask for a current list of who can reach project data, the role or group each person holds, and proof that access was reviewed and changed through an approved process. In OpenProject, the evidence comes from the user and role configuration, group membership, and, where LDAP group synchronization or single sign-on is used, the identity provider's group records that feed it. Enterprise features such as SAML, OIDC and LDAP group synchronization are listed on OpenProject's pricing page, so confirm which edition your agency needs before you design the evidence trail. Access reviews should be dated, signed by a named owner and kept alongside the export of role assignments. DeployOpen prepares these exports and the review procedure, but an independent auditor decides whether the controls are adequate. DeployOpen does not issue audit reports, attestations or certifications.

Oversight teams expect a record of who changed administrative settings, roles, project permissions, integrations and authentication configuration, with timestamps and the account that made each change. The primary source is the application's own administration log, complemented by the reverse proxy or web server access log and the operating system or container logs that show who logged in to the host. Logs should be forwarded to a store the project team cannot edit, so that the evidence survives an administrator's own actions. Confirm with your implementation partner exactly which events OpenProject records and how long they are retained, because retention settings are configured per deployment. For federal and health-adjacent scope, the HIPAA Security Rule's audit control requirement at 45 CFR 164.312(b) is a useful reference for what a reviewer will expect logs to show, even where HIPAA does not apply to the agency.

Reviewers typically want to see that traffic between users, the application and its database is encrypted in transit, that stored data and backups are encrypted at rest where required, and that cryptographic modules meet the standard the agency must follow. The evidence is a documented configuration: TLS versions and cipher settings from the ingress or reverse proxy, database connection settings, certificate inventory with expiry dates, key management records and backup encryption settings. For CJIS-scope data, the CJIS Security Policy v6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, so any project data touching criminal justice information needs this check. Confirm module validation status with the vendor and your platform team rather than assuming it. DeployOpen can prepare the configuration records and test results; the assessor issues the conclusion.

Agencies need dated accessibility test results that map to WCAG 2.1 Level A and AA success criteria, covering the pages and workflows staff use, plus a remediation log for every defect found. Under the ADA Title II rule, state and local government web content and mobile apps, including those provided through contracts or licenses, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200). A usable package usually includes automated scan output, manual testing with assistive technology, and an accessibility statement that names the known gaps. Custom branding and theme changes can alter contrast and focus behavior, so retest after every change. DeployOpen can run testing and prepare the evidence; conformance judgments and any public statement remain the agency's responsibility.

Reviewers typically ask for scan reports covering the application, its container images or packages, the operating system and the database, with dates, the scanner version, the findings, and the status of each finding. The CJIS Security Policy v6.1 calls for vulnerability scanning at least monthly under control RA-5, which is a common reference point for agencies that handle sensitive data. Keep the scanner output, the triage decision for each high-severity item, and the patch date that closed it. Security updates for the software should be tracked in the same record, for example by linking each scan to the release notes of the installed version. Confirm the scan schedule and tooling with your security team, because the platform does not produce this evidence on its own. DeployOpen performs security testing and can deliver scan and test records as part of an engagement, but scan coverage is set by the agency's written scope.

Reviewers want evidence that backups run on schedule, that they are stored away from the primary system, and that restores have actually been tested with a documented result. The record should show the backup job logs, the retention period, the restore test date, the scope restored (database, attachments and configuration), the time taken and any gaps found. For a Docker-based OpenProject deployment, the database and file attachments are the two elements to capture, and the PostgreSQL version must meet the platform's requirement of PostgreSQL 16 or later. Restore tests should run in a separate environment and be signed off by the service owner. Confirm the recovery targets the agency needs with its business owners before you write the procedure. DeployOpen can plan, implement and document backup and restore as part of an engagement and prepare the test evidence.

A change record should show what was upgraded, from which version to which version, why, who approved it, when it ran, how it was tested, and how it could be rolled back. For OpenProject, the reference point is the release notes for each version, such as 17.9.0 released on September 30, 2026 and 17.9.2 released on October 15, 2026. Keep the pre-upgrade backup, the test result in a staging environment, the post-upgrade checks and the approval record together. If the platform sits inside openDesk, the upgrade rules also matter: openDesk supports only the latest minor version, and in-place upgrades between majors are not guaranteed, so intermediate steps may be needed. Agencies should confirm these rules in writing before scheduling a change. DeployOpen can document and execute upgrades under a fixed-scope agreement, and ongoing upgrades are available as a retainer.

An independent auditor, assessor or certification body issues the audit report, attestation or certification, and the agency's own governance function decides what it accepts. DeployOpen prepares systems, controls and evidence for these assessments, including access exports, configuration records, test results, backup logs and change records, organized so an assessor can trace each one to a control. DeployOpen does not issue audit reports, attestations or certifications, and it does not decide whether a control is effective. Ask the assessor early which evidence formats and sampling approach they expect, and agree the evidence list in the written scope so that collection is planned rather than rushed before the review.

The cost is driven by scope, not by the software license alone. The community edition of OpenProject is free, while Enterprise on-premises is priced per named user per month: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users (OpenProject pricing). Beyond licenses, the main cost components are the number of integrations (identity, file storage, reporting), the hosting build, data migration from existing tools, accessibility testing, and the documentation and training you require. Ask any partner for a fixed-scope quote with each component listed separately, and confirm which items recur each year, such as support, upgrades and licenses.

The duration depends on the hosting target, the number of integrations and how many approval gates your agency runs. A standalone installation is simpler than one that must join an existing openDesk stack, a single sign-on setup and a migration from legacy tools at the same time. Packaged installs support Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15, and Docker is the recommended method (OpenProject system requirements), so the operating system and approval of the target platform are early decisions. DeployOpen agrees timelines in writing as part of the fixed scope, so ask for a plan with milestones tied to your security review and change board dates.

Most of the delay in public sector projects comes from inputs the agency must supply. Expect to provide a named sponsor, a security approval path, the target hosting environment with access for the implementation team, identity provider details for single sign-on, and a list of projects, templates and roles to be migrated. You also need a decision on who owns the data, who approves configuration changes and who signs off acceptance. If you run openDesk, confirm the Kubernetes cluster version, ingress controller and external services such as PostgreSQL and SMTP are ready, because the deployment depends on them. Agree this list in the written scope so that delays are visible early.

Yes, many agencies run OpenProject internally once it is installed, but the workload is ongoing. Your team will handle upgrades, backups, database maintenance, monitoring and user administration. OpenProject publishes sizing guidance for different user counts, and the database must meet current requirements, including PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions (OpenProject system requirements). Ask whether your staff has Linux, container and database skills, and whether an on-call rota exists. Many agencies choose a retainer for upgrades and continuous support, which is available from DeployOpen, while keeping day-to-day administration in-house.

Accessibility work is needed when the tool is part of your public-facing or regulated web content, and it is wise to check it in every case. The ADA Title II rule requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200). Confirm with your legal counsel which systems fall within that rule. Ask any partner how they test keyboard navigation, screen reader behavior, color contrast and custom branding, and whether the work is included in the written scope.

These frameworks change who is in scope and what evidence you need, which affects the effort. FedRAMP covers cloud products that process federal information on behalf of an agency, while systems used only for a single agency's operations on cloud infrastructure, not offered as a shared service, are out of scope (FedRAMP Consolidated Rules for 2026). Systems that handle criminal justice information fall under the FBI CJIS Security Policy, where version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for data in transit and at rest outside physically secure locations. Confirm your classification with your compliance office first. DeployOpen prepares systems, controls and evidence for assessments but does not issue authorizations or certifications.

A fixed-scope engagement covers only what is written in the agreed scope, deliverables and timelines. For project management, that typically means planning and installing the platform in your environment, configuring projects, roles and workflows, connecting single sign-on or directory sync, linking to file storage such as Nextcloud, hardening, backup setup, documentation and handover. Items such as large data migrations, custom development, extended training or ongoing testing may be separate. Ask each partner to list included and excluded items in writing before work starts, and to explain how change requests are priced and approved.