Why an EU data sovereignty intranet is a different build
An EU organization that wants its intranet, staff profiles and internal posts kept under EU jurisdiction has two workable routes: self-host the platform in infrastructure you control inside the EU, or use an EU-hosted option from the platform vendor. Either way, sovereignty is decided by every access path, not only by where the database sits. Support sessions, administrator logins, backups, log shipping, vendor telemetry and add-on connectors can each move personal data out of the EU, and EDPB Guidelines 05/2021 treat remote access from a third country, even display-only access for support, as a transfer. Map those paths before you pick a host.
The intranet is a wider data scope than a file store. It holds staff profiles with names, roles, locations and photos, status updates and comments that reveal personal views, HR-adjacent pages such as onboarding, leave policies or disciplinary guidance, and audit logs that record who read what. Under GDPR, each of these categories needs a lawful basis, retention rules and a clear answer to who can see them. Settle the data inventory and the access model before comparing platforms, because a profile field or an activity feed that seems harmless can carry more personal data than the file share it replaces.
On platforms, HumHub is built for social posting, spaces and news, XWiki is built for structured knowledge and policy pages with fine-grained rights, and Nextcloud combines files, talk and a light intranet role. None is sovereign by default, and the right choice depends on the work the intranet must do: a social stream with profiles, a governed policy library, or a file-centred portal. Ask each candidate partner to show which features, connectors and support channels would run outside your environment, and confirm those points against each product's current documentation and licence terms before you commit.
Which GDPR and sovereignty requirements shape the intranet build
This table maps the GDPR and transfer rules that apply when employee communications and profiles sit on a platform that a non-EU party can reach. Read each row as a question to answer before choosing hosting, support access and vendor contracts, because the build decisions follow from the answers.
| Requirement | Source | What it means for the build |
|---|---|---|
| Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions | GDPR Article 44 | Map where profiles, posts, files and logs are stored and who can reach them, including subprocessors, before choosing a host. |
| Infringements of Articles 44 to 49 can lead to fines of up to EUR 20 million or 4% of worldwide annual turnover | GDPR Article 83(5)(c) | Treat transfer decisions as board-level risk and document the assessment behind each hosting and support choice. |
| Remote access from a third country, even only viewing data on a screen for support, counts as a transfer | EDPB Guidelines 05/2021 (version 2.0) | Restrict vendor and integrator support sessions to EU staff or record a documented transfer basis, and control privileged access to the intranet database. |
| Storage in a cloud outside the EEA is a transfer | EDPB Guidelines 05/2021 (version 2.0) | Confirm the region of backups, snapshots, search indexes and log storage, not only the primary database. |
| A third-country authority request for data would itself be a transfer, so exposure to such laws must be assessed before engaging an EU processor | EDPB Guidelines 05/2021, Example 12 | Ask any hosting provider which foreign laws could compel access to intranet data and what their process is for handling such requests. |
| Third-country court judgments are enforceable only under an international agreement in force with the Union or a Member State | GDPR Article 48 | Expect disclosure requests to route through legal channels; keep an internal contact and a documented escalation path. |
| Privacy Shield was invalidated while standard contractual clauses were upheld | CJEU Case C-311/18 (Schrems II), 16 July 2020 | Standard contractual clauses remain a transfer tool, but they require a transfer impact assessment, not only a signed template. |
| The EU-US Data Privacy Framework adequacy decision applies only to US organizations on the DPF list, and an appeal in Case C-703/25 P is pending | Commission Implementing Decision (EU) 2023/1795; Official Journal C/2025/6610 | Do not rely on a US provider's DPF listing alone. Check whether the provider is listed, monitor the appeal, and keep a fallback transfer mechanism in the contract. |
| Where a cloud provider needs data in the clear and foreign authority powers exceed what is necessary and proportionate, no effective technical supplementary measure has been identified | EDPB Recommendations 01/2020 (version 2.0) | Where a US-controlled provider must read profiles or messages, self-hosting in EU infrastructure with EU-controlled operators is the simpler route to defend. |
| US providers subject to 18 U.S.C. 2713 must preserve or disclose data they control, wherever it is located | 18 U.S.C. 2713 (CLOUD Act) | Even EU-located data held by a US-controlled provider may be reachable, so assess the provider's control, not only its data center location. |
Where employee data moves inside an intranet
Every intranet holds more employee data than its profile pages suggest. Profiles and directory attributes (name, department, manager, phone, photo) are copied from the directory into the intranet at login or sync. Private messages, posts, comments, file attachments, audit logs and backups are created by the platform itself, and each of these copies lives somewhere. Before you decide what stays in the EU, list each data class for HumHub or XWiki, record where it is stored, and record who can read it from outside your network. Vendor support sessions are the category most often left off this list. A support engineer who views a screen from a third country performs a transfer, even if no file leaves the environment.
Most leakage happens at the edges of the platform, not in the database. Check the browser-facing assets first: CDN-hosted fonts, script libraries, avatars or embedded videos loaded from external domains reveal every employee's IP address to the CDN operator on each page view. Email relays for notifications, SSO identity providers that sit outside the EU, push notification services for mobile apps and any SaaS control plane that receives license, telemetry or update data are the other common exits. Confirm with the vendor and in your own environment which of these calls are made by default, which can be disabled by configuration, and which require a self-hosted replacement such as a local font package or an internal SMTP relay.
Remote access from a third country is a transfer even when nothing is downloaded. EDPB Guidelines 05/2021 state that displaying data on a screen for support or administration from outside the EEA counts as a transfer under Chapter V of the GDPR. For an intranet this covers helpdesk staff, implementation partners and vendor engineers who troubleshoot the database or view private spaces. Decide who may open administrative sessions, from which locations, through which jump host, and whether those sessions are logged. Write these rules into the support contract before work starts, so that access from outside the EU is either excluded or documented as a transfer with its own safeguards.
Self-hosting in EU infrastructure or using an EU SaaS option
Self-hosting in your own EU data center keeps operation, administration and storage under your control. Your platform team installs, patches and upgrades the application, database and web tier. Personal data stays within the EEA only if every copy, including backups and remote support sessions, stays there too. The EDPB's Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen, as a transfer, so support arrangements matter as much as storage.
- Operator: Your staff or a contracted operations team run the stack. An implementation partner can build and document it, but day-to-day operation remains with you unless you contract ongoing support separately.
- Administrator access: Limit root and database credentials to named staff, log privileged sessions and keep a register of who can reach profile data. Vendor support access should be time-boxed and approved case by case.
- Backups: Keep snapshots and off-site copies in EU locations you name in your records of processing. Confirm that any managed backup provider cannot read encryption keys from outside the EEA.
- Hardware and facility providers: Colocation, managed hardware and remote hands staff may reach the servers. List them as sub-processors where they touch personal data.
- Contract: For every hosting or support provider, require a sub-processor list with locations, advance notice of changes, and a documented process for handling third-country authority requests.
Before approving the data map, check who can physically and remotely reach the hosts, including hardware vendors and backup services.
Running HumHub or XWiki in an EU region of a cloud account you own moves facility management to the cloud provider while you keep the application layer, identity settings and encryption choices. The question shifts from who racks the servers to who can compel the provider and who holds the keys. EDPB Example 12 says that using an EU processor subject to third-country law with extraterritorial effect does not by itself count as a transfer, but complying with a third-country authority request would be one, so the exposure must be assessed before you engage the provider.
- Operator: You or your partner manage the virtual machines, containers, databases and application. The cloud provider operates the physical layer under its shared responsibility terms.
- Region and provider law: Confirm the region for compute, storage, logs and backups, and whether the provider or its parent is subject to non-EU law. Under 18 U.S.C. 2713, US providers must preserve or disclose data in their possession, custody or control regardless of where it is stored, so ask for the provider's written process for such requests.
- Key management: Use customer-managed keys held in an EU key service you control, and confirm where key material is generated and stored.
- Provider support access: Ask which provider staff can see customer data during incidents, from which countries, and under what logging.
- Contract: Require sub-processor disclosure, notice before changes, audit or evidence rights, and standard contractual clauses for any residual transfer.
Sign off only after you have the provider's written answer on law, keys and support access.
HumHub's EU SaaS hosting option moves operation to the vendor, so your governance depends on contract terms and written confirmations rather than your own servers. Your employees still produce personal data in profiles, posts and messages, and your organization remains the controller. Before procurement, confirm the details below with HumHub directly. This page does not state hosting region specifics, so treat every location claim as unverified until the vendor confirms it in writing.
- Operator: Ask who runs the platform, which legal entity contracts with you, and whether any subcontractor operates infrastructure or support tooling.
- Hosting region and backups: Get the data center locations for production, staging and backups in writing, including any replicas outside the EEA.
- Vendor and support access: Ask which HumHub staff can access tenant data, from which countries, for what purposes, and how access is logged and approved by you.
- Sub-processors and transfers: Require a current sub-processor list with locations, advance notice of changes, and standard contractual clauses for any residual transfer.
- Exit rights: Under the EU Data Act, switching rights apply to data processing services, with a maximum two-month notice period, a 30-day transition and a ban on switching charges from 12 January 2027. Confirm how export of content, profiles and attachments works in practice.
Request the answers in a single written statement and file it with your data protection impact assessment.
XWiki SAS offers XWiki Cloud hosting on infrastructure it describes as ISO 27001 certified, alongside on-premises support and migration services. This option suits organizations that want a vendor-operated XWiki with a defined security management standard, but the certification covers the infrastructure as described by the provider. DeployOpen does not issue certifications, so ask XWiki SAS for the current certificate, its scope statement and the auditing body, and confirm that the scope includes the services you will buy.
- Operator: XWiki SAS runs the cloud instance. Confirm whether the same team also provides support, backups and upgrades, and which parts are subcontracted.
- Certification scope: Check whether the ISO 27001 scope covers the data center, the application operation and the support processes, or only part of them.
- Admin and support access: Ask which XWiki SAS staff and subcontractors can open tenant content, from which countries, and how those sessions are recorded and approved.
- Backup location: Get the backup regions and retention periods in writing, and confirm that restores stay within the same jurisdiction.
- Contract and exit: Require sub-processor disclosure and third-country request handling in the contract. XWiki Standard is the free open source version, so ask how a move back to self-hosting would work and what it would cost. The XWiki pricing page lists Starter, Basic, Business and Enterprise tiers, and cloud and on-premises pricing are stated to be the same.
Confirm the certificate scope and the support access list before you compare this option with the self-hosted choices.
Which intranet platforms fit EU sovereignty requirements
Sovereignty requirements usually come down to where employee data is stored, who can reach it from outside the EU, and which directory signs people in. The platforms below fit different answers to those questions, and the choice of chat and mail components is a separate decision that sits alongside the intranet.
HumHub for self-hosted social intranet
HumHub suits organizations that want a social intranet with spaces, news and profiles running in their own EU data centers. Self-hosting keeps profile data, posts and attachments under the controller's contracts and jurisdiction. Before committing, confirm which edition provides LDAP and SAML single sign-on, since those features determine whether the directory stays the source of identity. HumHub also offers an EU SaaS hosting option, which shifts operations to the vendor and needs its own processor review.
XWiki for knowledge-heavy intranets
XWiki is licensed under the LGPL 2.1 and fits policy libraries, procedures and structured internal knowledge. Official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB, which lets your team reuse the database platform it already operates in its own EU infrastructure. XWiki SAS offers XWiki Cloud hosted on ISO 27001 certified infrastructure, so confirm the hosting location and sub-processors in writing. Directory single sign-on for Active Directory and Azure Active Directory is listed under XWiki Pro, so verify it against your identity setup.
Nextcloud when files and profiles must sit together
Nextcloud Server is licensed under AGPL-3.0 and combines file sharing, collaboration and user profiles on one self-hosted platform. It suits organizations where employees work mainly in shared files and the intranet must keep documents and people data in one controlled environment. Confirm which parts of the platform your team will expose to employees, and review the applicable Nextcloud release cadence before setting an upgrade plan. The current server release referenced in our research is v33.0.10, published October 15, 2026.
Chat and mail are separate decisions
An intranet rarely covers messaging or email on its own, and those components carry their own data flows. Team chat on Mattermost, Rocket.Chat or Matrix, and mail on Stalwart or mailcow, each need their own hosting location, retention rules and access review. Check that each one keeps message content and metadata inside the same EU boundary as the intranet. Treat them as separate components in your data processing records and vendor reviews, even when a single team operates them.
How the EU sovereign intranet rollout runs in phases
The sequence maps where employee data flows and who can reach it before any platform is configured, so each later decision traces back to a documented transfer and access position. Works council and DPIA input arrives early, while changes are still cheap to make.
Map employee data and transfers
Inventory every category of employee data the intranet will hold: profile fields, directory attributes, login and audit logs, posts, uploads, and messages. For each category, record where it is stored, which entities and processors touch it, and every location from which support staff could view it, including remote sessions from outside the EEA. The output is a records register and a transfer inventory, reviewed by the privacy lead and the hosting provider. The step is done when every flow has a named storage location, a named processor, and a yes or no answer on third-country access, with the evidence for each answer attached.
Prepare works council and DPIA input
Draft the data protection impact assessment and a works council briefing that describe the purposes, the data categories, the retention periods the business sets, and the monitoring features that will be switched on or off, such as read receipts, activity feeds and profile visibility. Ask the works council which of these it expects to co-determine and which it wants to see tested in the pilot. The output is a DPIA draft, a list of monitoring features with their default settings, and a written list of open questions. The step is complete when the council has confirmed the scope of its review in writing and the open questions have an owner.
Design hosting and privileged access
Choose the hosting location, whether your own data center, an EU cloud account, or a hosted offering from the platform vendor, and confirm in writing where backups, logs and search indexes live. Define the access matrix: who administers the servers, who can open support sessions, who can read content for moderation, and under which conditions a third-country processor could gain access. The output is a hosting diagram and an access matrix with each role, its permitted data, and the approval it needs. The step is done when the matrix has been signed off by security and legal, and the design answers the transfer questions from the first step.
Build the platform and directory integration
Install HumHub, XWiki or the chosen stack in the agreed environment, then connect it to the corporate directory for identity and group membership so that access follows existing roles. Configure logging so that administrative and content access events are recorded and retained as the DPIA specifies, and disable any external embeds, telemetry or push services that would send data outside the approved environment. The output is a configuration baseline and a build record listing versions, enabled modules, and directory mappings. The step is done when a test matrix confirms that each role sees only what the access matrix allows.
Migrate content and set access rules
Move existing intranet pages, files and wiki content in batches, mapping each source space to a target space with the owner, audience and classification agreed in the first step. Remove or archive content that falls outside the retention rules, and leave personal data in source systems where it has no business purpose on the intranet. The output is a migration log and a space register that names each space, its owner, its audience and its retention rule. The step is complete when sampled pages match their sources and every space has an owner who has accepted the access rules.
Run the pilot and works council review
Open the platform to a defined pilot group, chosen with the works council, and test the monitoring features, notifications, profile visibility and moderation workflows against the DPIA. Collect the pilot findings, record every change made in response, and give the works council the configuration it will be asked to approve. The output is a pilot report, a change log, and a works council decision or recorded objections. The step is done when the council has reviewed the final configuration and the DPIA has been updated to match what was tested.
Go live with a support access procedure
Launch the intranet to all employees with the approved configuration, the published privacy notice, and the moderation and retention rules in place. Before launch, write the support access procedure: how a vendor or partner engineer requests access, who approves it, how the session is logged, how it is time limited, and how the record is kept for review. The output is the live configuration, the signed support access procedure, and a log sample proving that a test access request was recorded. The step is done when the procedure has been tested end to end and the first access review date is set in the operating calendar.
Which controls reduce third-country exposure in practice
Does EU-only hosting and backup storage stop third-country transfers?
It removes the most common transfer path, but only if every copy of the data stays in the EEA. Storage in a cloud outside the EEA is a transfer under the EDPB's Guidelines 05/2021, so primary databases, file stores, search indexes, log pipelines and backups all need to be checked. Ask the provider for the exact regions and data centers for production, disaster recovery and backup copies, and for the names of any subcontracted storage services. Under Article 44 of the GDPR, onward transfers also fall under Chapter V, so the hosting contract should forbid moving data outside the EEA without your written approval. If you self-host in your own data center, the question shifts to which staff and vendors can reach that infrastructure, covered in the next item.
Who can reach production systems and their administrators?
Restricting privileged access to staff located in the EU limits the chance that a non-EU administrator views personal data in the clear. The EDPB's Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen, as a transfer, so an administrator working from abroad can create one even when the servers stay in Europe. Ask the provider where its administrators are located, whether follow-the-sun support is used, and whether access is granted through a named, time-limited and approved process. Confirm that the contract lists these conditions and that you can revoke access for a specific person or country. For self-hosted intranets, apply the same rule to your own service accounts and to any integrator working in your environment.
How should support sessions avoid exposing personal data to third countries?
Support should be able to diagnose faults without anyone outside the EU seeing employee records, messages or profiles. The practical controls are EU-based first-line support, screen sharing that is limited to EU sessions, sanitized logs and tickets, and test data in place of production content. Remote access from a third country that displays data counts as a transfer, so a support engineer in another country viewing a profile page is a transfer even without a download. Ask the vendor how remote sessions are recorded, whether support staff can open attachments or message content, and how they handle data included in support bundles. Confirm these rules in the support schedule, not only in a general policy document.
What should a sub-processor review and transfer assessment cover?
Every sub-processor that can access personal data is a potential transfer point, so the list must be complete and kept current. Ask for each sub-processor's name, location, service, and whether it has access to data in the clear. Under Article 83(5)(c), breaches of Articles 44 to 49 can lead to fines of up to EUR 20 million or 4% of worldwide annual turnover, so the assessment deserves written evidence. The EDPB's Guidelines 05/2021 say that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country request would be. Ask the provider to document that exposure and, where transfers do happen, which transfer tool applies. Standard contractual clauses under Commission Implementing Decision (EU) 2021/914 are one such tool, and the transfer impact assessment should be on file before go-live.
Who holds the encryption keys, and can a foreign authority force access?
Key custody decides whether the provider can read data in the clear, which matters most when a foreign authority issues a request. The EDPB's Recommendations 01/2020 state that where a provider needs data in the clear and the destination's public powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Ask who generates, stores and rotates keys, whether keys sit in an EU-hosted key management service or in a hardware security module you control, and whether the provider holds keys for your tenant. Also ask how the provider responds to government requests and whether it commits to challenge overbroad orders. Note that the US CLOUD Act provision at 18 U.S.C. 2713 applies to providers within its reach regardless of data location, so key custody must be checked against the provider's corporate ownership as well as its location.
Which admin actions must be logged, and where do the logs live?
Audit logs should record who changed configuration, exported data, granted access or read sensitive content, and these logs must stay under your control and inside the EU. Under 45 CFR 164.312(b), HIPAA requires audit controls that record and examine activity in systems holding ePHI, and similar expectations appear in many frameworks even when they do not name HIPAA. Confirm that the platform writes admin and access events to a log store you can query, that logs are retained for your required period, and that they are not shipped to a monitoring service outside the EEA unless that is agreed and assessed. Ask the provider whether it can give you the logs of its own staff's access to your tenant, and how long those logs are kept. Logs themselves contain personal data, so apply the same transfer review to them.
Evidence a data protection authority or auditor will ask for
This table maps each artifact a data protection authority, works council or external auditor is likely to request to its purpose and the platform component that produces it. Read it as a checklist to confirm before go-live, since most artifacts come from the platform audit log, exports or documents your team maintains rather than from the software alone. Attestations and certifications are issued by independent auditors, not by DeployOpen or the platform vendor.
| Artifact | Purpose and GDPR accountability link | Producing component or source |
|---|---|---|
| Records of processing (Article 30) | Shows purposes, categories of employee data, recipients and retention for the intranet, supporting the controller's accountability duty | Written by the controller and DPO, informed by the platform's data inventory of profile fields, spaces and modules |
| Transfer impact assessment | Documents whether any remote access, backup, log shipping or support session reaches a third country, and how Chapter V conditions are met | Controller assessment, using the hosting location record and the sub-processor list as inputs |
| Access logs | Demonstrates who viewed or changed employee profiles and restricted spaces, supporting security of processing and breach investigation | HumHub or XWiki audit and activity logs, forwarded to a central log store in the EU; confirm retention settings with your team |
| Sub-processor list | Lists every service that processes employee data, including support, email relay, backup and any EU SaaS hosting, so the controller can verify each engagement | Contracts and data processing agreements, mapped to each component in the deployment inventory |
| Hosting location record | Confirms data centers, regions and backup locations, which determines whether EU jurisdiction actually applies to the data | Infrastructure-as-code state, cloud account and region settings, and the hosting provider's documented locations |
| Works council agreement | Records co-determination consent for monitoring, profile fields, activity tracking and social features, where the national works council law requires it | Agreement drafted by HR and legal, with technical annexes produced from the platform configuration (enabled modules, visibility rules, log retention) |
| Deletion evidence | Shows that profiles, posts and logs are erased or anonymized after leaving or on request, supporting storage limitation and data subject rights | Platform user deletion and export functions, backup retention policy, and dated records from scheduled purge jobs |
| Data subject request records | Shows that access, rectification and export requests for employee profiles were answered within the deadline set in your procedure | Export of the user's profile and content from the platform, plus the ticket record kept in your helpdesk or ITSM tool |
What works councils expect from an employee intranet
Works councils and staff representatives will look first at purpose limitation: the intranet may process employee posts, profiles and activity only for the stated purposes, such as internal communication and collaboration. Put that purpose in writing and map each data category to it. Profile fields should be limited to what colleagues need to find and contact each other, and optional fields such as birthdays, private interests or photos should be opt-in. Ask who can see activity data. Most representatives will expect that individual activity logs, such as who viewed which page or who posted most, are visible only to a small administrator group for technical purposes, not to line managers or colleagues, and that any access to them is logged and limited to defined reasons.
Next, agree retention. Comments, likes and read receipts are personal data in most cases, so decide how long each is kept and when it is deleted or anonymized, and confirm that the platform's settings support those periods. Read receipts for mandatory notices are a common friction point: representatives often accept confirmation that a notice was delivered, but resist individual reading statistics used for performance assessment. Write down which features produce data about individuals, including any notification, reminder or read-tracking function, and confirm each one against your edition and version. The platform vendor's documentation is the starting point, but your own test instance is the evidence.
Finally, treat the written agreement as a prerequisite, not a formality. In many jurisdictions, introducing a system capable of monitoring employee behavior requires a works council agreement or a similar co-determination step before rollout, and the agreement should describe the features, roles, retention periods and the notice given to staff. Confirm with labor and data protection counsel in your country which rules apply, whether a works council must be consulted before go-live, and whether a data protection impact assessment is needed. Plan the agreement into the project timeline before the pilot, so that configuration choices are settled in the agreement rather than changed after employees are already posting.
What EU data sovereignty intranet projects cost and require
What drives the cost of a self-hosted EU intranet project?
The cost is driven by hosting, the edition you choose, directory integration, content migration and the internal effort around them. Hosting is paid to your own cloud, data center or provider, and it recurs. The software itself is often free under open-source licenses, but a supported edition is a subscription. Directory and single sign-on work, migration from an existing portal, theming and training are one-time project costs. Ongoing moderation, patching and upgrades recur. Ask any quote to split these lines, name who is paid for each, and state which items are fixed and which depend on content volume or user count.
How long does an EU data sovereignty intranet take to deploy?
The duration depends on scope, not on a standard timeline, so no figure applies to every project. The main variables are the number of audiences and spaces, how many sources feed the directory, how much legacy content must be migrated and reviewed, and how long the works council and data protection review takes. Consultation and approval often run in parallel with technical setup but can become the critical path. Ask for a written, scoped plan with milestones that name the review steps, and treat any duration without a scope as a starting assumption to test.
What does the organization need to provide for an intranet project?
The project needs named people, not only a budget. Typical roles include a data owner for each content area, a data protection officer who reviews the processing record and transfer analysis, a works council or employee representative body that is consulted on monitoring and profile fields, and internal administrators who will run the platform after go-live. Someone must also own the directory, decide who can post company-wide, and approve retention rules. Confirm these roles early, because decisions made late in the project usually cost more to reverse.
Can an internal IT team run an EU intranet without an implementation partner?
An internal team can deploy and run an intranet alone if it has the skills in Linux or container hosting, identity integration, database operations, web security and platform administration, and enough capacity to keep up with security updates. Many teams underestimate the work after go-live: patching, backup testing, upgrade planning, theme maintenance and user support. A partner can cover the parts that are one-time or specialized, such as hardening, directory integration and migration. Compare the skills you have against the list of tasks in the project scope, then decide which parts to keep in house and which to contract.
What do XWiki Pro and consulting rates mean for budgeting?
XWiki SAS publishes list rates that give a starting point for budgeting if you choose XWiki. It lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. XWiki Pro and support subscriptions come in Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users) tiers. XWiki SAS states that cloud and on-premises pricing is the same. Use these as list prices from the vendor, then confirm current terms, discounts, and what each support plan covers in writing before budgeting.
How does EU SaaS intranet hosting compare with self-hosting?
EU SaaS hosting shifts infrastructure, patching and availability to the vendor, while self-hosting keeps those tasks and the data inside your own environment. The comparison should focus on jurisdiction and control: where data is stored and administered, which entities can access it, how support access works, and whether the vendor's contract allows exit with data return. Self-hosting gives more control over these points but adds staffing and operating costs. Ask a SaaS vendor for its sub-processor list, its remote access policy and its contractual exit terms, and ask a self-hosting partner for the hosting and operations split in writing.
Which parts of an EU intranet project are one-time and which recur?
One-time work includes requirements, the transfer and risk assessment, directory and single sign-on setup, theming, content migration, the initial hardening review and staff training. Recurring work includes hosting, support subscriptions where you buy them, security patching, backup checks, upgrades, moderation of posts and spaces, access reviews and periodic reviews of the works council agreement. Budget both groups, and ask any quote to state which items recur, how often they are expected to happen and who performs them after handover.
How DeployOpen scopes and runs an EU sovereign intranet
This sequence turns an EU data sovereignty requirement into a written scope, a self-hosted HumHub or XWiki deployment inside your infrastructure, and an evidence pack your assessors can review. Each step ends with a named output so you know when it is complete.
Map data flows and jurisdiction exposure
DeployOpen works with your legal, privacy and IT leads to list every place employee communications, profiles, files and logs would be stored, processed or viewed. The team checks where support staff or vendors could access data from outside the EEA, since EDPB Guidelines 05/2021 treat remote viewing from a third country as a transfer. The output is a data flow register with hosting locations, administrator access paths and the third-country exposure your controllers need to assess before choosing a platform or hosting provider.
Choose the hosting model and platform
Together, you decide between self-hosting HumHub or XWiki in your own cloud account or data center, or using a hosting option from the platform vendor, and confirm where that vendor's operators can reach the data. DeployOpen documents the option that fits your sovereignty position and the edition you need for directory and SSO features. The output is a written architecture decision record that names the hosting location, the edition and the vendor's support and access model, with items to confirm listed where the vendor has not stated them.
Agree the fixed scope in writing
DeployOpen converts the requirements into a written scope covering systems, spaces, integrations, deliverables, responsibilities for your team and DeployOpen, and acceptance criteria. Both parties sign off before any build work starts, and the scope defines what is out of scope, such as content migration or theming if you do not need them. The output is a signed statement of work, and the quote is prepared from this document rather than estimated in advance.
Build and harden the environment
DeployOpen deploys the chosen platform, database and reverse proxy inside your infrastructure, configures encryption in transit for all employee traffic, sets up audit logging and restricts administrator access to named accounts. Hardening follows your security baseline and is tested before users arrive. The output is a configuration record and a test report showing that transport encryption and audit logs work as specified, which supports the technical measures your assessors will ask about.
Configure identity, access and spaces
The team connects the intranet to your directory, configures single sign-on, and builds the space and permission model that separates audiences, business units and restricted content. Your data owners approve the access matrix before go-live. The output is a tested access matrix and a log of directory connections, so you can show who can see which employee profiles and communications and how that access is granted and removed.
Document controls and prepare evidence
DeployOpen writes the operating documentation, including the data flow register, retention settings, backup and restore procedures, administrator runbooks and the records of processing inputs your privacy team needs. The evidence pack is organized by control so that your internal audit or external auditor can review it. DeployOpen prepares this material but does not issue audit reports or attestations, so the output is the documented evidence package, handed over for your assessors to review.
Support the works council and roll out
Before launch, your HR and works council representatives review the employee data categories, monitoring settings and moderation rules that DeployOpen configured, and DeployOpen supports the rollout with pilot groups and user guidance. Any change the council requests is logged in the scope as a documented change request. The output is a signed-off configuration baseline and a rollout record that shows which groups went live and which settings the council reviewed.
Hand over and support ongoing operations
DeployOpen hands over the environment with runbooks and training for your administrators, then continues under a support or retainer agreement if you choose one, covering upgrades, patches, backups and periodic testing. Retainer scope, response expectations and upgrade cadence are set in writing at this stage. The output is an accepted handover record and an operations calendar that keeps the evidence pack current as the platform changes.
