XWiki security hardening guide

Why XWiki security hardening starts after the first install

Hardening a self-hosted XWiki starts once the first install works, because a default installation is built to be usable, not to be locked down. If your team runs XWiki in its own infrastructure, or is about to, the first decision is which parts of the stack you must secure and in what order. The work covers the XWiki application itself, its scripting and rights model, the Tomcat servlet container it runs on, the database behind it, the reverse proxy in front of it, and every installed extension. Each layer has its own settings, and a gap in any one of them can expose the whole wiki.

The work is easy to underestimate because XWiki does not come in a single form. XWiki publishes a stable line, a long term support (LTS) line and an intermediate LTS line. The official Docker images are published in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, and each variant and line can carry its own defaults and its own upgrade path. At the time of research, the official image tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS. Confirm the current tags against the official image library before you pin a version, because they change with each release.

For that reason, hardening should be tied to the line and database variant you choose, not written as a generic checklist. A baseline you prepare for a stable release may not match the LTS line your security team has approved, and a setting that works on one database variant may need adjusting on another. Before you start, ask the implementation team to document the chosen line, the image variant, the Tomcat version in use and the list of extensions, and to record which default values were changed and why. That record becomes the starting point for every later security release and upgrade.

Plan for ongoing work as well. Security releases, extension updates and changes to the reverse proxy or database will all need to be checked against the hardened baseline. Ask who owns each layer, how quickly your team can apply a security release, and how you will test a change before it reaches production. Hardening evidence, such as configuration records, test results and change logs, helps your internal teams and independent auditors judge your controls. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Only independent auditors and certification bodies can do that, so treat your hardening evidence as support for their assessment, not a replacement for it.

Which XWiki components carry the attack surface

A hardening review should start with the components that accept input, run code or hold data. The six areas below hold most of the exposure, and they interact: a permissive rights model matters more when scripting is open, and a weak proxy matters more when the servlet container exposes management paths. Use each card as an inspection checklist and record the setting or artifact you checked.

Application and rights system

Rights are granted at wiki, space and page levels through groups, allow and deny entries, and inheritance. Guest access and the default rights on new spaces decide who can read and edit by default. An auditor will review the global rights settings, the groups holding administrative or programming rights, and any page-level overrides that break inheritance. Confirm each group's membership against your directory before sign-off.

Scripting services and macros

Wiki pages can run server-side code through scripting macros and script services, and the right to use them is separate from the right to edit content. Users with script or programming rights can run code inside the XWiki server, which makes this the highest-impact area in the review. Check which users and groups hold those rights, which macros are enabled, and who created pages that contain script macros. Ask the vendor which settings govern scripting in your version.

Tomcat and the reverse proxy

The official XWiki Docker images run on Tomcat, so the connector configuration, TLS settings and any exposed management endpoints are part of the attack surface. The reverse proxy in front usually terminates TLS and forwards requests, so its header handling and path rules decide what reaches XWiki. Check that only the intended ports and paths are reachable from outside, that administrative paths are blocked at the proxy, and that forwarded headers are set consistently. Compare the Tomcat configuration with your hardening baseline.

Database account and backups

The database, which can be MySQL, PostgreSQL or MariaDB in the official Docker image variants, holds page content, rights data and user records. The main risks are over-privileged database accounts, a database port reachable outside the internal network, and backups without encryption or access control. Check that the XWiki database user holds only the privileges it needs, that the database listens only on internal addresses, and that backup copies are encrypted. Confirm with the vendor that your database engine version is still supported.

Search index storage

The search index is built from page content and must stay in step with changes, so it holds copies of protected information. Index files on disk or in a separate search service need the same access controls as the wiki itself. Check where the index is stored, who can read those files or reach the service, and whether restored backups rebuild the index. Before relying on search for access control, confirm with the vendor how your XWiki version applies permissions to search results.

Installed extensions and authentication

Extensions add macros, applications and authentication paths, and their code runs inside the XWiki server. Inventory every installed extension with its source, version and whether its maintainer still publishes fixes. If the xwiki-contrib OpenID Connect extension is used, check which identity provider it trusts, how it maps identities to XWiki users, and how sessions end. That extension can also make XWiki an identity provider, so confirm that this role is intended.

