Two different compliance teams will ask you about communications tools, and they'll ask completely different questions.
A US healthcare compliance officer wants to know who can reach patient information, and whether you can prove it. A European public-sector buyer wants to know whose law can reach it. The interesting part? The answer to both is the same stack: open-source chat, video, phone, files, and email, running on servers you control, behind a single identity provider.
We've covered the individual pieces elsewhere: sovereign video conferencing, HIPAA-compliant telehealth video, and nine self-hosted Microsoft Teams alternatives. This article is about stitching them together into one platform that passes both tests, and the handful of spots where data still leaks out even when every server is yours. It's a technical guide, not legal advice.
The Quick Take
Open-source tools on infrastructure you control pass both tests. The real work isn't in any single app; it's in identity, logging, and the edges where messages leave your servers.
Healthcare, legal, public sector
Keycloak, a chat server, Jitsi, Nextcloud, and mailcow on servers you choose. Each piece is mature and replaceable.
EU administration on Kubernetes
openDesk ships the whole set as one product, built for public administration. Bigger deployment than a few servers.
HIPAA only, no sovereignty requirement
Microsoft signs a BAA. If nobody's asking whose law applies, a hosted suite under a BAA can be the simpler answer.
No risk analysis or identity plan
Do the HIPAA risk analysis or GDPR DPIA first, and decide where sign-in lives. Everything else hangs off those two.
Two Tests, One Stack
Sovereignty is about jurisdiction. HIPAA is about safeguards. Put the questions side by side, and they land on the same parts of the system.
| Layer | Sovereignty asks | HIPAA asks |
|---|---|---|
| Software | Can you run it without the vendor, and change supplier? | Does it support unique user IDs, audit logs, and encryption? |
| Infrastructure | Which country's law applies to whoever owns the servers? | Is there a BAA with the provider that stores the data? |
| Operations | Who can log in, patch, and answer support tickets? | Is access limited, logged, and reviewed? |
| Keys | Who can decrypt the data? | Is ePHI encrypted in transit and at rest? |
The real difference is who you sign with. HIPAA is satisfied by a BAA with your cloud provider, wherever it's based. Sovereignty isn't satisfied by any contract with a provider under foreign law, because the US CLOUD Act reaches data held by US companies wherever it's stored. US law enforcement can compel data from covered providers regardless of location, and the Act also creates a framework for foreign governments to access data held by US providers through executive agreements.
The Stack, Channel by Channel
Here's one workable set of open-source tools. Each is replaceable, which is part of the point: if a project changes its licence or its free edition, you swap that piece, not the whole platform.
| Channel | Open-source pick | Licence | Watch for |
|---|---|---|---|
| Identity | Keycloak | Apache 2.0 | It becomes the most important server you run. Back it up and monitor it first |
| Chat | Mattermost, Zulip, or Element (Matrix) | MIT (Mattermost Team Edition), Apache 2.0 (Zulip), AGPL or commercial (Synapse) | Free editions differ sharply on SSO and production use; check before you commit |
| Video | Jitsi Meet or plugNmeet | Apache 2.0, MIT | The media server decrypts to forward streams unless you turn on end-to-end encryption |
| Phone | Jigasi or plugNmeet's SIP gateway | Apache 2.0, MIT | The call leaves your boundary at the carrier |
| Files | Nextcloud | AGPL-3.0 | Previews, office editing, and federation each add a service to secure |
| mailcow | GPL-3.0 | Mail to outside recipients travels on servers you don't control | |
| TURN relay | Coturn | BSD-3-Clause | Without your own TURN, some calls fail or relay through someone else's |
Chat: the free edition is the trap
Mattermost
Mattermost is the closest match to Teams channels, but v11 changed the calculus significantly. Team Edition is still MIT licensed, but the user cap dropped to 250 users, and GitLab SSO, Google OAuth, and OpenID Connect were all removed from the free tier. HIPAA requires unique, managed identities, so SSO isn't optional. You're either paying for a commercial edition or picking a different chat server.
Zulip
Zulip gives you threaded conversations, a clean Apache 2.0 licence, and straightforward self-hosting. A good fit for teams that drown in busy channels. Our guide to Zulip as a Slack alternative covers the setup.
Element (Matrix)
Element (Matrix) offers end-to-end encrypted rooms and federation. Synapse is AGPL or commercial. But here's the trap: Element's free ESS Community suite is explicitly "not intended for production in commercial environments": no performance guarantees, no certifications, no SBOM, and no Cyber Resilience Act compliance. For anything real, you're looking at ESS Pro.
Video and phone
Jitsi Meet is the engine behind Germany's openDesk, and LiveKit sits under France's Visio, so either is a defensible choice for a sovereign buyer. For teams that record a lot, plugNmeet is the LiveKit-based option with built-in SIP dial-in. Turn on end-to-end encryption in Jitsi Meet for sensitive meetings, and run your own TURN server so calls through strict firewalls don't relay through a third party.
Files and email
Nextcloud covers files, calendars, and contacts under AGPL-3.0, and its Talk app can carry chat and calls for teams that want fewer servers. mailcow runs a full mail server in Docker under GPL-3.0.
Identity Comes First
Every app in the stack should sign in through one identity provider. It's the single biggest control for both tests: one place to enforce multi-factor authentication, one place to offboard someone, and one log of who signed in where.
- Stand up Keycloak before anything elseIt speaks OIDC, OAuth2, and SAML, which every app in the table supports in some edition. Our guide to Keycloak on AWS covers the setup, and Keycloak's own docs cover each protocol.
- Require MFA for everyone with access to sensitive dataHIPAA requires unique user identification, and the proposed Security Rule update would make MFA explicit. Sovereignty buyers will ask for it anyway.
- Connect each app as it goes liveChat, video, files, and mail clients should all authenticate against Keycloak, not their own local accounts.
- Make offboarding one actionDisabling a user in Keycloak should end their access everywhere. Test it with a real account before launch.
Where to Host It
The same software can pass or fail the sovereignty test depending on where it runs. HIPAA cares less about the country than about the BAA.
| Where it runs | Sovereignty | HIPAA |
|---|---|---|
| Your own hardware | Full, if you also operate it | No cloud BAA needed; physical safeguards are yours |
| An EU-owned provider | Strong: EU company, EU law | Only relevant for US PHI; few EU providers offer a HIPAA BAA |
| AWS European Sovereign Cloud | Partial: EU entity and staff, but US parent remains subject to CLOUD Act | Check which services and agreements it offers |
| A standard AWS or Google Cloud region | Weak: US company, CLOUD Act applies | Strong: BAA available, HIPAA-eligible services |
The AWS European Sovereign Cloud deserves scrutiny. It's physically and logically isolated within the EU, operated by EU-resident staff under a new German parent company, with identity management kept inside the EU. AWS personnel outside the EU have no technical means to access your content. But the underlying corporate parent is still a US company, and the addendum's language on governmental requests, while committing to challenge overbroad orders, doesn't claim immunity from US legal process. That's why it's "partial," not "full." For an EU ministry, the standard region fails outright; the sovereign cloud is a meaningful improvement but not a complete answer.
For a US clinic, a standard AWS region under the AWS BAA is a perfectly good home for this stack, and it's the setup our HIPAA voice agent guide assumes.
Where the Boundary Leaks
Self-hosting every server still leaves a few paths where content leaves your control. These are the ones auditors find.
Mobile push notifications
By default, Mattermost push notification content passes through Apple Push Notification Service (APNS) or Google Firebase Cloud Messaging (FCM) before reaching the device. If the notification carries message text, that text transits Apple's and Google's infrastructure. Mattermost's ID-only mode, where the phone fetches the message from your server, is an Enterprise feature, not a free-tier toggle. Use the most private option your edition supports.
Phone calls
The moment a call reaches the phone network, it's on a carrier's equipment. A carrier that only passes calls through may fall under HIPAA's conduit exception; the exception is narrow, limited to transmission services where access to PHI is random or infrequent. A carrier that records or transcribes is handling PHI and needs a BAA. For sovereignty, pick a carrier in your jurisdiction.
Email to outside recipients
Mail between your own users can stay on your server. Mail to anyone else crosses their provider. HHS allows unencrypted email to patients who have been warned of the risk and still prefer it. For everything else, use a secure link to a file in Nextcloud rather than an attachment.
Integrations, bots, and support access
A SaaS bot in a chat channel, an AI assistant reading messages, a backup copied to a foreign provider, or a vendor's engineer with SSH access: each one undoes the sovereignty layer it touches, and may need its own BAA.
Draw the boundary on paper before you build. List every path a message can take out of your servers, then decide for each one: block it, encrypt it, or accept it in writing.
Records, Retention, and Logs
A communications platform creates records in six places at once, and each app has its own retention setting. Set them deliberately.
Keep, and protect
- Sign-in and admin logs from Keycloak and every app
- Your HIPAA policies and risk analysis, for six years under 45 CFR 164.316(b)(2)(i)
- Backups, encrypted, in the same jurisdiction as the live data
Limit, and delete on schedule
- Meeting recordings and transcripts (most teams don't need them)
- Chat history beyond what your policy requires
- Message content in logs, error reports, and monitoring tools
GDPR's data minimisation and HIPAA's retention rules can pull in different directions. Settle that in policy, per channel, before you switch anything on.
A Rollout Order That Works
- Risk analysis or DPIAWrite down what data each channel will carry and who needs it. Every later choice traces back here.
- IdentityKeycloak with MFA, before any user-facing app.
- Chat and videoThe tools people use every hour. Move one team first and fix what they find.
- FilesNextcloud, with sharing rules set before the first upload.
- PhoneDial-in or a SIP trunk, once the carrier question is settled.
- Email lastIt's the hardest to move: MX records, DNS reputation, and years of mailboxes. Run it in parallel before you cut over.
Is a Self-Hosted Platform Worth It?
If someone in procurement is asking whose law applies to your communications, yes. No contract with a US provider fully answers that, and the organisations that have moved (France to Visio, built on LiveKit; Germany to openDesk; and the International Criminal Court off Microsoft Office after a sanctions-linked account suspension) all chose open source run inside their own jurisdiction.
If your only requirement is HIPAA, it's a closer call. A hosted suite under a BAA can be compliant and is less work to run. Self-hosting earns its keep when you want control over where data lives, what's logged, and who can reach the servers, or when per-seat licences across a large organisation add up.
Either way, start with identity and the leak list. Those are the parts that decide whether the platform actually passes, not which chat server you picked.
Frequently Asked Questions
What is a sovereign communications platform?
One where the software, infrastructure, operations, and encryption keys all sit under your jurisdiction's law, so no foreign government can compel access to your data.
Can one platform be both sovereign and HIPAA compliant?
Yes. Open-source tools on infrastructure you control can satisfy both, provided you have a BAA where needed and keep keys and operations in-jurisdiction.
Is Microsoft Teams sovereign if I use an EU data region?
Not fully. Microsoft is a US company, so the CLOUD Act applies regardless of where the data sits.
Which open-source tools make up the stack?
Keycloak for identity, Mattermost/Zulip/Element for chat, Jitsi or plugNmeet for video, Jigasi for phone, Nextcloud for files, mailcow for email, and Coturn for TURN relay.
Can a HIPAA covered entity email patients from a self-hosted server?
Yes, if patients have been warned of the risk and still prefer unencrypted email. For everything else, use a secure link instead of an attachment.
Do I still need a BAA if everything is self-hosted?
Not for your own hardware. You do need one for any cloud provider, SaaS integration, or vendor with access to ePHI.
What's the hardest part to make sovereign?
Email. MX records, DNS reputation, and years of mailboxes make it the slowest channel to move, and outside recipients' providers are always out of your control.
Planning a Sovereign or HIPAA-Ready Platform?
We deploy and run open-source chat, video, files, and email on infrastructure our customers control. Tell us which channels you need and where the data has to stay.
Talk to Meetrix