Why team chat for EU data sovereignty is a transfer and control question
Moving internal messaging from a US SaaS tool to infrastructure you control in the EU removes the largest transfer exposure only if you check every place personal data can still leave the EU: hosting, administrator access, backups, federation and encryption key handling. Hosting in an EU data center does not settle the question on its own. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and the EDPB's Guidelines 05/2021 treat remote access from a third country, even just displaying data on a screen for support, as a transfer. A vendor support engineer in another country who can see message content is therefore part of your transfer analysis, not a footnote to it.
The reason control matters more than location is the legal context. In *Schrems II* (Case C-311/18), the Court of Justice invalidated the EU-US Privacy Shield while keeping standard contractual clauses valid, and the EDPB's Recommendations 01/2020 state that where a provider must access data in the clear and foreign public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. The US CLOUD Act (18 U.S.C. 2713) reaches providers' data regardless of where it is stored. Before you choose between Mattermost, Rocket.Chat and a Matrix homeserver running Synapse, ask each vendor and each hosting partner which entity controls the software, the keys and the administrators, and whether any of them is subject to foreign law with extraterritorial reach. Mattermost, Rocket.Chat and Matrix differ in federation, licensing and enterprise features, and that trade-off is covered later on this page.
DeployOpen plans, implements and hardens self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and it prepares the configuration, access records and evidence that a compliance assessment will ask for. It does not provide legal opinions on transfer mechanisms or on the adequacy of a third-country framework, and it does not issue audit reports or certifications. Your data protection officer or counsel should decide whether the transfer analysis holds, and an independent auditor should assess the controls. Start by documenting where messages, files, metadata, logs and backups are stored, who holds administrator and support access, and whether any sub-processor can reach the data in the clear.
Which requirements a sovereign chat deployment must meet
This table maps the EU and US legal requirements that shape where chat data lives, who can reach it and how it can leave. Read each row as a question the controller must answer with its own assessment, since the sources set conditions rather than guarantee outcomes. The main takeaway is that hosting location alone does not settle transfer or access exposure.
| Requirement | Source | What it means for the build |
|---|---|---|
| Transfers to third countries, including onward transfers | GDPR Article 44 (Chapter V); fines under Article 83(5)(c) reach up to EUR 20 million or 4% of worldwide annual turnover | Map every location where chat content, backups, logs and push metadata are stored or accessed. Confirm that subprocessors and support staff outside the EU are covered by a Chapter V mechanism. |
| Remote access and storage outside the EEA count as transfers | EDPB Guidelines 05/2021 (version 2.0) | Administrator and vendor remote sessions from a third country, including screen-sharing for support, must be included in the transfer assessment. Restrict admin access paths and log them. |
| Using an EU processor under foreign law | EDPB Guidelines 05/2021, Example 12 | Using an EU-based processor is not itself a transfer, but compliance with a third-country authority request would be. Controllers should assess that exposure before engaging a hosting or support provider. |
| Third-country disclosure orders | GDPR Article 48 | A foreign court or agency order is recognized only under an international agreement in force with the Union or a Member State. Ask providers how they handle such requests and whether they notify the controller. |
| US reach over data held by providers | 18 U.S.C. 2713 (CLOUD Act), added 23 March 2018 | Preservation and disclosure duties apply to data in a provider's possession, custody or control, wherever it is located. Hosting with a US-parented provider can therefore carry access exposure even inside the EU. |
| Third-country access to non-personal data | EU Data Act Article 32, Regulation (EU) 2023/2854 | Chat metadata, channel configuration and other non-personal data also need safeguards against conflicting third-country access. Ask providers which technical, organizational and legal measures they apply. |
| Switching to another provider or on-premises | EU Data Act Articles 25, 29 and 50, applicable since 12 September 2025 | Customers may move to another provider or on-premises infrastructure with notice of at most two months and a 30-day transition. Switching charges are banned from 12 January 2027, so design exports of channels, users and files from the start. |
Where a chat deployment creates a transfer without anyone noticing
A chat deployment creates a transfer under GDPR Chapter V in more places than the primary database. Under the EDPB's Guidelines 05/2021 (version 2.0), remote access from a third country counts as a transfer even when the person only views data on a screen for support or administration. A vendor engineer in a non-EEA country who opens a message history during an incident has made a transfer, whether or not any file left the EU. Storage in a cloud outside the EEA is also a transfer, and so is any onward transfer from a processor to a sub-processor located elsewhere. Article 44 applies to each of these hops, and infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c).
The less obvious flows sit around the chat server. Mobile push notifications often pass through a relay operated outside the EU, and the relay may see sender, recipient and sometimes message metadata. Email notification services, SSO identity providers, telemetry and crash reporting, link preview fetchers and third-country CDNs for static assets can each receive personal data. Backups copied to an off-site location and audit logs shipped to a hosted log platform are frequent blind spots. Build a table with one row per data class (message content, metadata, uploaded files, audit logs, backups, push payloads, telemetry) and one column per location and per administrator's location. Confirm each cell with the product documentation and your own network configuration, not with assumptions about what the "self-hosted" label covers.
Where a processor is an EU company but is subject to third-country law with extraterritorial reach, the EDPB's Example 12 says that engaging it is not itself a transfer, but complying with a third-country authority request would be one. Treat this as an open risk to assess before signing, not a closed question. Ask any implementation partner or hosting provider which legal orders they could receive, where their support staff are located, and what they would do with a request that conflicts with Article 48 of the GDPR. The GDPR text on EUR-Lex is the primary reference for that analysis, and your data protection officer should record the outcome in the transfer impact assessment.
Which open-source chat platform fits an EU sovereignty brief
The three platform families below differ less in features than in how they handle licensing, federation and high availability. Each card names the decision a sovereignty brief forces, so you can test candidates against your own transfer analysis, partner model and support obligations.
Mattermost for controlled single-organization hosting
Mattermost runs as a single Linux binary on PostgreSQL, and its compiled releases are MIT-licensed while the source falls under AGPL-3.0 with listed exceptions. For a sovereignty brief, the question is which edition unlocks what you need: SSO and AD/LDAP sync start at the Professional plan, high availability and FIPS 140-3 compliance at Enterprise, and air-gapped deployment at Enterprise Advanced. High availability also needs shared file storage on S3-compatible services or NAS, because local storage can corrupt files. Confirm the edition, storage design and the Mattermost release cadence before you commit.
Rocket.Chat and its enterprise boundary
Rocket.Chat is MIT-licensed except for content in its ee directories, which falls under a separate enterprise license. That split matters for sovereignty because a build you audit, host and keep in-country may include code you can only run under a commercial agreement. Map each feature you need, such as SSO, compliance export, or clustering, to either the MIT core or the enterprise directories before you assume it is free to self-host. Ask the vendor for a written list of enterprise-licensed components and confirm how EU hosting and data location are covered in that license.
Matrix with Synapse for controlled federation
Synapse is AGPL-3.0 licensed and is the most widely documented Matrix homeserver. Federation is the sovereignty lever: the federation_domain_whitelist setting limits federation to listed domains, and an empty list disables it entirely. Pair that with a firewall on the federation listener, as the docs recommend. Synapse supports OIDC, SAML2 and CAS for single sign-on, recommends PostgreSQL for production, and uses Redis to relay replication when you scale with workers. Plan for rollback limits: schema changes between releases can make downgrades difficult, so test upgrades in a staging environment first.
Dendrite and Conduit as alternatives to confirm
Matrix.org lists Dendrite, which is AGPL-3.0-or-later and written in Go, along with Conduit and its Rust forks Continuwuity and Tuwunel, which are Apache-2.0. These options may suit smaller footprints or different licensing preferences, but they need verification against your requirements before you choose one. Confirm federation controls, SSO support, database requirements, clustering and upgrade paths for the exact release you intend to run in production. Ask the partner which of these implementations they have operated under federation and audit obligations, and whether a commercial support path exists.
How to restrict federation and choose encryption without losing control
Federation is the sovereignty feature most teams overlook, and it is the one that can quietly move messages outside your control. A Matrix homeserver built on Synapse federates on port 8448 by default, and delegation can serve user IDs such as @user:example.com from another host on port 443. The server_name setting fixes how users and rooms are identified, so it must be chosen before the first user is created, because changing it later is effectively a new deployment. Start by setting federation_domain_whitelist to the explicit list of partner domains you have approved. An empty list disables federation entirely, which is the right default until a partner is approved. Pair that setting with firewall rules on the federation listener, since the Synapse documentation recommends both controls rather than relying on one. Confirm the behavior in a test environment by attempting a room invite to a domain that is not listed.
The decision to federate with a partner belongs to governance, not to the platform team. Before adding a domain, record who approved it, which data classes may be shared, how the partner's own retention and access controls are assessed, and who can revoke the entry. Each approved domain is also a third-country exposure question if the partner's server is hosted outside the EEA, so the GDPR transfer analysis from the earlier sections applies to federated rooms as well. On encryption, the team needs three separate decisions. Transport encryption (TLS) protects traffic between clients, servers and federated peers. Encryption at rest protects the PostgreSQL database and the media or file store, and it is usually delivered by the storage layer, so confirm which volumes and backups it covers. End-to-end encryption protects message content from the server itself, but it limits server-side search, compliance export and moderation, because the server cannot read the messages it holds. For regulated teams, decide which rooms may use end-to-end encryption and which must remain readable for retention. Finally, decide key ownership: who holds the keys, where they are stored, how they are backed up, and who can recover them if a device or account is lost.
Which hosting model keeps EU control clearest
An EU region inside a cloud account that the client owns is the most common middle path. The client keeps the account, the billing relationship and the root credentials, and the chat platform runs as workloads inside EU regions. Control depends on configuration, not on the provider's location alone, so the account has to be built for it from the start. Whether the cloud provider's own staff or parent company can reach the environment is a contract and architecture question that the client must answer in writing.
- Administrative credentials: Root and owner accounts sit with named client staff under the client's identity provider, with hardware-backed multi-factor authentication. Service roles are scoped to EU regions, and key management is kept in the client's own control plane.
- Backups and logs: Database dumps, file storage snapshots and audit logs are pinned to EU regions through policy, and replication to other regions is disabled. Confirm which provider-side logs (control plane, support access, telemetry) are retained and where.
- Third-country support access: Ask whether the provider offers EU-only administration or support staffing, how customer-managed keys are held, and what happens when a provider employee in another country is asked to act. The EDPB Recommendations 01/2020 treat a provider that must access data in the clear under broad foreign powers as a problem that technical measures may not solve.
- Data Act switching: Under the Data Act, customers can switch away from a data processing service with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. Confirm the export formats for messages, files and configuration before signing.
- Operational scope: The client's team still operates the chat platform, patches it and handles upgrades.
Before committing, ask the provider for its written position on foreign government requests and on support access from outside the EEA.
An EU sovereign or private cloud provider operates the infrastructure under a contract that is designed around EU jurisdiction and client control. The model can reduce the number of parties with access, but it moves trust into the provider's ownership structure, staffing and legal exposure. Evaluate the provider as you would evaluate any processor, and assess the foreign-law exposure of its owners and subcontractors before engaging it, as EDPB Guidelines 05/2021 advise for EU processors subject to third-country law.
- Administrative credentials: Ask whether the client receives its own administrator accounts and break-glass access, and whether provider staff access is logged, approved per request and visible to the client.
- Backups and logs: Confirm the physical and legal location of backup copies, log archives and support tooling, including any subcontractors that touch them.
- Third-country support access: Require a list of subprocessors, a commitment that remote access from outside the EEA is blocked or approved case by case, and a defined procedure for handling government requests, including challenge and notice to the client.
- Data Act switching: Confirm that the contract gives the client switching rights to another provider or to on-premises infrastructure, with notice and transition terms that match the Data Act, and that exit assistance includes a complete data export.
- Ownership and financing: Ask who owns the provider, whether any non-EU parent can direct its operations, and how a change of control would be handled.
Request the provider's written answers on these points and have legal counsel review the exit terms before signing.
Running chat in the client's own data centre gives the most direct control over administrative access, storage and network paths. The trade-off is that the client carries the hardware, facilities, patching and staffing, and must build the resilience that a provider would otherwise supply. It also removes the switching question at the provider level, because the client already holds the infrastructure, although the Data Act's on-premises option is a useful reference for exit planning.
- Administrative credentials: Access is limited to named staff through the client's directory, with privileged sessions recorded and reviewed. No vendor remote access is enabled unless it is approved, time-bound and logged.
- Backups and logs: Backups go to a second site in the same jurisdiction, with encryption keys held by the client. Audit logs are forwarded to a log store the client controls.
- Third-country support access: Vendor support, if purchased, runs through a documented, client-initiated session. Remote access from outside the EEA should be disallowed by network policy, not only by contract.
- Data Act switching: Moving data out is handled by the client's own migration plan, so the main exposure is the reversibility of the platform itself. Confirm that the chosen open-source platform and its database can be exported and restored elsewhere.
- Operational scope: Plan for high availability, failover testing and on-call coverage, because a single site is a single point of failure.
Check whether the site, its operators and its support contracts meet the same jurisdiction and access rules the chat platform must meet.
How a sovereign chat migration runs from transfer map to cutover
The sequence turns a US SaaS chat tenant into an EU-controlled, self-hosted platform in stages, with a written output at each gate so that transfer exposure, federation scope and deletion of the old tenant can be shown to a data protection officer or auditor.
Map transfers and data flows
Begin by inventorying what the current chat tenant holds: messages, files, profile data, guest accounts, integration tokens, backups and support access paths. For each flow, record where the data sits, which vendor staff or subprocessors can reach it, and whether remote access from outside the EEA occurs, since EDPB Guidelines 05/2021 treat even on-screen display for support as a transfer. The output is a written transfer map signed off by the controller and the data protection officer. It is done when every flow is either mapped to EEA hosting or flagged for a decision.
Choose platform and federation policy
Select Mattermost, Rocket.Chat or Matrix based on the requirements that the transfer map surfaces, such as SSO, retention, mobile push and partner messaging. Decide in writing whether federation is needed at all. If it is, Synapse's federation_domain_whitelist setting limits federation to named domains, and an empty list disables it. Confirm the licence and edition for each required feature with the vendor, because SSO, high availability and air-gapped use sit in paid tiers for some products. The output is a platform decision record and a federation policy listing permitted domains, reviewed by security and legal.
Design hosting and access controls
Specify where the platform runs, which EU provider or data centre hosts it, and who holds administrative and root access. Document the access path for DeployOpen or any other operator, and confirm that support sessions do not expose data from outside the EEA. Define database, file storage and backup locations, and encryption in transit and at rest. Where Mattermost high availability is planned, shared storage must be on S3, an S3-compatible service or NAS on every node, since local storage risks file corruption. The output is an architecture and access design that the transfer map can be checked against.
Integrate SSO and directory sync
Connect the platform to the organization's identity provider using OpenID Connect, SAML or the directory integration the chosen edition supports, and confirm which edition includes it. Set rules for account provisioning, deprovisioning and guest accounts so that leavers lose access on the same day their directory account is disabled. Test login, role mapping and session lifetime with a set of named test identities. The output is a signed-off identity configuration and a test log showing provisioning and removal results.
Build and test the test tenant
Stand up a test tenant in the EU hosting design, not on the production hosts. Load representative channels, retention settings, legal hold rules, export jobs, bots and integrations, and run the restore procedure from backup. Check that logs needed for audit are written to a location under the organization's control. Exercise upgrade and rollback on the test tenant first, since rollback can be difficult when database schemas change between releases. The output is a test report listing each defect, its owner and its closure evidence.
Migrate Slack or Teams history with a gap check
Export history from the source tenant using the vendor's export mechanism, then run the import into the test tenant. Mattermost publishes a Slack migration guide, which the team should check against the actual export contents. Compare message counts, threads, attachments, edits, reactions, user mappings and channel membership against the export. Record explicitly what is not carried across, such as certain integrations, bot configurations, app data or files that the export does not include. The output is a migration gap register that business owners accept in writing before the pilot begins.
Run a pilot group
Move a bounded group of users, chosen to include an administrator, a compliance contact, mobile users and one team with external partners, onto the EU platform while the US tenant stays live. Collect defects, check push notification behaviour on managed devices, and verify that retention and export behave as the policy requires. Obtain sign-off from the pilot owners on usability, access and the gap register. The output is a pilot exit report with any accepted risks recorded against named owners.
Cut over and delete the US tenant
Freeze writes on the US tenant, run the final delta migration, switch users and integrations to the EU platform, and communicate the new address and sign-in path. After a defined observation period agreed in advance, request deletion of the US tenant and its backups from the provider, and obtain written confirmation from the provider that deletion was carried out. Keep the deletion confirmation, the final transfer map and the cutover record in the compliance file. The output is a closure pack that shows where data now resides and proves that the US copy was removed.
Evidence a data protection authority or auditor will ask for
This table lists the records a data protection authority, auditor or internal assessor is likely to request when internal messaging moves to EU-controlled hosting. Each row names the evidence, who typically produces it and who owns it on the client side. DeployOpen prepares and documents much of this evidence, but auditors and supervisory authorities decide whether it is sufficient.
| Evidence | Produced by | Owner |
|---|---|---|
| Records of processing and transfer map covering message content, metadata, user directory and backups | Client privacy team, using the data mapping workshop output from DeployOpen | Data protection officer |
| Transfer impact assessment support and standard contractual clause records for every third-country access path, including support and administration | Client legal team, with DeployOpen supplying a technical access inventory | General counsel or privacy counsel |
| Hosting location register for servers, databases, object storage, push relays and backups, with the EU region or data center named | DeployOpen as a configuration record, verified by the client's cloud or data center team | Head of infrastructure |
| Admin access logs and a list of who can reach the platform from outside the EEA, including vendor or partner remote sessions | Bastion or VPN logs, and the platform's admin audit trail, exported by DeployOpen into the client's log store | Security operations lead |
| Federation allow-list configuration and change records, showing the permitted domains and the approver for each change | Synapse or Mattermost configuration files, versioned in Git, plus change tickets | Platform owner, with the CISO as approver |
| Audit logs from the chat platform covering logins, role changes, admin actions and exports, retained for an agreed period (a comparable expectation to the audit controls in 45 CFR 164.312(b)) | Platform audit logs forwarded to a central SIEM, configured by DeployOpen | Security operations lead |
| Encryption configuration evidence: transport TLS versions and certificates, database and storage encryption at rest, and key custody | Configuration exports and certificate inventory produced during hardening | Infrastructure security owner |
| Backup location and restore test results, showing that backup copies stay in the EU and that restores have been tested | Backup job reports and restore test records produced by DeployOpen, with restore results signed off by the client | Backup or resilience owner |
| Deletion evidence from the old SaaS tenant, including export completion, workspace deactivation and vendor confirmation of data removal | Migration runbook records, vendor deletion confirmation and the client's own check of the old tenant | Records manager, with the data protection officer |
What to ask an implementation partner before signing a sovereignty scope
Which chat platform should we choose if we need federation with other organizations?
Matrix is the platform built around federation, while Mattermost and Rocket.Chat are usually run as a single organization's server, so the choice depends on who you must talk to. Ask the partner to name the platform and explain why against your actual partner list, including which external organizations already run Matrix servers and whether they accept federation at all. Ask how they would handle an organization that stays on Slack or Teams, and whether a bridge is proposed, who maintains it, and what happens to message history when it is used. A good answer ties the platform choice to your federation requirement in writing rather than to general preference.
Which features need a paid plan, and how is that confirmed in writing?
SSO, high availability, FIPS compliance and air-gapped operation are often tied to specific editions, so the scope must name the edition and the features it includes. According to the Mattermost pricing page, SSO and directory sync start at the Professional plan, high availability and FIPS 140-3 compliance at Enterprise, and air-gapped deployment at Enterprise Advanced. Ask the partner to list every feature your requirements depend on, map each to a plan in the vendor's current documentation, and attach that mapping to the signed scope. Pricing is set by the vendor and is not published, so ask for the license quote to be issued directly and confirmed by the vendor before the scope is signed.
Where do all components and backups run, and who has admin access from which country?
The partner should give a written inventory of every component, including application servers, database, file storage, search, backup targets, logs, push relays and support tooling, with the hosting location and legal entity for each. Under EDPB Guidelines 05/2021, remote access from a third country, even just displaying data on a screen for support, counts as a transfer, so administrator and vendor access locations matter as much as storage. Ask for a list of named roles, the country each person works from, how access is granted and recorded, and whether any backup replica or log shipper leaves the EEA. Confirm that the cloud provider, if any, is also covered by this statement.
How is federation restricted to trusted domains, and how is that tested?
Federation should be limited to an explicit list of trusted domains, not left open by default. In Synapse, the federation_domain_whitelist setting restricts federation to listed domains, an empty list disables federation, and the documentation recommends also firewalling the federation listener. Ask the partner to show the exact configuration, the firewall rule for port 8448 or any delegated endpoint, and the test plan that proves a non-listed server is refused. Ask who approves changes to the list and how that approval is logged. A partner should be able to demonstrate the refusal in a test environment before go-live.
How is Slack or Teams history migrated, and what is lost in the move?
Migration typically moves channels, users, messages and some files, but integrations, bots, app-specific data, some metadata and possibly edit histories may not carry over cleanly. Ask the partner to produce a field-by-field gap list for your source workspace before scope is signed, covering private channels, direct messages, attachments, guest accounts and retention settings. Mattermost publishes a migration guide for Slack, which is a useful starting point for the partner to test against your export. Ask for a test migration on a copy, a reconciliation report comparing message counts and attachments, and written agreement on what will be retired instead of migrated.
How does mobile push work without sending message content through a foreign gateway?
Mobile push notifications usually pass through a vendor or platform push service, and the content or the identifiers sent through that path may leave your control. Ask the partner to describe exactly what data each push carries, whether message text is included, and which push relay is used for each mobile platform. Ask whether the relay can be self-hosted or replaced, where its logs are kept, and how it behaves when public gateways are blocked. The answer should be documented in the data flow diagram and reviewed against your transfer assessment before users are onboarded.
How are monthly and security releases applied, and who does it?
Mattermost releases a new server version in binary form on the 16th of each month, and support windows are short for non-ESR versions, so an unpatched server can fall out of support quickly. Ask the partner for a written release policy covering the test environment, change window, rollback plan, and the time between a vendor security release and your production update. Ask which version you will run, whether an Extended Support Release is proposed, and who is responsible for watching the vendor release page. The Synapse upgrade notes warn that rolling back can be difficult because of database schema changes, so ask how backups are tested before each upgrade.
What evidence does the partner deliver to support a sovereignty review?
Ask for a documented evidence pack rather than verbal assurances: an architecture and data flow diagram, the component and location inventory, the access register, the federation configuration with test results, the transfer impact assessment inputs, the backup and restore test record, and the release and change log. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and an independent auditor or certification body makes that determination. Ask the partner to state which evidence items are delivered at handover and which are produced on a retainer, and confirm that the list is part of the signed scope.
Who pays for what, and what recurs after go-live?
Costs usually fall into four groups: the fixed-scope implementation, the software license or subscription for any paid edition, the infrastructure in your cloud or data center, and ongoing operations including upgrades, backups and support. DeployOpen works on fixed scope agreed in writing before work starts, and does not publish a price list, so the quote follows from the written scope. Ask the partner to separate one-time work from recurring costs, to name who invoices each line, and to identify what would change the total, such as user count, federation partners or high availability requirements. Ask the partner to state in writing whether the license is billed by the vendor and whether ongoing support is a separate retainer.
How DeployOpen scopes and runs a sovereign chat deployment
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source chat inside your own cloud accounts, data centers or air-gapped networks. For EU data sovereignty, the work starts with where personal data and metadata will sit, who can administer the platform, and which federation and identity links must be controlled before any build begins.
How we scope
- Written scope lists the chat platform, hosting location, administrator access model and each third-country exposure you need to close.
- Scope records which federation domains are allowed, enforced through a documented allow-list and firewall rules on the federation listener.
- Scope names the identity provider, directory sync, retention settings and migration source, with deliverables and timelines agreed in writing before work starts.
How we build
- Deploy the chosen platform and its database and file storage inside EU-controlled infrastructure, with network paths mapped to show no unplanned data flows.
- Configure single sign-on, encryption in transit, audit logging and retention, then test federation restrictions and administrator remote access against the written scope.
- Migrate exported history from Slack or Teams in a rehearsed run, verifying message counts, attachments and access rights before cutover.
How we hand over
- Deliver architecture diagrams, data flow records, configuration baselines and runbooks that your data protection and security teams can review.
- Provide evidence packs that show how controls were implemented, prepared for review by your independent auditors or assessors, not issued as audit reports.
- Train administrators on upgrades, backups and restore procedures so your team can operate the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering monthly platform releases and security patches.
- Re-test federation allow-lists, access paths and configuration drift after each upgrade or change in your transfer or vendor position.
- Revisit the scope when laws, adequacy decisions or your processor contracts change, with any new work agreed in writing first.