Which release line and hardening model fit your risk profile

This table compares the decisions that shape an XWiki hardening plan, with the typical fit and operational cost of each option. Read each row as a choice you make once and revisit at every upgrade, then match the option to your data sensitivity and the staff you can commit. Confirm current Docker tags before use: at research time the stable tag was 18.8.0, the LTS tag 17.10.14 and the intermediate LTS tag 18.4.7.

Decision	Option	When it fits	Operational cost
Release line	Stable line (for example tag 18.8.0 at research time)	Teams that can upgrade frequently and test extensions on each release	Frequent upgrade cycles and regression testing; security fixes arrive fastest
Release line	LTS line (for example tag 17.10.14 at research time)	Regulated teams that need long, predictable support windows and fewer major changes	Lower change frequency, but you must plan the move to a newer line before support ends
Release line	Intermediate LTS line (for example tag 18.4.7 at research time)	Teams wanting a middle path between stable churn and a long LTS cycle	Moderate upgrade cadence; confirm the line's support dates with XWiki before committing
Security release cadence	Apply security releases within a defined internal window	Internet-facing wikis or wikis holding sensitive customer or employee data	Standing staff time for triage, staging tests and change approval on each release
Security release cadence	Batch security releases into scheduled maintenance windows	Internal wikis with restricted network exposure and documented compensating controls	Lower disruption, but longer exposure between release and deployment
Guest access	Disable guest access entirely	Wikis holding confidential or regulated content	Requests for read access from outsiders need a manual account process
Guest access	Allow guest read on selected public spaces only	Public documentation mixed with internal content	Ongoing review of space rights so public spaces stay separate from internal ones
Scripting rights	Restrict scripting rights to a small named group	Most organizations, where script-capable pages are a sensitive permission	Admins must review and approve every script-capable change
Scripting rights	Delegate scripting rights to power users in defined spaces	Large teams with mature development practices and code review	Higher audit load and more reviews of script content across spaces
TLS and authentication termination	Terminate TLS and SSO at a reverse proxy or identity gateway in front of Tomcat	Standard enterprise setups with a central gateway and certificate management	Proxy configuration, header trust settings and certificate renewal to maintain
TLS and authentication termination	Terminate TLS inside the servlet container	Single-host deployments with few other services to front	Certificate and cipher changes handled per application server
Extensions	Allow only extensions on a vetted list, each with a recorded owner	Regulated or high-exposure wikis	Review effort for each new extension and each upgrade of an allowed extension
Extensions	Allow extensions on request with case-by-case review	Smaller teams with low risk tolerance for change but fewer approval steps	Review load is unpredictable and extension sprawl becomes harder to audit

How to harden a self-hosted XWiki step by step

This sequence takes a self-hosted XWiki from its default state to a configuration you can defend in a review. Each step names what changes and the check that proves it, so the sequence doubles as an acceptance test for your administrators. Work through the steps in order, because later steps assume the version and access baseline set earlier.

