Open source intranet for the public sector: why hosting and accessibility decide the platform
For a ministry, agency or municipality, the platform decision starts with two questions: where employee communications are stored and administered, and whether the intranet can meet accessibility duties from day one. A self-hosted intranet on HumHub, XWiki or Nextcloud can satisfy both when it runs in government infrastructure, under the body's own administrators, and is tested against WCAG 2.1 Level A and AA. The public sector also differs because the intranet rarely stands alone. It must sit beside the official directory, the records and document systems, and in some bodies a full workplace suite such as openDesk. Those integrations shape the choice as much as the feature list does. The accessibility clock is the most concrete deadline. 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). Procurement teams should ask each candidate for its current conformance statement and its roadmap for the remaining gaps, then check those claims in a pilot with real screen reader and keyboard users. Hosting scope is set by NIS2 for EU bodies: it covers central government entities regardless of size, lists public administration as a sector of high criticality, lets Member States extend it to local administration, and excludes national security, defense and law enforcement. Confirm with counsel which regime applies to your body. FedRAMP, CJIS and CMMC matter only when the intranet creates, stores or processes federal, criminal justice or controlled unclassified information. An internal news and policy intranet often does not, but a space that holds case files or CJI does. Ask your compliance lead and legal counsel to classify the content before the platform is chosen, and state in the requirements whether cloud hosting is permitted at all. Applicability depends on your mandate, your data and your jurisdiction, so treat this as a starting point, not a legal conclusion.
Which public sector requirements shape an intranet build
This table maps each public sector requirement to what it means for hosting, directory integration, content classification and audit logging in an intranet build. Read each row as a question to settle with your legal, security and records teams before choosing a platform. The main takeaway is that accessibility, sector scope and data classification decide more of the build than the choice of software.
| Requirement | What it asks for | Build impact | Evidence to prepare |
|---|---|---|---|
| ADA Title II web accessibility | State and local government web content and mobile apps must meet WCAG 2.1 Level A and AA, including content provided through contracts or licenses. Compliance dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts (28 CFR 35.200). | Theme, templates and vendor plugins must be tested for keyboard use, contrast and screen reader support. Confirm which intranet content and third-party embeds fall under your contracts. | Accessibility test results per template, a remediation log and a list of contracted components in scope. |
| NIS2 for central and possibly local government | Central government entities are covered regardless of size, and public administration is a high-criticality sector. Member States may extend coverage to local administration. Defense, security and law enforcement entities are excluded. | Hosting, access control and incident handling for the intranet must follow the national transposition in your Member State. Confirm whether your intranet supports regulated services. | Written scope decision from legal counsel, asset inventory and incident response procedures covering the intranet. |
| CJIS Security Policy v6.1 (where criminal justice information appears) | Version 6.1 took effect on 26 June 2026. It requires FIPS 140-3 validated modules or AES with 256-bit keys for CJI in transit and at rest outside physically secure locations, and vulnerability scanning at least monthly. | Keep criminal justice information out of general spaces and file areas. Confirm that TLS and storage encryption use validated modules and that scanning covers the intranet hosts. | Data flow diagrams, encryption configuration records, monthly scan reports and access restriction documentation. |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 for CUI | Federal agencies must use NIST SP 800-171 when setting requirements for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards. Confirm this applies through your contracts or agency terms. | Classify intranet content by CUI category, restrict distribution lists and external sharing, and host where the required controls can be implemented. Confirm agency-specific requirements. | System security plan mapped to the 800-171 requirements, CUI marking guidance for authors and access review records. |
| NIST SP 800-53 baselines as a control reference | Release 5.2.0 of NIST SP 800-53 is current. The SP 800-53B low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively. Agencies and their contractors often use these baselines to set scope. | Choose the baseline that matches the highest impact category of intranet data, then map hosting, identity and logging controls to it. Use OSCAL profiles to keep the mapping current. | Control implementation statements, a baseline selection memo and an OSCAL or spreadsheet control matrix. |
| Directory integration | Authentication and authorization must follow the agency or municipality's identity source, with leavers removed promptly. Confirm which directory is authoritative for employees, contractors and partner staff. | Plan group-to-space mapping, SSO and account deprovisioning. Confirm which intranet edition supports the directory protocols you need. | Identity architecture diagram, group mapping table and deprovisioning test results. |
| Audit logging and access review | Systems holding sensitive information require audit controls that record and examine activity, in line with the audit control expectations found in federal and state frameworks. Confirm the retention period with your records officer. | Send intranet authentication, administration and content access events to the central logging platform. Confirm which events the chosen edition records natively. | Log source inventory, retention settings, sample audit reports and periodic access review sign-offs. |
| Hosting location and sovereignty | Government data may need to stay in agency or national infrastructure, and cloud use can bring additional authorization requirements. Under FedRAMP scope rules, single-agency systems not offered as a shared service may fall outside its scope. | Prefer self-hosting inside government data centers or an approved cloud. Confirm with the contracting officer whether any cloud service triggers an authorization requirement. | Hosting decision record, data residency statement and any authorization letters or determinations. |
Where the intranet can run and what hosting location means for scope
The hosting location decides which compliance regime you enter before any product choice is made. A public body can run an intranet in a government data center, in a government-controlled cloud tenant, or as a commercial SaaS service. Each option puts different parties in control of the servers, the administrators and the data, and each changes which controls an assessor will ask you to evidence. A self-hosted HumHub, XWiki or Nextcloud instance in your own data center is mainly a question of your internal authorization boundary. A commercial per-user SaaS intranet moves the provider's operations, subprocessors and data locations into your boundary, and you inherit their assessment evidence only to the extent they share it. FedRAMP is the first scoping question for US federal and federally funded bodies. Under the FedRAMP scope set by OMB memo M-24-15, the program covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, falls outside that scope. Confirm this classification in writing with your authorizing official or the agency's FedRAMP program contact before you sign a contract, because the same intranet can be in scope or out of scope depending on whether it is shared across agencies or contractors.
For EU public bodies, NIS2 sets the baseline. It covers central government entities regardless of size and lists public administration as a sector of high criticality, while Member States may extend it to local administration. It does not apply to entities working in national security, public security, defense or law enforcement. Confirm with your national competent authority whether your intranet falls under the directive or under a national security regime, because a defense or police intranet may be governed by stricter rules that do not follow from NIS2 at all. Whichever hosting option you choose, record the decision, the responsible owner and the list of administrators with privileged access, since that record is what an assessor will request first.
Which platform fits which public body
openDesk fits a ministry, agency or municipality that wants one self-hosted workplace with a shared identity layer rather than assembling separate products. It is a Kubernetes-based suite from ZenDiS GmbH that bundles XWiki for wiki and intranet-style content, Nextcloud for files, Element for chat, OX App Suite for groupware and Nubus for portal and identity. The deployment automation is Apache-2.0, but each bundled component keeps its own license, such as AGPL-3.0 for Nextcloud and Nubus and MPL-2.0 for Collabora.
- Cluster prerequisites: openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. It is tested on kubespray clusters, not OpenShift.
- Production services: the project expects external PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, so the body must already run or budget for them.
- Release cadence: only the latest minor version is supported, and in-place upgrades between majors are not guaranteed.
- Enterprise Edition: ZenDiS recommends Enterprise Edition for production, adding SLA-backed second and third level support and Enterprise-only modules.
Confirm the cluster, the external services and the upgrade path with the vendor and your own platform team before committing.
A standalone intranet suits a body that already runs file sharing, email, document management and a case or service system, and needs a shared communication space rather than a new workplace. XWiki, which openDesk also bundles, and HumHub are candidates here. The choice depends on whether the body wants structured wiki and policy content (XWiki) or a social, news-led employee network (HumHub). Both can run on hardware the body already operates, which keeps the intranet inside the existing data center or government cloud boundary.
- Coexistence: the intranet links out to existing systems instead of replacing them, so the body avoids a second copy of files and records.
- Directory integration: confirm which LDAP, SAML or OIDC sources the body needs, and whether the chosen edition supports them without extra modules.
- Accessibility: state and local web content must meet WCAG 2.1 Level A and AA under the ADA Title II rule, with the 26 April 2027 date for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts.
- Edition scope: confirm which HumHub or XWiki features needed for the body sit in the community edition and which sit in Professional Edition or XWiki Pro.
Write down the existing systems the intranet must integrate with before selecting a product, since that list usually decides the fit.
A Nextcloud-centred stack fits a body where files, sharing and collaborative editing are the main daily need and the intranet is secondary. Nextcloud Server is licensed under AGPL-3.0, so the body can inspect and modify the source, but it must still plan for its own patching and hardening. Nextcloud's intranet-style features cover team spaces and internal news in a limited way, so bodies with broad communication needs often pair it with a dedicated intranet tool.
- Hosting boundary: when the body stores case-related or citizen data, confirm whether it falls under a federal cloud authorization regime, since FedRAMP scope applies to cloud services offered to agencies.
- Editions: Nextcloud Enterprise adds security patch channels and support, which the body should weigh against its patching capacity.
- Office and mail: confirm which document editor (ONLYOFFICE Docs under AGPL-3.0 or Collabora Online under MPL 2.0) and which mail platform the stack will connect to.
- Security baseline: map the deployment to the NIST SP 800-53 Rev. 5 baseline the body is assessed against, selecting low, moderate or high.
Ask the vendor which Nextcloud release line and edition it will support, and how security patches reach production.
Integration points that public sector intranets must connect
A public sector intranet is only as trusted as the systems it depends on. The integration points below decide who can sign in, how uploads are screened, where notifications travel, and what evidence survives an incident review. Settle each one before content goes live, not after.
Directory and single sign-on
Employees should sign in once, through the body's own identity provider, with group membership driving access to spaces and news audiences. openDesk documents federation with an external identity provider, which is the starting point for a standalone intranet too. Confirm which protocol the body's provider supports, who owns group mapping, and how leavers lose access on the same day their directory account is disabled. Test deprovisioning, not only login.
SMTP relay for notifications
Digest emails, mandatory read reminders and password or account messages all leave the platform through an SMTP relay. Public sector mail is usually tightly controlled, so the relay must be an approved host with sender domains, SPF and DKIM records agreed with the mail team. Ask who owns the relay, whether notifications can be rate limited, and whether message content avoids personal data that the body's policies would not allow in an external mailbox.
ClamAV over ICAP for uploads
Every file an employee attaches or publishes should pass malware scanning before other users can open it. openDesk expects ClamAV reached over ICAP as an external production service, so the scanner becomes a separate component with its own patching and capacity. Confirm the scan runs on upload and on edit, how infected files are quarantined, and who receives alerts when a scan fails. A scanner that silently times out is a gap an auditor will test.
Object storage and a managed database tier
For production, openDesk expects PostgreSQL 15 or MariaDB 10, Redis 7, Memcached, object storage and a TURN server as externally run services, not containers left inside the evaluation cluster. Choose the database engine the platform build supports, and agree backup and restore targets for each store, since content, files and sessions live in different places. Ask which team patches these services, what recovery point the body expects, and whether storage sits inside national or sovereign infrastructure.
Audit log export for records and incidents
Public bodies must be able to show who viewed, changed or shared content, and when. Export audit events from the intranet and the identity layer to the body's log store or SIEM, rather than relying on an application-only view that administrators can edit. Confirm retention periods with records officers, the format used for export, and whether events from directory changes and admin actions are included. The same trail supports the audit controls expected for regulated records.
How a public body rolls out an intranet in phases
The sequence moves a public body from an agreed scope to a supported, accessible intranet in stages, with a sign-off at each phase so that hosting, identity, accessibility and operations decisions are made and recorded before content moves across. Each phase closes with a named artifact that the owning office can approve.
Agree scope and classify content and audiences
The client's communications, records and HR owners, together with the CIO office and DeployOpen, list the audiences (for example, a single ministry, its agencies or the staff of several municipal departments), the spaces they need and the content each space will hold. Each content class is labeled by sensitivity, such as public, internal or restricted, so that no restricted material is placed in a space open to the whole workforce. The phase closes with a signed scope document that names the owners of each space and the content classes allowed in it. Ask for a written list of out-of-scope content so that later requests are handled through change control rather than added informally.
Decide hosting and identity with a control mapping
The hosting location, the operator model and the directory integration are decided together, because identity sources and data residency determine what the platform can connect to. The security team maps the agreed design to the control requirements that apply to the body, such as the NIST SP 800-53 baseline the authority has adopted or the rules of its own jurisdiction, and records which control is met by which configuration choice. Confirm with the authority's legal and procurement teams whether any cloud-hosted option falls under a federal authorization requirement before shortlisting it. The phase closes with a control mapping that the security office has reviewed and accepted, including the owner of each control and the evidence that will be kept.
Set the accessibility baseline and test against WCAG 2.1 AA
Before theming or content migration, the accessibility baseline is written down as the WCAG 2.1 Level A and AA criteria that apply to the body's web content and mobile apps, using the compliance date that applies to its population size. Testing combines automated checks with manual review by people who use assistive technology, covering the core templates, navigation, forms, search and the mobile view. Findings are logged against the template or theme they come from, so that one fix in the shared theme is verified across every space. The phase closes with an accessibility report listing the tested pages, the open defects, their owners and the agreed remediation before pilot launch. Ask the vendor which test tools and assistive technologies were used and how the report will be updated after each theme change.
Run a pilot with one directorate or department
A single directorate or municipal department is onboarded with its real workflows, including its news, team spaces, document links and approval routines, for a defined pilot period agreed in the scope. Pilot users are drawn from the target audience, and the pilot tracks defects, access requests, moderation cases and questions from staff who were not involved in design. Support contacts and escalation routes are tested as part of the pilot rather than assumed. The phase closes with a pilot sign-off from the owning office, listing the accepted defects, the residual risks and the criteria that the wider rollout must meet. Confirm that the sign-off is recorded in the change system so that the criteria are traceable later.
Migrate content and train staff in waves
Content is moved in waves that follow the content inventory, starting with public and internal material and leaving restricted records in their existing systems until their classification and retention rules are confirmed. Each wave is checked against the source for completeness, broken links and permissions, and migrated spaces are assigned named administrators and moderators. Training is delivered by role, covering publishers, moderators, space owners and general staff, with short guides that match the authority's own navigation and accessibility settings. The phase closes with a migration log per wave, a list of retired legacy pages and a training record showing which roles were covered. Ask the partner how permissions are reconciled after each wave and how legacy portals are switched off.
Hand over operations with a runbook and upgrade plan
The operating team receives a runbook covering installation, backups and restore tests, monitoring, account lifecycle, moderation, incident response and the change process for theme and module updates. The upgrade plan states how the platform's releases are assessed, tested in a non-production environment and applied, and who approves each change. Where the authority chooses a supported edition, the support scope, response expectations and patch cadence are written into the handover so the internal team knows what the vendor provides. The phase closes with a signed handover and a first documented restore test, with the runbook stored under the authority's own change and records management. Ask whether the runbook is versioned with the deployment code so that operational changes stay synchronized with the configuration.
Evidence auditors and regulators ask for from an intranet
This table maps each control area an assessor typically asks about to the evidence an intranet deployment should produce and where that evidence usually goes missing. Read it as a checklist for the implementation scope, not as a statement of compliance. DeployOpen prepares the systems, controls and evidence, while independent auditors and certification bodies assess them and issue any reports.
| Control area | Evidence to prepare | Where it usually fails |
|---|---|---|
| Access and audit logs (CJIS and HIPAA-style audit controls) | Authentication, admin and content-access logs exported to a central store, with retention and review records | Logs stay inside the intranet app only, or no one reviews them for health or criminal justice data spaces |
| Encryption configuration for CJIS-scope data | Documented FIPS 140-3 validated modules or AES with 256-bit keys for data in transit and at rest outside physically secure locations | Certificate and storage settings are left at defaults, or the validation status of the crypto module is unconfirmed |
| Monthly vulnerability scan reports | Scan scope, schedule, tool output and remediation tickets showing scans at least monthly | Scanning covers the web tier only, not the database, object storage or connected services |
| Accessibility test results (WCAG 2.1 Level AA) | Automated and manual test records for templates, themes and modules, with a list of known issues and remediation plans | Testing is done once at launch, and custom theme changes or third-party widgets are never retested |
| Release and patch records | Version inventory per component, change tickets, test results and dates of applied security updates | Component versions drift across environments, or upgrade history is not written down |
| Role-based access reviews | Periodic review of group membership, space admins and directory sync results, signed off by a named owner | Directory groups grow without review, and former staff keep admin rights in spaces holding restricted content |
| Hosting and boundary documentation | Diagram of where the intranet runs, which government network it sits in and which external services it calls | Embedded external content, push services or cloud backups are added later and not recorded |
Questions public sector buyers ask before hiring a partner
What drives the cost of a public sector intranet deployment?
The cost is driven by scope more than by the software, because the core platforms are open source and carry no license fee for the community editions. The main cost components are hosting in your own infrastructure, the edition or subscription you choose for directory and SSO features, accessibility remediation of existing content and templates, content migration from legacy portals, and identity integration work with your directory. Hosting and staffing recur every year, while onboarding, theming, migration and integration are usually one-time. Ask any partner for a quote that separates these items, names who pays for each, and states which parts depend on your current portal and directory. No public figure for DeployOpen work is given here, so request a written scope first.
How long does a public sector intranet deployment take?
Duration depends on the scope you agree in writing, not on a standard timeline. The factors that move it most are the number of audiences and spaces, how many legacy sites must be migrated, how many accessibility fixes are needed, whether your directory needs federation or group synchronization, and how quickly your approval chain signs off on each stage. If you plan to use openDesk, the deployment also depends on whether your Kubernetes platform already meets its requirements. Ask the partner to break the timeline into phases with named deliverables and to list the decisions your team must make before each phase starts.
What does the public body need to provide for the project?
Three things decide whether the project moves: directory access, content owners and a named executive sponsor. The directory team must provide service accounts, group structures and a decision on which identity source is authoritative for employees. Each department needs a content owner who approves what is migrated, what is retired and how news is moderated. The sponsor resolves conflicts between departments and signs off on accessibility and data protection decisions. Hosting access inside your government infrastructure, security review and change approval are also needed. A good partner will ask for these in the kickoff rather than discover them during rollout.
Can our own staff run a self-hosted public sector intranet after launch?
Yes, if you plan for it, but it is an operating commitment that must be staffed. Running the platform means applying security updates, maintaining backups, monitoring hosting, managing accounts, and moderating content. Many public bodies split this between an internal platform team and an external support contract. Confirm with the partner what documentation, runbooks and knowledge transfer are included in the fixed scope, and what ongoing support is available as a separate retainer. Ask how many people your team needs to cover operations, whether that staffing exists, and what happens during staff absences.
Is openDesk Enterprise Edition required for a production deployment?
The openDesk project recommends Enterprise Edition for production, but the open-source core is available under its component licenses. According to ZenDiS documentation, Enterprise Edition uses the same open-source core licenses and adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Enterprise-only features include Collabora branding and automatic load scaling, Nextcloud Enterprise security patches and the Guard app, and OpenProject Enterprise add-ons. Decide whether your support obligations require SLA-backed patches. Ask partners to price the community and Enterprise options separately, and check whether your procurement rules accept closed-source modules.
How do upgrades work with openDesk's release cadence?
openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, in-place upgrades between majors are not guaranteed, and skipping several minor versions may require intermediate steps. This means you need a repeatable upgrade process, a test environment that mirrors production, and an agreed window for changes. Ask the partner how they track releases, who tests each upgrade, how rollback works, and whether upgrades are included in a retainer or quoted per event. Confirm these points with ZenDiS release documentation before you commit to a support model.
Does the partner handle accessibility fixes for public sector web content?
Accessibility is a scope item you should agree in writing, because the legal deadline applies to the public body. Under the ADA Title II rule, state and local government web content and mobile apps 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, according to 28 CFR 35.200. Ask the partner to assess the templates, themes and plugins they will deploy, to list which content owners must fix their own pages, and to describe how testing evidence will be documented. DeployOpen prepares controls and evidence but does not issue conformance certifications, so confirm independent testing with your own assessor.
What to ask an implementation partner before signing
Put every question below in writing and file the answers with the statement of work. Start with the accessibility claim, because the ADA Title II rule requires state and local government web content and mobile apps, including those provided through contracts, to meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people. Ask the partner which test method produced its WCAG 2.1 AA results: automated scanning only, manual review with assistive technology, or both. Ask who tested, which browsers and screen readers were covered, and whether the bundled components you plan to use, not just the core intranet, were in scope. Ask for the open defects list, not a summary.
Next, pin down where the system runs and who can touch it. Ask whether the deployment will sit inside your government data center or an approved hosting environment, and which named staff hold access to hosts, databases, backups and logs. For directory integration, ask which protocol is planned, SAML or LDAP, and whether the partner has confirmed that the chosen intranet edition supports it. Ask who holds the administrator credentials after handover, how break-glass access is recorded, and whether the account used by the partner for setup is disabled at go-live. Ask for the written handover list of privileged accounts.
Finally, settle support and upgrades before the contract is signed. For openDesk-based designs, ask which tier covers second and third line support, what the response and restoration commitments are in writing, and whether any SLA terms are part of the price or a separate option. Ask how the partner will move your environment between openDesk minor releases, given that only the latest minor version is supported and skipping several minors may require intermediate steps. Finally, ask for the evidence pack you will hand to your assessor, including configuration baselines, access reviews, vulnerability scan results and audit log samples, and confirm that the partner prepares this evidence but does not issue any attestation.
Procuring a supported edition: what to request in writing
Open-source core licenses do not settle support for a public-sector intranet. Each vendor edition, add-on and implementation partner needs its own written terms before go-live. Confirm support terms, licences and hosting options with each vendor before you sign, and keep the four items below in one procurement file.
openDesk Enterprise Edition
ZenDiS recommends openDesk Enterprise Edition for production. It keeps the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Enterprise-only items include GroupSync, the Admin Console and Nextcloud Enterprise security patches. Ask which support levels, response times and patch windows the SLA covers, and whether the closed modules fit your open-source policy.
XWiki Pro apps
XWiki's intranet spaces, policy pages and document content can run on the community core, while Pro apps are separate paid components that openDesk Enterprise also lists among its Enterprise-only features. Before you buy, list the apps your intranet needs, such as directory or administration features, and confirm them with XWiki. Ask whether the license covers on-premises installs in your data center, how many instances it permits, and what support terms apply to each app.
Nextcloud Enterprise security patches
Nextcloud Server is licensed under AGPL-3.0, so the core code can be installed and audited without a license fee. Enterprise security patches are a separate commitment. Within openDesk Enterprise, they come with the Guard app as part of the bundle. If you run Nextcloud outside openDesk, ask who delivers security patches, on what timeline, and under which contract for your version. Confirm that terms cover your hosting model and that the patch process fits your change control.
Fixed-scope implementation agreement
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The agreement should name each deliverable, the acceptance test for it, and who holds the vendor licenses and hosting accounts. It should also set how change requests are priced and approved, and how support passes to your team or to a retainer. Vendor licenses and support contracts are usually bought separately from the implementation, so list them as excluded items to avoid gaps.
How DeployOpen scopes and supports a public sector intranet
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a government data center, a sovereign cloud account or a segregated network. For a ministry, agency or municipality, the practical starting point is a written, fixed-scope agreement that names the intranet platform, the hosting boundary, the directory and identity integration, the accessibility target and the deliverables before any work begins. DeployOpen does not publish a price list, so the quote follows from that scope. Ask each bidder to state which items in the scope are fixed, which depend on decisions still open (for example, whether the portal sits beside an openDesk deployment or stands alone) and how changes to scope are priced.
Security testing is scheduled before go-live, not after. For a public sector intranet, that means testing the web application and its APIs, the identity integration and the hosting layer, and checking that the accessibility work described in the scope has been verified against WCAG 2.1 Level AA. Agree in the scope who receives the findings, how remediation is tracked and what retest is included. Where the intranet will carry personal data of civil servants or citizens, ask the partner how test data is handled so that no live records leave the environment during testing.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration baselines, access reviews, backup and restore records and change logs. It does not issue audit reports, attestations or certifications; those come from independent auditors, accreditation bodies or the authority that owns the assessment. Confirm early which assessment applies to your organization and which evidence that assessor expects. Ongoing upgrades, patching and continuous testing are available as retainers, which matters because the intranet will need regular updates and a supported upgrade path rather than a one-time handover.
