Why a knowledge base for EU data sovereignty starts with transfer risk
The decision turns on GDPR Chapter V exposure, not only on where the server sits. An EU organization whose wiki holds HR notes, customer escalations and named runbook owners is processing personal data, and a US-controlled SaaS vendor can expose that data in ways that a European data center does not remove. Under the EDPB's Guidelines 05/2021 (version 2.0), remote access from a third country is a transfer even when the person only views data on a screen for support, and storage in a cloud outside the EEA is a transfer too. The US CLOUD Act (18 U.S.C. 2713) reaches data in a provider's possession, custody or control wherever it is located. Before you sign, ask the vendor which entities can access tenant data, from where, and what support staff can see. Map every answer to a Chapter V transfer mechanism or to a documented decision not to transfer.
For most EU teams, the practical shortlist is short. XWiki fits structured, sovereign deployments: it can run on infrastructure you control, it is licensed under LGPL 2.1, and XWiki SAS offers cloud hosting, on-premises support and migration services from Confluence, so you can choose an EU-based support path. BookStack, licensed under MIT, suits simpler content with fewer permission layers and a lighter administration load. Outline is a capable editor, but its Business Source License 1.1 forbids offering a commercial Document Service, so have counsel confirm that your intended use of it, especially if you resell or host it for others, falls outside that restriction before you build on it.
Treat the platform choice and the hosting choice as separate decisions. Self-hosting in your own EU infrastructure removes the vendor's remote-access path, but only if your administrators, backup providers and any DeployOpen or other partner staff work under documented controls that keep personal data in the EEA. Confirm the processor chain, the sub-processors and whether any support tooling sends page content to a third country. Where a provider falls under a third-country law with extraterritorial reach, EDPB Recommendations 01/2020 point to a deeper assessment, so record that analysis in your transfer documentation.
Which requirements a sovereign wiki must meet and what each means for the build
This table maps each legal requirement that touches a self-hosted wiki to what it means for hosting location, administrator access, data export and contract terms. Read it row by row before choosing a hosting site or a support partner, because a single remote administrator session from outside the EEA can count as a transfer. The main takeaway is that sovereignty is decided by where data sits, who can reach it, and what the contract lets you take out.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| GDPR Article 44 and transfer definition | Any transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. EDPB Guidelines 05/2021 treat remote access from a third country, even display-only support sessions, and cloud storage outside the EEA as transfers. | Pin hosting and backups to EEA locations. Restrict vendor and support sessions to EEA-based staff or log and assess every remote view. Confirm backup replicas and log shipping stay in the EEA. |
| GDPR Article 48 and third-country disclosure orders | A foreign court or authority order to disclose personal data is recognized or enforced only if it rests on an international agreement in force with the Union or a Member State. | Ask hosting and support providers how they handle foreign government requests and whether they notify you. Keep encryption keys under your control where feasible and document the assessment before engaging a provider with foreign-law exposure. |
| US CLOUD Act reach (18 U.S.C. 2713) | US electronic communication and remote computing providers must preserve or disclose data in their possession, custody or control, wherever that data is located. | Using a US-parent provider can bring data under US reach even inside EU data centers. Confirm the corporate parent, the legal entity holding your contract, and which staff can access your environment. |
| Schrems II and Data Privacy Framework status | Schrems II invalidated Privacy Shield but kept standard contractual clauses valid. The Data Privacy Framework adequacy decision covers only US organizations on the DPF list, and the appeal in Case C-703/25 P is pending. | Do not rely on the DPF as a stable basis for transfers. Treat any US-linked vendor as requiring a transfer impact assessment, and monitor the appeal outcome. EDPB Recommendations 01/2020 say no effective technical measure exists where a provider must access data in the clear and foreign powers exceed necessity. |
| Data Act switching rights | Customers may switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027 (Articles 25, 29 and 50). | Write export formats, full page history and attachment export into the contract. Confirm which exit steps the provider must support and how long a transition takes in practice. Plan migration tooling for the exit path, not only the entry path. |
| Data Act Article 32 on third-country access to non-personal data | Providers must take technical, organizational and legal measures to prevent third-country governmental access to non-personal data held in the Union where this conflicts with Union or national law. | Non-personal content such as internal runbooks and process documents is covered too. Ask the provider for its written measures and whether they apply to your tenant or only to shared services. |
| Migration exit data from Confluence or Notion | Source platforms hold personal data in comments, user profiles, attachments and page history that may be copied to the new wiki. | Plan a pre-migration review of personal data in pages and attachments. Confirm which user, permission and history metadata the migration tooling carries across, since attachment history may not transfer. |
What personal data actually sits in wiki pages
Personal data in a wiki is rarely confined to a designated HR or people space. It sits in page bodies (names in meeting notes, customer contacts in runbooks, incident narratives that name the engineer on call), in comments and mentions, in attachments such as spreadsheets and exported tickets, and in page history, where earlier revisions keep text that was later edited out. User profiles, audit logs and the search index add further copies. Before you plan a transfer to EU-controlled hosting, inventory each of these locations, because the GDPR analysis applies to every copy you move, including the index and backups that are easy to forget.
The export from Confluence Cloud or Notion is itself a personal data set. It carries user identities, email addresses, group memberships and space or page permissions, which show who could read sensitive material and when that access was granted. Treat the permission model as data you must migrate accurately and minimize deliberately: decide which accounts are former staff or contractors who should not be imported as active users, and which group memberships are stale. The migration tooling you choose determines how much of this arrives intact. XWiki's Confluence Migrator Pro, for example, migrates users, groups and permissions along with pages and metadata, so the mapping to your directory needs to be checked before the first full run.
Attachment history needs an explicit decision. Confluence Migrator Pro keeps page history but not attachment history, so an earlier version of a contract, scan or spreadsheet may not reach the target wiki. Ask the vendor to confirm exactly what is dropped and whether the dropped versions are still held in the source. Then set a rule with your records and privacy owners: keep the current attachment only, archive old versions in a restricted location under a defined retention period, or delete them after the retention basis lapses. Document the choice, because an auditor or data subject request may later ask why an earlier version no longer exists in the wiki.
Which open-source wiki fits an EU sovereignty requirement
XWiki is licensed under the LGPL 2.1, which permits internal self-hosting, modification and commercial use without a separate license fee for the core software. The official Docker images are maintained by the XWiki Core Dev Team and come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. XWiki publishes a stable line (18.8.0 at the time of research) and a long term support line (17.10.14), so you can choose between faster feature updates and a slower upgrade cadence.
- License constraint: LGPL 2.1 has no field-of-use restriction for internal hosting, but you should confirm how extensions you add are licensed.
- EU support option: XWiki SAS, the company behind the project, offers XWiki Cloud on ISO 27001 certified infrastructure and on-premises professional support, with consulting and training billed by the day.
- Hosting choice: Self-hosting in your own EU data center keeps the wiki under your control, while XWiki Cloud is an option if the vendor's hosting location and contract terms meet your requirements.
- Structured content: Applications for structured data and business features are available in XWiki Pro, which is useful for policies, approvals and forms.
- Fit: Organizations that need structured content, fine-grained rights and a European vendor for support.
Confirm the hosting location, sub-processors and support terms in writing before you rely on XWiki Cloud for personal data.
BookStack is licensed under the MIT license, one of the most permissive open-source licenses, so you can host it internally, modify it and redistribute it with few obligations. Its content model is a simple hierarchy of shelves, books, chapters and pages, which many teams find easier to maintain than a structured application platform. The current release at the time of research was v26.09.1, published on September 29, 2026.
- License constraint: MIT imposes no hosting or field-of-use limits, so legal review is light compared with the other candidates.
- EU support option: The supplied research did not identify a dedicated EU vendor support subscription for BookStack, so confirm support with an implementation partner or a local service provider.
- Hosting choice: Run it on infrastructure you control in the EU, with a database and file storage that you back up on your own schedule.
- Simple structure: Good for documentation that is mostly pages with clear ownership, such as runbooks and procedures, but it offers less built-in structure for forms, approvals and typed data.
- Fit: Teams that want a lightweight internal wiki, a clear license position and a small operating footprint, with support handled by an implementation partner.
Check the page-level permission model and the audit features against your sovereignty and records requirements before you commit.
Outline is licensed under the Business Source License 1.1, not an open-source license in the usual sense. Its additional use grant forbids using the software to offer a commercial Document Service, which means a company that hosts Outline for paying customers may fall outside the grant. Internal use by an employer for its own staff is a different question, and it needs a written legal review before you deploy. The latest release at the time of research was 1.11.0, published on October 12, 2026.
- License constraint: The grant wording must be read against your exact use, including any external or customer-facing access and any managed hosting you purchase from a third party.
- EU support option: The supplied research did not identify an EU vendor support program for Outline, so confirm support options directly with the project or a partner.
- Hosting choice: Self-hosting keeps data in your EU infrastructure, but the license review should happen before the first production deployment.
- Editing experience: Outline is strong for fast, Markdown-friendly documentation, which suits engineering teams more than records-driven organizations.
- Fit: Internal engineering and product teams whose legal function has confirmed that internal self-hosting falls within the grant.
Ask legal counsel to confirm the license position in writing, and record that confirmation as part of your sovereignty and procurement file.
How to migrate from Confluence Cloud or Notion without moving data outside the EU
This sequence moves internal documentation from Confluence Cloud or Notion to EU-controlled hosting in a controlled way, with a data map, a tested migration, reconciled permissions and history, and a documented retirement of the source.
Inventory spaces and map personal data
Your team lists every Confluence space or Notion workspace, page count, attachment volume, owner, and who holds admin rights. Privacy and legal staff then review sample pages to flag personal data such as names, contact details, HR notes, customer identifiers, and credentials pasted into runbooks. The output is a data map that records each space, its data categories, its owners, and the processing purpose. Confirm with the vendor where the source tenant stores data and where its support staff may view it, because both count toward your transfer analysis under the GDPR.
Classify content and set retention rules
Using the data map, the business owners sort each space into categories such as public internal, restricted, personal data, and records that must be kept for a fixed period. Pages that are obsolete, duplicated, or unowned are marked for archive or deletion rather than migration. The output is a classification register with a retention decision per space and a list of pages to exclude. Ask your legal team to confirm which retention obligations apply to your sector, since the register determines what the target platform must preserve.
Define EU hosting and admin access model
Your architecture owner selects the target hosting location, the operator of the platform, and the admin accounts that can reach the data, including any support access from outside the EU. Vendor and implementation staff access is documented as a possible transfer, since remote viewing from a third country counts under the EDPB's guidance. The output is a transfer assessment file covering hosting, storage, backups, support access, and any sub-processors, with a decision on whether any third-country exposure remains. Confirm with the target vendor and your counsel whether any provider in the chain is subject to third-country law with extraterritorial effect.
Run a pilot migration on a copy
The team exports a copy of two or three representative spaces, including one with personal data and one with heavy attachments, and imports them into a non-production instance. XWiki's Confluence Migrator Pro moves spaces, pages, users, groups, permissions, attachments, and metadata, and keeps page history but not attachment history. Its trial is limited to 30 pages per migration, so a pilot of this kind needs either a licensed copy or a scripted approach agreed in advance. The output is a pilot log listing errors, skipped items, and manual fixes, which feeds the rules for the full run.
Reconcile permissions and page history
Your team compares source and target for every migrated space, checking page counts, attachment counts, user and group mappings, and inherited versus direct permissions. Attachment history loss is recorded explicitly, and any page that needs its full attachment trail is handled through a documented exception. Access reviewers confirm that restricted and personal-data spaces show the same readers as before. The output is a reconciliation report signed by the space owners, listing each discrepancy and its resolution. Ask the migration provider to show how it handles Notion databases and block-level content, which may not map one to one.
Cut over with DNS and link redirects
Operations staff run the final export and import during a freeze window agreed with space owners, then point the wiki hostname to the EU instance. Old Confluence or Notion URLs are redirected or documented in a link map, and bookmarks, integrations, and links from ticketing or monitoring tools are updated. Users are told where to find content and who to contact for access issues. The output is a cutover record with timestamps, the final reconciliation delta, and a list of links still pointing to the source, which the team tracks to closure.
Retire the source with a deletion record
After a parallel read-only period agreed with the business, the team deletes content from the source tenant, revokes integrations and API tokens, and asks the vendor to confirm deletion, including backups where the contract provides for it. Before deletion, a final export is archived in the EU under the retention rules from step two. The output is a deletion and export record covering what was removed, when, by whom, what the vendor confirmed in writing, and where the archived export is held. Keep this record with the transfer assessment file so that auditors and regulators can trace the full path of your data.
Where the wiki should run and how identity and backups stay in the EU
A wiki that moves out of Confluence Cloud or Notion for sovereignty reasons still leaks data if its hosting, identity, backups, search indexes, logs or vendor access sit outside the EU. The cards below cover each place personal data can leave the perimeter, and what to confirm with the platform vendor and the implementation partner before any content is migrated.
EU hosting location and operator control
Decide which legal entity and which data center operate the wiki, and whether your own team or an EU operator holds the administrator keys. The GDPR treats storage in a cloud outside the EEA as a transfer under EDPB Guidelines 05/2021, so the hosting location must be defined in writing. XWiki SAS offers XWiki Cloud on ISO 27001 certified infrastructure, but a self-hosted install on your own EU infrastructure keeps the operator question in your hands. Confirm the physical location of every database replica and object store, and which subprocessors touch them.
EU identity provider and SSO
Single sign-on decides who can authenticate, and the identity provider is often the most exposed component because it sees every login. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, so a Microsoft-based identity estate may point to Azure Active Directory, which is an operator and region question to answer before go-live. For a fully EU-operated stack, test an OIDC connection to an EU-hosted identity provider using the xwiki-contrib OIDC extension, and confirm with XWiki SAS whether that extension is supported in your version.
EU-located backups and key management
Backups copy every page, attachment and version, so a backup stored outside the EU carries the same transfer exposure as the live system. Confirm where snapshots, database dumps and attachment archives are written, who holds the encryption keys, and whether keys are stored in an EU key management service or in your own hardware security module. Keep the restore path inside the same jurisdiction, and test restores in that location, because a backup that can only be restored in a third country defeats the design.
Connector scope for Office and OnlyOffice
Office integrations often send document content to an external service, which can create an unplanned transfer. XWiki Pro lists Google Apps, Office365 and OnlyOffice connectors, and each one defines a data path. The Office365 and Google connectors send content to vendor clouds that may sit outside the EU, so they should be disabled unless their data flow is mapped and approved. An OnlyOffice connector is only in scope if the document server runs in your EU environment. Ask the partner for a data flow diagram per connector.
Search and logging kept in region
Search indexes and audit logs contain copies of page text, user names and access events, so they are personal data in their own right. A search engine or log shipper that sends events to a hosted service outside the EU recreates the transfer problem even when the wiki database is local. The HIPAA Security Rule at 45 CFR 164.312(b) requires audit controls for systems containing ePHI, so audit logs must also be retained and reviewed in region. Confirm where the index, the log store and any monitoring agent send data, and the retention period you have set.
Vendor remote access controls
Vendor support is a transfer if the support engineer views personal data from a third country, even only on a screen, according to EDPB Guidelines 05/2021. Define which support staff can connect, from which countries, through which jump host, and with which session recording. XWiki SAS offers on-premises professional support and installation help, so ask whether support is delivered from EU locations and whether access is time limited and logged. Record each session, and require approval from your own administrators before access begins.
Evidence a DPO or regulator will ask for and which component produces it
This table maps each piece of evidence a data protection officer or regulator typically asks for against the component that produces it, whether that is the data inventory, the hosting or support vendor, the wiki audit trail, the migration run or the switching plan. Read it as a division of responsibility: the wiki supplies logs and exports, but the records of processing, transfer assessments and contracts are organizational documents that the wiki cannot generate on its own.
| Evidence item | Produced by | What the reader should confirm |
|---|---|---|
| Records of processing and transfer map | Data inventory of the wiki spaces, updated with each migration wave and with any new hosting location | Every space and attachment store is listed, with the location of storage, backups and any remote administration access |
| Transfer impact assessment for any non-EU access path | Controller's assessment, informed by vendor answers on remote support and third-country law exposure | Remote support sessions, telemetry, backups and vendor staff locations are each assessed as a possible transfer under EDPB Guidelines 05/2021 |
| Data processing agreement and sub-processor list | Hosting provider, implementation partner and any support vendor, as signed contracts | Sub-processor changes are notified in advance and the list covers backup, email and monitoring services |
| Access review logs from the wiki audit trail | Wiki page history, permission exports and the identity provider's group membership records | Reviews show who can read restricted spaces, and logs are kept in EU-controlled storage with a defined retention period |
| Deletion and export records from the migration | Migration run reports from the source export and the import into the target wiki | Page history, attachments and user mappings are reconciled, and deleted or excluded personal data is documented with dates |
| Data Act switching documentation | Exit plan, export format definitions and the target platform's runbook, maintained by the controller and the provider | Switching to another provider or on-premises infrastructure can happen within the notice and transition periods the Data Act sets |
What EU teams ask before moving their wiki
Is a US-owned SaaS vendor with EU data centers enough for data sovereignty?
Not on its own. EU data centers answer where data is stored, but two other questions decide the risk: whether the vendor can be compelled to disclose data, and who can see it in the clear. The US CLOUD Act, at 18 U.S.C. 2713, requires providers to preserve or disclose data in their possession, custody or control regardless of location. GDPR Article 48 limits how third-country orders are recognized, but only where an international agreement applies. EDPB Guidelines 05/2021 also treat remote access from a third country, even just displaying data on a screen for support, as a transfer. Ask the vendor in writing how it handles foreign government requests and which staff can reach your content from outside the EEA. Your legal and privacy team should make the final assessment.
How long does a wiki migration from Confluence or Notion take?
The duration depends on the number of spaces, the volume of attachments, how much page history you keep and how complex your permission model is. Permission mapping usually takes the most analysis, because groups and page restrictions rarely translate one to one. Timelines should be fixed in the written scope before work starts, after a discovery phase that inventories spaces, users, groups and attachments. Ask the partner to show which assumptions the timeline depends on, and what happens if the source data is larger than the inventory suggested.
What drives the cost of an EU-hosted knowledge base?
Costs fall into four groups: the software, the support tier, migration tooling and consulting days, and the hosting and administration you run yourself. XWiki Standard is free and open source. XWiki SAS lists support and Pro subscriptions in Starter, Basic, Business and Enterprise tiers, with user limits from 25 to unlimited, and states that cloud and on-premises pricing is the same. Its consulting is listed at 1200 EUR per day for Business or Enterprise support plans, and Confluence Migrator Pro is priced from 2000 EUR according to the XWiki Store. Those figures come from XWiki SAS and may change. DeployOpen does not publish prices. A quote follows from a written scope that states spaces, users, integrations and support expectations.
What does our internal team need to provide for the migration?
A named business owner for each major space, someone who can approve permission decisions, and an administrator who can supply directory access for SSO. You will also need to decide what to retire, because migrating stale pages costs time without adding value. Expect to provide a current export or read access to the source tenant, a list of identity groups and their intended use, and sign-off on the test pages used for validation. The more of these decisions are made before the engagement, the fewer surprises appear in the written scope.
Can our own team migrate and host the wiki without a partner?
Yes, if you have the skills and capacity. XWiki, BookStack and Outline can be installed and run by a capable administrator, and the official XWiki Docker images are maintained by the XWiki Core Dev Team. The harder parts are migration fidelity, permission design, SSO configuration, backups, upgrades and security testing, which need repeated attention for years. Consider a partner when the team lacks experience with these areas, when the migration has many spaces, or when audit evidence must be produced. A partner can also run only the parts you cannot staff, such as the migration or the upgrade runbook.
How does the EU Data Act affect exiting a wiki provider?
The Data Act gives customers of data processing services the right to switch to another provider or to on-premises infrastructure. Under Regulation (EU) 2023/2854, the notice period can be up to two months, the transition period is 30 days, and switching charges are banned from 12 January 2027. Those rights apply to the service contract, so write exit planning into your procurement. Keep regular exports in an open format, document your permission model and confirm that your vendor can supply full page history and attachments. Ask your legal team whether the Data Act applies to the specific contract you are signing.
What personal data should we remove from pages before migrating?
Start by identifying personal data in old pages, such as HR notes, customer names in incident reports or contact details in onboarding guides. Under GDPR, you still need a lawful basis and a retention rule for that data after it moves, and a migration is a good moment to delete what you no longer need. Review attachments as well as pages, since they often contain more personal data than the text. Decide the retention period per space, and make sure restricted spaces use separate permissions. Your data protection officer should sign off on the approach before the import begins.
Questions to put to an implementation partner on sovereignty
Start with a map of where every component runs and who can reach it. Ask the partner to list each service in the wiki stack (the application server, database, search index, attachment storage, backups, mail relay and monitoring) with its physical location, hosting account and operating jurisdiction. Then ask who holds administrative and remote access to each one, under which accounts, from which countries, and whether any support session ever displays production data on a screen outside the EEA. The EDPB guidelines treat that kind of remote viewing as a transfer, so the answer determines whether the design is sovereign or only European on paper. Request the access list as a document you can audit, not a verbal assurance.
Next, ask for the full sub-processor chain. Include the hosting provider, any managed database or backup service, the partner's own support tooling, ticketing systems and vulnerability scanners that touch client data. For each one, ask whether the provider is subject to third-country law with extraterritorial reach, such as the CLOUD Act provision at 18 U.S.C. 2713, and what the partner has done to assess exposure to a foreign authority request. Ask how the partner would notify you before adding a sub-processor and how you could object. Confirm which non-EU support paths exist for upstream vendors, because a vendor patch channel can become a transfer path even when your data never leaves the EU.
Ask how the migration treats personal data in attachments, page history and comments before anything is copied. Confluence and Notion exports often carry old revisions, deleted pages, user profiles and mentions that persist longer than the business owner expects. Ask whether the partner will run a personal data scan, how it will decide what is excluded or redacted, and who signs off on that decision. Ask how the migration tool handles history and attachment versions, since tooling limits differ by source, and ask for the written list of what is not carried over. Finally, ask how the partner documents transfer assessments and the Data Act exit plan: which written record covers each transfer analysis, how upgrades and security patches are delivered without foreign administrative access, and how you would move the data and configuration to another provider or on-premises infrastructure under the switching rights in the Data Act, including the notice period and the transition steps you would need to fund.
Rollout phases and what each one delivers
The sequence moves from a data inventory to a documented, EU-hosted wiki that your own staff can upgrade, back up and keep current after the implementation partner leaves. Each phase closes with a written output that you can review before the next phase starts.
Scope the wiki and classify the content
DeployOpen and your data protection lead inventory the spaces, page counts, attachments, users and groups in Confluence Cloud or Notion, then classify each space by sensitivity and by whether it contains personal data such as names, contact details, HR notes or customer references. The client's data protection and records owners confirm which spaces are in scope for the first wave. The step closes with a signed scope document and a classification register that names the owner of each space.
Design the sovereign architecture and review vendors
Together with your architects, DeployOpen selects the wiki platform (for example XWiki, BookStack or Outline, each with its own license terms) and designs hosting in your EU cloud account, data center or private network. The team maps every component, including backups, logs, search indexes and any support access, and records where each one runs and which legal entity controls it. Vendor and support contracts are reviewed for third-country access, remote support and sub-processors. The output is an architecture decision record and a vendor review memo that your legal and privacy teams sign off.
Build and harden in the client environment
DeployOpen deploys the chosen platform in your EU environment, configures SSO against your identity provider, sets up the database, storage, TLS, backups and audit logging, and applies the hardening baseline agreed in the architecture record. Remote administration paths are restricted to EU-located, named staff under your access rules. The step closes with a deployment record, a configuration baseline and a test report covering access control, logging and restore testing, which your security team reviews.
Run a migration pilot and then the full migration
DeployOpen migrates one or two representative spaces first, using the migration tooling that fits the source and target, and checks pages, history, attachments, users, groups and permissions against the source. Known limits are documented before the pilot, including any loss of attachment history in Confluence migrations and anything the tool cannot map. After the pilot is accepted, the remaining spaces move in waves, with a reconciliation report per wave. The output is a pilot acceptance record and a reconciliation report for each wave, with a documented cut-over and a plan for decommissioning the source tenant.
Train staff and assign page ownership
DeployOpen delivers role-based training for editors, space owners, administrators and readers, and works with your teams to assign an accountable owner to every space and to high-risk pages such as policies and runbooks. Review dates and approval rules are set for controlled content. The output is a training record by role, a named owner register and a page review schedule that the business owners have accepted.
Hand over with a documented upgrade and backup routine
DeployOpen hands the platform to your operations team with runbooks for upgrades, backup and restore, certificate renewal, user offboarding and incident response. The restore procedure is exercised by your team with DeployOpen observing, and the upgrade path for the chosen platform is written down, including how security releases are tested and applied. The output is a handover pack, a tested restore record and an operations calendar. Ongoing upgrades, monitoring and testing can be placed under a separate retainer if you choose that model.
How DeployOpen scopes and supports a sovereign wiki
A sovereign wiki only holds up if scope, hosting and testing are settled before content moves. DeployOpen agrees these in writing, builds the platform inside your EU infrastructure, and tests the wiki and its connectors the way an assessor would.
Fixed written scope
Each engagement starts with a written scope that names the platform, the Confluence or Notion sources to migrate, the identity provider, and each integration such as chat, file storage or ticketing. Ask the partner to list which spaces are in and out, how attachments and page history are handled, and which migration steps are manual. Scope also fixes who owns data mapping decisions and who signs off on the cutover. Deliverables and timelines are agreed before work begins, so changes are tracked as written amendments rather than absorbed silently.
Deployment in your EU infrastructure
The wiki, its database, search index and attachment storage run in cloud accounts, data centers or private networks that you control and that sit in the EU. Confirm where backups, logs and search indexes are written, because copies outside the EEA count as transfers under EDPB Guidelines 05/2021. Ask for a data flow diagram that shows every location, including support access paths. Remote administration from a third country must be listed and controlled too.
Security testing of the wiki
Testing covers the wiki application, its API, and each connector, including SSO, webhooks and any import tooling. Testing is aimed at the risks that matter for personal data in pages, such as access to restricted spaces, leaked attachments and misconfigured guest or public sharing. Ask for the test scope in writing, the remediation process, and whether retests are included. Findings should be tied to the permission model so you can show that restricted content stays restricted.
Compliance evidence and retainer support
DeployOpen prepares the system description, configuration records, access reviews, backup and restore evidence, and change logs that your compliance team and independent assessors need. DeployOpen prepares evidence for assessments but does not issue audit reports or certifications; those come from independent auditors and certification bodies. Ongoing support, upgrades and continuous testing are available as a retainer. Ask which evidence is produced at handover and which is produced on each upgrade cycle.