Record the running version and release line
The platform owner records the exact XWiki version in use and whether it is on the stable, LTS or intermediate LTS line. Compare that against the image tag or WAR version in your deployment manifest, because a mismatch means someone changed the running system outside the pipeline. Also record the Java, Tomcat and database versions, since security fixes can depend on them. Done when the version in the administration screen, the deployment record and the line you intend to stay on all agree and are written in the change log.
Confirm how security fixes reach your instance
Name one owner for security notices from the XWiki project and one approver for each fix. Agree in writing how a fix moves from notice to a staging copy of the wiki, then to production. Confirm that staging uses the same release line, extension set and database type as production, so the test means something. Ask your internal team or support provider to state the response they will give to critical notices, and record that as a commitment you can hold them to. Done when a tabletop run of one illustrative notice moves through the named steps and the approver signs a dated record.
Restrict guest and anonymous access at wiki level
Review the global rights granted to guests and anonymous users in the administration section, and remove view, edit, comment and similar rights from any space that holds internal content. Decide which spaces, if any, should be public, and set each exception explicitly and keep a list of them. Confirm that self-registration is disabled unless a documented decision says otherwise. Check: open a private browser session, request a protected page and an edit URL, and confirm each returns a login prompt or a denied message. Repeat with a page you have marked public so you know the test can tell the two apart.
Limit script and programming rights to named administrators
Identify every account and group that holds programming or script rights, since these allow a page to run server-side code. Remove them from all groups except a short, named list, and tie each entry to a documented business reason. Review nested groups and space-level grants, because a group granted rights on a broad space can pass them to people who never received them directly. Check: sign in as a standard editor without script rights, try to save a page containing a script macro, and confirm the save is refused. Then confirm that an approved administrator can still save it, so the restriction does not stop legitimate work.
Lock down the Tomcat connector behind a reverse proxy
Place a reverse proxy in front of XWiki and make it the only route from user networks. Bind the Tomcat connector to an internal interface or restrict it at the firewall so clients cannot reach the application server directly. Configure forwarded address and protocol handling in both the proxy and the servlet container, so XWiki sees the correct client scheme and address. Enforce TLS at the proxy, add the security response headers you have agreed on, and remove default connectors and error pages that reveal server details. Check: from a host outside the proxy network, connect to the Tomcat port and confirm it fails, then fetch a page through the proxy and review the response headers.
Restrict database accounts to minimum privileges
Create a separate runtime account for XWiki with only the data privileges the application needs. Use a different account for schema changes during installation and upgrades, and remove administrative privileges from the runtime account. Restrict network access to the database host so only the application server can connect. Store credentials in a secrets store or a protected configuration file with restricted file permissions, and keep them out of wiki pages and version control. Check: sign in with the runtime account, attempt a schema change or a privilege grant, and confirm the database refuses it. Then confirm that an ordinary page save still succeeds.
Disable unused extensions after a documented review
Export the list of installed extensions and record the owner and business purpose of each one. Disable extensions that nobody uses first, and confirm no remaining feature depends on them before you remove them from the image or extension store. For third-party and contrib extensions, review the source, the maintainer's recent activity and the license, and confirm a version exists for your release line. Check: after disabling, load the core pages and the features each remaining extension supports, then confirm the extension inventory matches the list the approver signed off.
Enable logging and confirm security events are captured
Turn on access and error logging for the servlet container and the application, and forward logs to a central store that wiki administrators cannot silently edit. Decide which events you must be able to answer questions about later, such as failed logins, rights changes and administrator actions, and confirm the wiki records them at that level. Agree a retention period with your policy and legal owners and apply it to the central store. Check: trigger one failed login and one rights change in staging, then find both entries in the central store with the user, time and source address.

Controls to set for guest access, scripting and secrets

Most XWiki compromises start with rights that were left at their defaults: a guest who can edit, a group that can run scripts, or a database password sitting in a page. The controls below work together, so each should be set, tested and recorded before the wiki is opened to users.

Wiki-level guest rights

Decide whether anonymous visitors can view, comment or edit at the wiki level, and remove edit rights for guests unless the business has a documented reason. Check the guest rights on every space, because a space-level grant can override a wiki-level restriction. Test the result by browsing the wiki while logged out.

Scripting and programming rights

Limit script and programming rights to a small group of trusted administrators, since these rights allow wiki pages to execute server-side code. Review which users and groups hold them, including any inherited through groups. Record who may grant these rights and require a review when someone asks for them.

Edit rights on administrative spaces

Restrict edit rights on administrative and configuration spaces to named administrators, and keep general contributors out of them. Broad edit rights on these spaces let a normal user change settings or inject content that other users trust. Verify the restriction with a non-admin test account.

Database and servlet credentials

Keep database and servlet container credentials out of wiki pages, attachments and version control. Store them in the deployment's secret mechanism or an environment-specific configuration file with restricted file permissions. Confirm that backups and exported configuration files do not expose them in plain text.

TLS-only access

Serve XWiki only over HTTPS, redirect plain HTTP, and make sure the reverse proxy and the servlet container agree on the external address. Check that login forms, session cookies and attachments are never delivered over an unencrypted connection. Confirm the certificate chain and renewal process with the team that owns the proxy.

Session and cookie settings

Review session timeout, cookie flags and proxy headers, since these settings are often split between the proxy and the servlet container. Confirm that session cookies are marked secure and restricted to HTTPS, and that forwarded headers are trusted only from the proxy. Test logout and session expiry on a real browser.

Admin account protection

