Why a self-hosted knowledge base for the public sector starts with hosting and access rules
For most agencies, the main candidate for a self-hosted wiki is XWiki, because its structured permissions, page and space rights and LGPL 2.1 license fit government policy libraries better than simpler wikis do. If the agency wants a full workplace rather than a single wiki, the option to evaluate is openDesk, the Kubernetes-based suite from ZenDiS that bundles XWiki with files, office, chat, video, groupware and identity. The choice between them is mainly a question of how much of the surrounding workplace the agency must run under the same identity layer.
A knowledge base in the public sector differs from a private sector wiki because the content must stay under national or agency control, and the hosting decision is made before any page is written. Baselines such as the NIST SP 800-53 control catalog, which the Office of Management and Budget and FISMA shape for US federal systems, or state-level equivalents, determine which controls the wiki inherits or must implement. Accessibility is a second constraint: the ADA Title II rule sets WCAG 2.1 Level A and AA deadlines for state and local government web content, and those dates depend on the population the entity serves. Records retention is the third. Agencies should confirm with their records officer which policies and procedures must be kept, for how long, and whether page history itself counts as a record.
Before a pilot, confirm three things in writing: which hosting zone and operator will run the platform, which baseline the agency must meet and who assesses it, and which identity source (such as directory groups or an external identity provider) will drive department-level permissions. Those answers determine whether a standalone XWiki deployment or an openDesk deployment is the right starting point.
Which public sector requirements shape the wiki build
This table maps each public sector requirement that applies to an agency wiki to what it asks for and how it changes the build. Read the first column to find the rule that applies to your agency, then the third column for the design decisions it forces. Applicability depends on your jurisdiction, funding and data types, so confirm scope with counsel or your assessor before committing to a design.
| Requirement | What it asks for | Effect on the wiki build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements, per SP 800-53B. Used as the control source for US federal and federally funded systems. | Choose the baseline before choosing hosting. Map page classes, admin roles and logging to control families so evidence can be produced for each system boundary. |
| FISMA and OMB Circular A-130 | Agencies assess and report security of their systems. Inspectors General independently assess agency security and report to OMB. | Keep an inventory of the wiki as a system, with owners, boundaries and review dates. Retain audit logs and access reviews that an Inspector General can sample. |
| FedRAMP scope under M-24-15 | Applies to cloud products that handle federal information on behalf of an agency. Systems used only for one agency's internal operations on cloud infrastructure are generally out of scope. | Self-hosting inside the agency's own infrastructure usually keeps the wiki out of FedRAMP scope. A hosted or shared wiki offered to several agencies may fall in scope, so confirm the model with your authorizing official. |
| CJIS Security Policy v6.1 | For criminal justice information, FIPS 140-3 validated modules or AES-256 for CJI in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly. | Pages that contain CJI need encrypted storage and TLS with validated modules, and a scanning schedule for the wiki host and its containers. Restrict CJI pages to a separate space with its own access rules. |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 | Agencies use NIST SP 800-171 when setting requirements for CUI on non-federal systems, unless the CUI category prescribes other safeguards. | Where contractors or partners edit CUI pages on their own systems, the wiki's access, encryption and audit settings must meet the 800-171 requirements the agency sets. Mark CUI pages with labels that drive permissions. |
| ADA Title II and WCAG 2.1 Level AA | State and local government web content 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). | Pick a wiki and theme that can meet WCAG 2.1 AA. Build page templates with heading structure, alt text fields and color contrast rules. Test published pages and the content editors produce, not only the theme. |
| NIS2 public administration scope | Covers central government entities regardless of size. Member States may extend it to local administration. It excludes entities in national security, public security, defense or law enforcement. | In EU agencies, determine whether the entity is in scope before deciding how much of the wiki falls under NIS2 risk management and incident reporting. Keep security-sensitive or law enforcement content in a separate instance. |
How department-level permissions and records change page design
Agency wikis hold content owned by many departments, and each department brings its own editors, readers and retention duties. The design decision that follows is to model those owners as separate spaces with their own page rights, rather than one shared space with exceptions bolted on. In XWiki, spaces and page-level rights let an agency give a records office read access across departments while limiting edit rights to the program team that owns a procedure. Map those rights to directory groups from the agency's identity provider instead of maintaining local accounts, so that a transfer or departure in the HR system changes wiki access without a manual ticket. Before go-live, confirm with your partner exactly which group-mapping and single sign-on features are included in the edition you select.
Directory integration and single sign-on for Active Directory and Azure Active Directory are listed among XWiki Pro applications, along with connectors for Office365 and OnlyOffice. If your agency relies on those directories, budget for XWiki Pro or a support subscription in the cost model and confirm the current tier, since XWiki SAS publishes user-count tiers from Starter to Enterprise. For agencies using other identity platforms, confirm the OpenID Connect or SAML path with the vendor and the xwiki-contrib OIDC extension before committing. Audit who can read what by exporting effective rights per space on a schedule, and test that report against a sample of restricted pages before relying on it as evidence.
Records retention is an agency policy question, not a wiki default. The wiki must support page versioning, export and a way to show who changed what and when, but the agency decides how long each class of page is kept, when it is reviewed and when it is disposed of, under its own statute, schedule and archival rules. Do not import retention periods from private-sector rules. The SEC rule for broker-dealer communications and the HIPAA Security Rule's audit and transmission controls are the wrong reference points for a public agency unless a specific law or contract applies them. Ask your records officer to classify the pages by series before migration, and confirm with your partner how page history and attachments survive a Confluence migration, because the migration tooling documents its own limits on attachment history.
Which platforms fit public sector agencies and why
XWiki Standard is the free, open source edition of XWiki, licensed under the LGPL 2.1. Agencies that run their own Kubernetes or virtual machine estate can deploy it directly from the official Docker images, which come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat. The project publishes a stable line, a long term support line and an intermediate LTS line. At the time of research the tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS, so the agency should choose a line that matches its upgrade cadence.
- Full control of the estate: Hosting, backups and network placement stay inside the agency's own accreditation boundary.
- Structured data and permissions: XWiki's space and page rights, plus its application model, suit department-level separation.
- Database choice: Pick the variant that matches the database service the agency already operates and supports.
- Support is self-sourced: Without a commercial subscription, patching, incident response and upgrades rely on the agency's own staff or a partner.
- Feature gaps: Directory integrations and business connectors listed for XWiki Pro are not part of the standard edition.
Confirm with the agency's security team which XWiki line is approved, whether the chosen database and Tomcat versions are supported, and who owns patching for the image.
openDesk is a Kubernetes-based digital workplace suite for public administration, provided by ZenDiS GmbH, and XWiki is one of its bundled components. Deployment is automated with Helmfile and Helm under an Apache-2.0 license, but each bundled component keeps its own license, so XWiki's terms apply to the wiki itself. This option fits agencies that want the wiki integrated with files, office, groupware, chat and identity under one platform, rather than assembling those parts separately.
- Shared identity layer: Nubus provides portal and identity management across the bundled components.
- Prerequisites are demanding: The platform requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager and external production services such as PostgreSQL 15, Redis 7 and an SMTP relay.
- Enterprise Edition for production: ZenDiS recommends openDesk Enterprise Edition, which adds SLA-backed support and includes XWiki Pro apps among its Enterprise-only features.
- Release discipline: Only the latest minor version is supported, and in-place upgrades between majors are not guaranteed.
- Less control over the wiki configuration: Changes to the bundled XWiki must follow the openDesk release model.
Confirm the support model, the Kubernetes platform the agency will use (openDesk is tested on kubespray clusters and not on OpenShift) and which XWiki capabilities are included in the edition being licensed.
BookStack is a wiki platform licensed under MIT, and v26.09.1 was published on September 29, 2026. Its book, chapter and page structure is simple to learn, which makes it a practical choice for a single department that needs shared procedures, forms guidance or team handbooks without a structured application model. The MIT license places no reuse restrictions on the agency or on partners that operate it.
- Low operating footprint: A simple structure means fewer moving parts for a small team to patch and back up.
- Clear licensing: MIT terms allow the agency to host and modify the software without a commercial agreement.
- Limited structure for cross-department governance: Department separation is possible, but BookStack lacks the structured applications and per-space model that large multi-department wikis often need.
- Self-managed support: Vendor support is not part of the open source offering, so the agency must plan internal ownership.
- Scale planning: Confirm how the chosen version handles the number of users, shelves and attachments expected in the department.
Before selecting BookStack, confirm that its permission model meets the agency's records and accessibility obligations, and that it can be expanded or migrated if other departments later join the same wiki.
Outline is a modern wiki with a polished editing experience, but it is licensed under the Business Source License 1.1. The additional use grant forbids using the software to offer a commercial Document Service. For most internal government wikis this restriction is not a barrier, but it matters when an agency hosts documentation for other public bodies, shares services through a joint operation, or contracts a provider to run the wiki for several clients. Outline 1.11.0 was published on October 12, 2026.
- Shared service risk: A provider running Outline for several agencies may fall outside the grant, so the arrangement needs legal review.
- Internal use is the common case: An agency running Outline only for its own staff sits within the grant's intent, subject to legal confirmation.
- Licensing check: Ask counsel to confirm the grant wording against the agency's exact arrangement.
- Permission and accessibility review: Test page-level rights and the accessibility of published content against the agency's obligations.
- Records and audit: Confirm export and retention options before adopting it for records-bearing content.
Before choosing Outline, have legal counsel review the license against any shared-service or hosting arrangement, and confirm that the chosen deployment supports the agency's identity, retention and accessibility requirements.
Five build decisions that decide whether the wiki passes review
Agency wiki reviews tend to turn on five choices: where the platform is hosted and under which authorization scope, how sensitive content is encrypted, whether published pages are accessible, how Confluence content moves over, and how the platform keeps receiving updates. Each choice carries evidence that reviewers will ask for, so settle them before the first page is migrated.
Hosting location and authorization scope
Decide whether the wiki runs in an agency data center, a state or national cloud, or a commercial cloud region. FedRAMP's scope covers cloud products that handle federal information on behalf of an agency as a shared service, so a wiki run only for one agency's internal operations on its own infrastructure is generally outside it. Ask counsel and the authorizing official to confirm that classification in writing, and record which controls the hosting provider inherits.
Encryption for CJI and sensitive pages
If pages may contain criminal justice information, the CJIS Security Policy in version 6.1 requires FIPS 140-3 validated modules or AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations. Confirm that the TLS termination, database encryption and backup tooling all use validated cryptographic modules, not only the application. Get the module certificate numbers in the evidence pack.
Accessibility testing of templates and content
Title II of the ADA requires state and local government web content, including content delivered through contracts or licenses, to meet WCAG 2.1 Level A and AA. Test the page templates, navigation, search results and the editor's output, not just a sample of finished pages. Build a recurring review into the publishing workflow so that newly published pages are checked against WCAG 2.1 AA before they go live.
Confluence migration plan and its gaps
Plan the migration in stages covering spaces, users, groups, permissions, page history and attachments. Tools such as Confluence Migrator Pro carry over page history but not attachment history, so an agency that must keep attachment revisions needs a separate archive or export. Map each Confluence permission to an XWiki right before migration, then sample pages from every department to confirm that readers see what they saw before.
Upgrade path tied to release lines
Choose the XWiki line that matches your upgrade tolerance: the stable line for faster feature access, or the long term support line for slower, planned change. If the wiki is part of openDesk, follow its release policy, which supports only the latest minor version and does not guarantee in-place upgrades between majors. Write a test-and-rollback procedure for each upgrade and schedule it against the accreditation or assessment cycle.
How an agency wiki rollout runs from scoping to handover
The sequence moves from security scoping and platform choice through permission design, accessibility testing and a Confluence pilot to a cutover with runbooks the agency can operate on its own. Each phase closes with a named output that the security office and business owners sign off before the next phase starts.
Scope the system boundary with the security office
DeployOpen works with the agency security office to define the system boundary, the data classes the wiki will hold (for example, internal policy, personnel material or citizen-facing content) and the control baseline that applies. Where the agency uses NIST SP 800-53 Rev. 5 as its reference, the baseline choice (low, moderate or high, as defined in SP 800-53B) should be confirmed in writing before any design work. The step is complete when the security office signs a scope statement and a control mapping that names which controls the wiki must satisfy and which the hosting layer must provide.
Choose the platform and check prerequisites
The agency decides between standalone XWiki, deployed on its own virtualization or container platform, and XWiki as one component of an openDesk deployment. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner and Helm and Helmfile at the versions listed in the openDesk requirements, and it expects external production services such as PostgreSQL, Redis, an SMTP relay and object storage. The output is a prerequisite checklist with a yes or no for each item, plus a decision record stating why the agency chose its option. Confirm with the openDesk maintainers whether an OpenShift or other distribution is acceptable, since the requirements document lists kubespray as the tested basis.
Design identity and department permissions
DeployOpen maps the agency directory groups to wiki roles, then designs the space model so each department owns its spaces, with read and edit rights set at the space and page level where sensitive material such as HR or legal pages needs separation. The design covers single sign-on through the agency identity provider and how group changes from joiners, movers and leavers reach the wiki. The outputs are a group map, a space model with owners named for each space, and an audit query that lists who can read and edit every space. The step closes when the security office can run that query and get the expected answer for a sample of accounts.
Build templates and run the accessibility test
The build team configures the approved page templates, navigation, search and publishing workflow, then tests published content against WCAG 2.1 Level A and AA, the success criteria that the ADA Title II rule adopts for state and local government web content. Where the agency serves 50,000 or more people, the rule applies from 26 April 2027, and smaller entities and special districts from 26 April 2028, so the agency should confirm which date applies to it. The output is a test report listing defects by page type, the fixes applied and any residual issues with an owner and a plan. Accessibility of templates is tested here, not only at launch, because every page inherits them.
Pilot the Confluence migration on sample spaces
Before any bulk move, the team migrates a representative sample of Confluence spaces, chosen to include the largest spaces, restricted spaces and pages with heavy attachments. Confluence Migrator Pro from XWiki SAS is one tool that moves spaces, pages, users, groups, permissions, attachments and metadata and keeps page history but not attachment history, so the pilot must test that limit directly. The output is a reconciliation report comparing page counts, permissions and attachment counts between source and target, and an exceptions register listing attachments or history that did not carry over and how each will be handled. Ask the migration vendor to confirm the current trial limits and license terms before the pilot starts.
Cut over, train editors and hand over runbooks
The team plans the production cutover with a freeze window agreed with the business owners, runs the full migration, repeats the reconciliation against the pilot results, and redirects users from the old space to the new one. Editors, space owners and administrators receive role-based training on templates, permissions and publishing rules. The handover package includes operations runbooks for backup, restore, upgrades and access reviews, and the agency staff who will run the platform perform a restore test before the project closes. The step is complete when the reconciliation is signed, the training record is filed and the agency operator confirms in writing that it can run the runbooks without DeployOpen.
What auditors and inspectors ask for from the wiki
Who can read restricted spaces in our wiki, and how do we prove it?
The answer comes from a permission export that lists, for each space and page, which groups and users hold read, edit and admin rights, combined with the directory group mapping that feeds those groups. XWiki handles this through page and space rights, and the identity provider remains the source of group membership. Auditors usually want the export dated, the list of group-to-role mappings, and a record of who approved changes to them. Confirm with your wiki platform which permission reports it exposes natively and which need a query or script. DeployOpen can prepare the export procedure, the mapping documentation and the review cadence, but the sufficiency of the evidence is decided by your auditor or inspector, not by DeployOpen.
How do we show who changed a policy and when?
Page history is the primary record: each saved revision stores the author, timestamp and content, so a reviewer can compare any two versions of a policy or procedure. Page history alone rarely covers administrative actions such as permission changes or account deletions, so pair it with platform audit logs from the wiki and from the identity provider. Ask whether your platform keeps history for attachments as well as pages, since some migration tools keep page history but not attachment history. Set a retention period for logs that matches your records schedule, and store exported logs outside the wiki server so they survive a rebuild.
Did we test the published content against WCAG 2.1 AA?
Evidence is a dated accessibility test report that covers the published pages, templates and any custom theme, measured against WCAG 2.1 Level A and AA. Public sector entities subject to the ADA Title II web rule must meet that standard for web content, including content provided through contracts or licenses, with compliance dates of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Automated scans give coverage but not complete proof, so record manual testing with assistive technology, the tools and versions used, and the remediation log. Confirm the applicable deadline for your entity with counsel.
How are records retained and exported for an inspection?
Retention is defined by a written schedule that states which spaces are records, how long each class is kept and what triggers deletion or archiving. The wiki must then enforce that schedule, typically through export and archive procedures rather than native retention rules, so confirm what your platform supports. Export tooling should produce complete page content, history and attachments in an open format with a checksum or manifest, so an inspector can read the output without the live system. Where regulation sets a minimum period, such as the three-year rule for certain broker-dealer communications, that period belongs in the schedule. Your records officer and legal team own the schedule; DeployOpen can implement the export jobs and test a restore.
How do we show the wiki platform is patched and supported?
The patch evidence is an upgrade log that records each version deployed, the date, the change ticket, the test result and the rollback point. For XWiki, the record should state whether the instance runs the stable line or an LTS line, since the LTS lines are the ones intended for organizations that need longer support windows. If the wiki runs as part of openDesk, the record should cite the openDesk release used, because openDesk supports only the latest minor version and does not guarantee in-place upgrades between majors. Ask your vendor or partner for the support lifecycle in writing, and keep the vulnerability scan results beside the upgrade log.
Who owns the evidence, and what does DeployOpen provide?
DeployOpen prepares the controls, configuration records and evidence that an assessment will examine, including permission exports, log configuration, accessibility test runs, retention procedures and upgrade records. DeployOpen does not issue audit reports, attestations or certifications, and it does not decide whether a control is effective. Independent auditors, inspectors and certification bodies draw those conclusions. Your engagement scope should list each evidence item, its owner, the producing component and how often it is refreshed, so the work is agreed before implementation starts.
What should we ask a partner to confirm before an audit?
Ask for a written list of evidence items, the component that produces each one and the command or screen used to extract it. Request a sample export from a non-production instance so you can check its content before inspectors ask for it. Confirm where logs are stored, how long they are kept, and whether they are protected from edits by administrators. Ask how group membership changes are reviewed and how upgrade records are signed off. Finally, confirm that the scope of the engagement includes the evidence pack and a walkthrough with your internal audit team, which DeployOpen can deliver as part of a fixed-scope engagement.
What to ask an implementation partner before a public sector wiki contract
Start with scope, because every other answer depends on it. Ask the partner which control baseline they have scoped the wiki against and which data classes they expect the pages to hold. NIST SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively, so a partner who says "we follow NIST" without naming a baseline has not finished the scoping. Ask for the written mapping from the baseline to the wiki's configuration, hosting and logging, and ask whether any page may carry criminal justice information, which would bring the FBI CJIS Security Policy into scope with its FIPS 140-3 and vulnerability scanning requirements. Confirm the answers in the fixed-scope document, not in the sales conversation.
Next, ask whether the partner builds on XWiki Standard or XWiki Pro, and why. Standard is the free open source edition. Pro adds the Active Directory and Azure Active Directory SSO applications and the Office365 and OnlyOffice connectors, and the openDesk Enterprise Edition notes say XWiki Pro apps are part of the Enterprise-only set. Ask the partner to list every extension they plan to install, its license and its maintainer, and to explain which department-level permission or SSO requirement each one solves. For SSO and permission tests, ask how they will prove that a user in one department cannot read another department's spaces, how group changes in the directory propagate, and what audit export format the wiki produces and who reviews it. Ask for the test scripts and the sample export, not a description of them.
Then cover migration, accessibility and the support model, each with a named sign-off. For Confluence, ask how spaces, permissions, page history and attachments will be reconciled against the source, since the XWiki Store describes its Confluence Migrator Pro as keeping page history but not attachment history. Ask who signs off the reconciliation and what happens to pages that fail. For accessibility, ask which WCAG 2.1 Level A and AA tests are run, whether they use automated tools plus manual review with assistive technology, and who on the agency side accepts the result, since the ADA Title II deadlines apply to web content delivered through contracts. For support, ask whether the agency will run openDesk Enterprise Edition or a community deployment, who provides second and third level support in each case, and which parts of the stack fall outside that support. Finally, require written upgrade and rollback commitments: the supported version window, the test environment used before each upgrade, the rollback window and the recovery point, all stated in the fixed scope.
How much does a public sector wiki cost and what does the agency need to provide
What drives the cost of a public sector wiki?
Cost is driven by who does the work and how much of it there is. The software itself is free to download under the open-source license of the chosen platform, such as XWiki Standard. Recurring and one-time costs come from four places: the agency's own staff time for identity, hosting and content, the implementation partner's fixed-scope work, the support or Pro subscription if the agency wants vendor backing, and the infrastructure the wiki runs on. The main cost multipliers are the number of spaces, the number of integrations (identity, file storage, office editing, ticketing), the volume of content to migrate, and the accessibility and permission design the agency requires. Ask any quote to split one-time work from recurring support and to list each integration separately.
How much does XWiki consulting and training cost per day?
XWiki SAS lists consulting at 1200 EUR per day and training at 1500 EUR per day on its pricing page. Consulting from XWiki SAS requires a Business or Enterprise support plan, so an agency that wants vendor consulting should budget for that subscription as well. These are list rates from the vendor, not DeployOpen prices. DeployOpen does not publish a price list. An implementation quote follows from the written scope, which should state the number of days, the deliverables and the responsibilities of each party.
Which XWiki Pro subscription tier fits our user count?
XWiki Pro and support subscriptions come in four tiers by user count. Starter covers up to 25 users and is available for XWiki Cloud only. Basic covers up to 1,000 users, Business covers up to 10,000 users and Enterprise has no user limit. XWiki SAS states that cloud and on-premises pricing is the same, so the tier choice does not depend on where the wiki is hosted. Agencies running XWiki inside their own infrastructure should confirm with XWiki SAS which tier includes the features they need, such as directory single sign-on and the Pro applications, before selecting one.
How much does migrating from Confluence cost?
Confluence Migrator Pro from XWiki SAS is priced from 2000 EUR. It migrates spaces, pages, users, groups, permissions, attachments and metadata, and it keeps page history but not attachment history. A trial is limited to 30 pages per migration, which is useful for testing mapping rules but not for a full move. The license is one part of the cost. Pages that need manual cleanup, permission remapping to agency directory groups and validation of accessible content will add effort. Ask the partner to run a trial migration on a representative sample and to list which items will need manual work.
Does time to deploy depend on spaces and integrations?
Yes. Effort scales mainly with the number of spaces and their permission rules, the number of integrations and the volume of content that needs cleanup. A wiki with a few departmental spaces and one directory integration is a very different project from one with dozens of spaces, nested permissions, legacy Confluence content and links to office editing and ticketing. The agency should ask for a timeline that is broken down by phase, and should confirm that the scope lists each space group, each integration and each migration batch. DeployOpen agrees timelines in writing as part of a fixed-scope engagement.
What does the agency need to provide for the wiki project?
The agency must provide the people and access that only it can supply. Identity administrators need to configure the directory, groups and single sign-on that define who can read and edit each space. Platform or infrastructure staff need access to the target environment, including Kubernetes access if the wiki is deployed as part of an openDesk stack. Content owners from each department need to approve what moves, decide which pages are current and sign off on permissions. Compliance or accessibility leads should confirm the standards that apply. Agreeing these roles in the scope document prevents the most common delays.
Can our own staff run a public sector wiki without a partner?
Staff can run a wiki alone if they have the skills and time for ongoing operations, but the first deployment, the identity integration and the migration usually need specialist experience. Operating the platform means applying upgrades, managing backups, monitoring availability, reviewing permissions and keeping accessibility of published content under review. Agencies that already run Kubernetes or have an established platform team often keep operations in house and buy a partner for the initial build. Agencies without that capacity should ask a partner to document the system and train their administrators before handover.
Is ongoing support available as a retainer?
Yes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, separate from the fixed-scope implementation. A retainer typically covers patching, upgrades between versions, backups, incident response and periodic review of permissions. The retainer scope and response expectations should be written into the contract, and agencies should compare them with the vendor support tiers, such as XWiki SAS subscriptions, to avoid duplicated or missing coverage. Ask for the retainer terms in writing before the build starts.
Where DeployOpen fits in a public sector wiki program
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms inside the agency's own infrastructure, whether that is a government cloud tenancy, an agency data center or a network with no outside connectivity. For a wiki program, that work covers the parts an agency cannot hand off to a generic vendor: deploying XWiki or a component of an openDesk deployment, wiring it to the agency's directory and identity layer, designing the space and group permission model across departments, setting up the migration from Confluence and the retention approach for records, and documenting the result for the team that will run it afterward. DeployOpen does not issue audit reports, attestations or certifications. It prepares the system configuration, access reviews, backup and restore evidence and control documentation that an agency's assessors or certification bodies will examine, and the agency decides which assessor to engage.
Engagements are fixed-scope. Before work starts, the agency and DeployOpen agree in writing on the scope, deliverables and timeline, so the agency can see which items sit inside the engagement, such as the accessibility remediation of published content, the migration waves and the permission audit, and which sit with the agency's own staff. Ongoing work after go-live, including platform upgrades, security patches and periodic permission reviews, is usually better handled through a retainer than through repeated one-off projects. Ask for the upgrade approach in writing, because openDesk's own release management documentation says only the latest minor version is supported and that skipping several minor versions may need intermediate steps. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen scopes, builds and supports the agency wiki
The sequence turns an agency's control, accessibility and records requirements into a written scope, a wiki built inside the agency's own environment, verified content and permissions, and a handover the agency can run without outside help.
Agree the written scope and targets
DeployOpen works with the agency's security, records, accessibility and business owners to define the in-scope spaces, user populations, identity source, hosting boundary and the control and accessibility targets the wiki must meet. Targets are tied to the agency's own baseline, such as the NIST SP 800-53 Rev. 5 control set it adopts, and to WCAG 2.1 Level A and AA where the ADA Title II rule applies. The output is a signed statement of work that lists deliverables, exclusions and acceptance criteria. Work starts only after both parties sign it.
Map the requirements to controls
Each agreed requirement is traced to a configuration item, a procedure or a test. Examples include who may read restricted departmental spaces, how page history is kept, how audit logs are retained and where the data is stored. The output is a requirements traceability matrix that the agency's assessors can read without help from the implementation team. Gaps between the baseline and the chosen platform are recorded with an owner and a decision.
Build inside the agency environment
DeployOpen deploys XWiki, or the agreed components of an openDesk deployment, into the agency's own cloud account, data center or isolated network. Identity is connected to the agency's directory through the agreed protocol, and spaces are created with the permission model from the traceability matrix. Hosting choices are fixed at this stage, including the database variant and whether openDesk is installed in its evaluation or production configuration. The output is a working staging environment and a configuration record kept in version control.
Harden, back up and reconcile migrated content
The environment is hardened to the agreed baseline, and backup and restore are tested with a documented recovery target. Content from any source wiki is migrated in batches, then reconciled against the source: page counts, permissions, users, groups and attachments are compared. Where a migration tool does not carry a given item, such as attachment history, the gap is recorded and the agency decides how to handle it. The output is a hardening report, a restore test record and a reconciliation report signed off by the content owners.
Test accessibility and permissions before go-live
Published templates and representative pages are tested against WCAG 2.1 Level A and AA, and permission tests confirm that each restricted space is hidden from users outside its group. Findings are logged with severity and owner, and the agency approves the fixes or accepted exceptions before go-live. The output is an accessibility test report and a permission test report that the agency keeps with its compliance evidence.
Document and hand over the platform
DeployOpen writes operating procedures for administrators, editors and records officers, covering backup, restore, user onboarding, permission changes, retention rules and the upgrade path. Staff from the agency's team are trained on these procedures and perform at least one restore and one permission change under observation. The output is a handover pack and a completed training checklist, with named agency owners for each operating task.
Run upgrades, testing and support under a retainer
After handover, a retainer can cover patching, version upgrades, periodic accessibility and permission re-tests, and security testing of the wiki and its integrations. Upgrade windows are planned against the vendor's release notes, and the retainer scope lists which vendor releases are in and out. The output is a maintenance calendar, a dated test log and an updated configuration record after each change. Retainer terms, response expectations and fees are set in the written agreement and are not fixed here.