Limit the number of administrator accounts, give each administrator a named account, and require strong authentication for administrative logins. Keep a documented break-glass procedure for the rare case when the identity provider is unavailable. Review the administrator list on a fixed schedule and after staff changes.

Auditing installed extensions

Inventory every installed extension with its version, then check where each one came from and whether it is still maintained. Compare each installed version with the version the target XWiki release expects, and decide to keep, update or remove it before the upgrade. Remove unused extensions, since each one adds code that must be patched.

What makes XWiki hardening take longer or cost more

This table lists the factors that lengthen or raise the cost of hardening a self-hosted XWiki, with a way to reduce each one. Read the first column as the variable you control and the last column as the lever to pull before work starts. The main takeaway is that scripting rights, extension count and environment count usually decide the effort more than the base installation does.

Driver or cost item	Why it changes effort or cost	How to keep it down
Wikis, spaces and pages with custom scripting or macros	Each script or macro needs review for rights, input handling and injection paths, and broad scripting rights widen that review.	Limit script rights to a small named group and inventory scripted pages before the review starts.
Count and age of installed extensions	Each extension adds code and dependencies, and older ones often lag behind the current release line.	Remove unused extensions, pin versions and run a periodic extension audit against release notes.
Integrations such as identity providers and connectors	Each connection adds configuration, secrets and trust boundaries, such as SSO attribute mapping and group sync.	Document each integration once, assign one owner to each and map directory groups to XWiki groups.
Database and servlet container topology	Replicated or clustered setups add review points at each node and each replication link.	Standardize one database and container build, then manage its configuration from a single template.
Reverse proxy and network path	Proxy header handling, TLS settings and internal routing each need testing, and misconfiguration can weaken login and rights checks.	Keep proxy configuration in version control and test header handling after every change.
Number of environments (test, staging, production)	Each environment needs the same controls, so configuration drift creates extra checks and extra evidence to collect.	Build all environments from one code path and compare configuration automatically.
Upgrade frequency and release line choice	Each security release triggers patch testing, and the effort repeats for as long as the wiki runs.	Choose a release line your team can keep current and rehearse upgrades on a copy of production data.
Compliance evidence requirements	Assessors may ask for dated configuration exports, scan results and change records, which take time to collect each cycle.	Automate configuration exports and scan reports, and agree the evidence list in writing before work starts.
One-time: initial review and remediation	Initial review, rights cleanup and fixing findings are paid once, but their size follows the drivers above. XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise plans.	Ask for findings grouped by severity and a quote built from written scope, with review and remediation priced separately.

How to test that XWiki hardening holds and fails safely

Hardening only counts if you can show it still holds after each change. Build a verification pass that tests each control from the outside, the way an unauthenticated visitor or a low-privilege user would meet it, and from the inside, where administrators and the database account operate. Record each test, its expected result and the actual result, so the same pass can run again after every security release, extension change or configuration update. Start with access. Use a browser session with no login and attempt to read and edit pages in restricted spaces. Each attempt should be refused. Then create two test accounts, one with script rights and one without. The account without script rights should not be able to save a page containing a script macro or run one that another user has placed. Finally, connect to the database with the account XWiki uses at runtime and attempt administrative statements, such as creating users or altering schema. Confirm with your database administrator that the account is refused for anything the application does not need.

Next, check the edge and the runtime. Request pages through the reverse proxy and compare the response headers and cookie attributes with your written proxy policy, including whether session cookies carry the secure and HTTP-only flags. Then try to reach the servlet container's port directly, bypassing the proxy. That path should be closed at the network level. For extensions, disable one that is installed, restart as your change process requires, and confirm that its macros and interface elements no longer render and that its files are not served. Re-enable it only through your normal change record. Logging is the control most often assumed rather than tested. Generate a set of failed logins and a rights change in the test environment, then confirm that each event appears in the log destination your security team reads and that it reaches your central collector. Confirm the exact log locations and event formats with the XWiki version you run, because they differ between configurations. An event that is not logged cannot be investigated later.

The fail-safe check tests what happens when things go wrong. Restore a recent backup into an isolated test environment that has no route to production users or systems. Confirm that rights survive the restore: group membership, space and page restrictions, guest access limits and script rights should match the source. Also confirm that disabled extensions stay disabled and that the restored instance does not open broader access than production. A restore that quietly widens permissions is a security incident in its own right, so treat any difference as a failed test and investigate before the backup process is accepted. Finally, have an independent party test the running instance. An authorized security test against a test or production copy should have its scope, rules of engagement, testing windows, data handling and escalation contacts agreed in writing before work begins. DeployOpen provides security testing for applications and infrastructure inside the client's environment, and the results feed your remediation plan. The test does not replace the internal checks above. Independent auditors and certification bodies, not DeployOpen, decide whether your evidence meets any framework you are assessed against.

What to monitor, back up and document after go-live

Hardening an XWiki instance is only the starting state. The controls below keep it true over time: advisories are read, patches are applied on a schedule, rights are reviewed, logs are watched, and backups are proven restorable. Together they also produce the records an internal or external reviewer will ask to see.

Track advisories for your chosen line

Subscribe to XWiki security advisories and release notes for the line you run, whether stable, LTS or intermediate LTS, and record who reads them. Map each advisory to your version and the extensions you run, since a core fix may not cover a vulnerable extension. Note the date each advisory arrived so you can show how quickly you responded.

Schedule patch windows and test upgrades

Set a recurring patch window and rehearse every security release on a staging copy built from production data and the same database and servlet container. Confirm extension compatibility before the window opens, and keep a rollback path for the database and the WAR or image tag. Record the outcome of each test upgrade.

Review rights and administrator membership

Review global administrators, wiki administrators, and groups granted script or programming rights on a fixed cadence agreed with your security owner. Compare the lists against your identity provider and remove accounts for leavers and temporary grants. Keep each review's date, reviewer and changes so the history can be audited.

Monitor Tomcat and database logs

Forward Tomcat access and error logs and database logs to a central location and alert on repeated authentication failures, unexpected administrative actions and server errors. Confirm log retention matches your policy and that log files cannot be altered by the application account. Review alert thresholds after the first month of real traffic.

Back up the database and attachments

Back up the XWiki database and the attachment store together, on a schedule that keeps their timestamps consistent. Store copies outside the application host and encrypt them. Confirm the attachment storage location with your platform team, because attachments are not covered by a database dump alone.

Test restores on a fixed schedule

A backup is only proven when a restore completes on a separate environment and the wiki starts, lists pages and opens attachments. Run restore tests on a set cadence, record the time taken and any manual steps, and fix gaps in the runbook. Ask your partner or internal team to state in writing what a restore test covers.

Maintain the extension register

List every installed extension with its version, source, business owner, technical owner and last review date. Check each entry against upgrade notes and advisories, and flag extensions that are unmaintained or no longer compatible with your XWiki line. Remove extensions nobody owns.

Document the baseline, exceptions and evidence

Maintain three records: the hardening baseline describing each applied setting, an exception register listing each deviation with its reason, owner and expiry date, and an evidence index that states where logs, review records, test results and backup reports are stored. Keep them in a location both your team and an assessor can reach.

Common questions about hardening a self-hosted XWiki

How much does hardening a self-hosted XWiki cost, and what drives it?

The cost follows the written scope, and DeployOpen gives a quote once that scope is agreed. DeployOpen does not publish a price list. The main drivers are the number of XWiki instances, the servlet container and database in use, how many extensions need review, how complex the rights model is, and whether SSO, backups and reverse proxy configuration are included.

Some work is one-time, such as the initial review and baseline configuration. Patch cadence, extension re-review after upgrades and periodic checks recur, and a retainer can cover them. For reference only, XWiki SAS lists consulting at 1200 EUR per day on its pricing page. That rate applies to XWiki SAS consulting and requires a Business or Enterprise support plan. Ask for line items for each activity, the effort assumptions behind them, and a clear list of exclusions.

How long does an XWiki security hardening review take?

No duration is fixed in advance. The length of a review depends on how many XWiki instances are in scope, how many extensions and custom scripts are installed, how large and layered the rights model is, and how quickly your team can provide access and documents. Environment factors matter as well, including whether a staging environment exists for testing changes and whether change windows limit when settings can be applied.

A single instance with a short extension list moves much faster than a multi-instance estate with custom macros. The timeline should appear in the written scope along with its start conditions and the points where your team's responses are needed. Ask which milestones carry dates and which depend on your input, and confirm both in writing before work starts.

What must our team provide before an XWiki hardening review starts?

Four inputs unblock most reviews:

Administrator access to the wiki and the servlet container, or a supervised session with an admin account.
The full extension list with installed versions.
An architecture diagram showing the reverse proxy, servlet container, database, network zones and identity provider.
A rights export covering global and space-level rights, groups, and any allow or deny rules.

Access to logs and backup configuration helps as well. Access should be scoped and recorded, and credentials should be rotated after the engagement ends. Ask the partner to confirm how secrets are handled and where the work is performed before you share anything.

Can our internal team harden XWiki without an outside partner?

Yes, an internal team can harden XWiki alone if it has people who understand the servlet container, the database, reverse proxy configuration and XWiki's rights model. The work is methodical: choose a supported release line, apply security releases, restrict guest and scripting rights, review extensions, lock down the container and database, and keep evidence of each change.

The usual gaps are time and independent review. Security releases arrive on the vendor's schedule, so someone must own that cadence every month. An outside reviewer can check configuration and rights with fresh eyes. Many teams split the work: they own routine patching and the outside reviewer checks the baseline and the rights design. Write that split into the scope so responsibilities are clear from the start.

Should we run XWiki stable or LTS for security reasons?

For most organizations with security obligations, the LTS line is the more predictable choice because it is intended for longer support, but confirm current support terms and end dates with XWiki SAS. At the time of research, the official Docker image tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS.

Stable releases carry newer features and fixes, which helps when you need the latest protections, but each one requires an upgrade sooner. LTS releases reduce upgrade frequency and suit a planned patch cycle. Decide based on your patch capacity, how well your extensions track each line, and how quickly you can absorb a major upgrade. Confirm the security release process with XWiki before you commit to a line.

Does DeployOpen issue security certifications for our XWiki?

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that work. DeployOpen can plan, implement and document hardening, and it can prepare systems, controls and evidence for an assessor to review. Evidence may include configuration records, rights exports, change logs and extension review records.

Whether that evidence meets a specific framework depends on the assessor and the scope of the assessment, so raise the requirements with them early. Separately, XWiki SAS states that its XWiki Cloud hosting runs on ISO 27001 certified infrastructure. That statement covers XWiki's hosted service, which is separate from a self-hosted instance in your own environment.

How do we audit installed XWiki extensions for security risks?

Start with an inventory of every installed extension, including its version, source and owner, then remove the ones the wiki does not use. Compare each version against the XWiki release it targets and check whether the project still has an active maintainer and recent fixes. Community projects in the xwiki-contrib organization vary in maintenance status, so review each one individually.

Give the most attention to extensions that run scripts, call external services or change authentication, because they carry the most risk. Limit scripting rights to people who need them, and test any extension that needs elevated rights in staging before production. Record each decision so the next upgrade starts from a known, reviewed list.

How DeployOpen scopes, hardens and hands over XWiki security work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including XWiki. For security hardening, we agree a written scope first, apply changes in your environment, test them, and hand over documented configuration and runbooks your team can operate.

How we scope

Inventory your XWiki version, flavor (stable or LTS), database and Tomcat setup before agreeing any changes
Record which guest access, scripting rights and extension installs are in use today
Agree in writing which hardening items, environments and deliverables are included in the fixed scope
Confirm who on your side approves changes, maintenance windows and access to staging

How we build

Apply the XWiki line and security releases your scope requires, tested first in a staging copy
Restrict guest access and scripting rights based on the permission model your wiki actually needs
Harden the servlet container and database configuration, including network exposure and service accounts
Review installed extensions against their source, version and maintenance status, then test changes before production

How we hand over

Deliver a documented record of each configuration change, its reason and how to verify it
Provide test evidence from staging and production checks against the agreed scope
Write runbooks for applying future XWiki security releases and rolling back a failed update
Walk your operations and security staff through the configuration and the handover documents

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Ask whether a retainer covers new XWiki security releases, extension reviews and periodic configuration checks
Confirm response expectations and out-of-scope items in the written agreement before work starts
Compliance readiness work produces evidence for independent auditors, who issue any assessment or certification