What does digital sovereignty mean?

An organization's ability to decide independently about its data, technology and IT operations – without legal, technical or economic dependency on individual vendors or third countries.

How do you achieve digital sovereignty in practice?

In six steps: take stock, assess risks, define binding sovereignty criteria, select providers, migrate step by step and review continuously through audits and export tests.

What is a sovereign cloud?

A cloud environment with a European legal entity, storage and processing in the EU, operations and support from within the EU, and full customer control over keys, configuration and data export.

What does data sovereignty mean?

The right and technical ability to decide at any time who accesses your data, where it is processed and in which form it can leave the system.

Where is my data stored?

Exclusively in our own ISO/IEC 27001-certified data centre in Germany (Ahaus, Münsterland) – with no data transfer to third countries.

What does the US CLOUD Act mean for European companies?

US companies must hand over data on request from US authorities – regardless of storage location and including their European subsidiaries.

What does the Schrems II ruling mean for cloud services?

Data transfers to the US require additional safeguards and case-by-case assessments. Processing exclusively inside the EU avoids these obligations.

What makes a cloud GDPR compliant?

A data processing agreement under Art. 28 GDPR, documented technical and organisational measures, transparent sub-processors, clear retention periods and a complete data export.

What role do Gaia-X and BSI IT-Grundschutz play?

Gaia-X provides a European framework for interoperable cloud services, BSI IT-Grundschutz concrete building blocks for technical and organisational protection.

Is there a sovereign alternative to Microsoft 365?

xworks.365 covers email, calendar, contacts, files, document editing and video conferencing in one integrated platform – operated by a German company in Germany.

How do I avoid vendor lock-in?

Open standards (IMAP, SMTP, CalDAV, CardDAV, WebDAV), open document formats and a complete self-service export – contractually settled during selection.

Case study · model scenario

Digital sovereignty in a public authority with 850 workplaces

A fully worked model scenario: how a public administration moves from a US cloud to a sovereign platform with xworks.365 – with disclosed assumptions, architecture and traceable metrics.

Note: this is a model scenario, not a real customer reference

The “model city” shown here is a constructed example organisation. All figures are model calculations based on the assumptions disclosed below – they are not measured results from a specific customer and not a guarantee. Your actual values depend on user count, licence mix, data volume and migration effort. Talk to us for a calculation with your own numbers.

Starting position of the model organisation

We assume a mid-sized municipal administration with a classic departmental structure and a mixed device fleet.

Organisation

Municipal administration, 12 departments

Workplaces

850 (180 mobile / field staff)

Mailboxes

850 personal, 60 shared function mailboxes

Data volume

14 TB file storage, 9 TB email

Legacy platform

US hyperscaler suite plus on-premise file server

Drivers

CLOUD Act, Schrems II, council resolution on sovereignty

Project objectives

Legally sound data residency

All primary, backup and log data in Germany, operated by a German legal entity without extraterritorial access.

One platform instead of a tool zoo

Email, calendar, contacts, files, document editing and video conferencing consolidated – reducing shadow IT.

Keep systems interoperable

Open standards (IMAP, SMTP, CalDAV, CardDAV, WebDAV) and line-of-business integration without proprietary connectors.

Switch without service interruption

Migration during regular public office hours, department by department, with parallel operation in the transition phase.

Architecture in the model scenario

The target setup follows the four-layer model of xworks.365 – every layer stays under German operational responsibility.

Layer 1

Access layer

Browser interface, desktop and mobile clients plus standard protocols (IMAP/SMTP, CalDAV, CardDAV, WebDAV) for existing clients. No external CDNs or trackers are loaded.

Web clientOutlook/Thunderbird via IMAPiOS/Android via CalDAV & CardDAVWebDAV drive

Layer 2

Application layer

The platform services: carrier-grade mail system, calendar and tasks, cloud storage with file groups, Euro-Office for collaborative document editing, and video conferencing.

Email & groupwareCloud storageEuro-OfficeVideo conferencing

Layer 3

Security and identity layer

Role and permission model along departmental lines, tenant separation, two-factor authentication, encryption in transit and at rest, audit-ready logging.

Roles & permissions2FAEncryptionAudit logs

Layer 4

Infrastructure layer

Operated in German high-security data centres with redundant sites, geo-redundant backup and ISO/IEC 27001-certified information security management.

German data centresGeo-redundancyISO 27001BSI baseline alignment

Data flow and integrations

Line-of-business systems

Connected via REST APIs and an SMTP relay – notices and notifications go through your own platform instead of external delivery services.

Directory service

Users, groups and departmental structures are taken from the existing directory; roles mirror the organisational chart.

External communication

Share links with expiry dates and password protection for citizens and external service providers – no account required on the recipient side.

Migration in four phases

Phase 1 · weeks 1–4

Inventory and target picture

Survey of mailboxes, file shares, line-of-business systems and interfaces. Definition of the role model per department and of retention rules.

Phase 2 · weeks 5–8

Pilot with two departments

Around 90 workplaces in parallel operation. Testing mail routing, calendar sharing, document editing and mobile access.

Phase 3 · weeks 9–20

Wave migration

Department by department migration of mailboxes and file storage in waves of roughly 100 workplaces, each with a short training session and an office hour.

Phase 4 · weeks 21–24

Decommissioning and evidence

Shutdown of legacy systems, export and deletion records, updates to the record of processing activities and the data protection impact assessment.

Measurable outcomes in the model

All values are calculated model results for the example organisation described above – the calculations are shown below.

100 %

Data in Germany

Primary data, backups and logs remain in German data centres; support is delivered from Germany.

Tools consolidated

Mail, calendar, file storage, document editing, file sharing and video conferencing run on one platform instead of six separate services.

Weeks to decommissioning

Four phases from inventory to legacy shutdown, without interrupting public service operations.

850

Workplaces in 9 waves

A pilot with 90 workplaces, followed by eight waves of around 95 workplaces during normal operations.

Third-country transfers

No processing outside the EU, so no transfer impact assessment under Schrems II is required.

23 TB

Data volume migrated

14 TB of file storage and 9 TB of email, transferred via standard protocols instead of proprietary export tooling.

Transparency

Assumptions and calculation

To keep the numbers verifiable, here are the underlying assumptions. Replace them with your own values to transfer the model to your organisation.

User count: 850 workplaces, including 60 shared function mailboxes without their own licence.
Wave size: 850 workplaces minus 90 in the pilot leaves 760, spread across 8 waves of roughly 95.
Project duration: 4 + 4 + 12 + 4 weeks per phase, 24 weeks in total without buffer time.
Data volume: 14 TB file storage (approx. 16.5 GB per workplace) and 9 TB email (approx. 10.6 GB per mailbox).
Tool consolidation: Six previously separate services are counted as absorbed into the platform. Line-of-business systems remain unchanged.
Not included: Costs for end devices, network connectivity, internal staff effort and custom adaptations to line-of-business systems.

Transferable lessons

Make sovereignty verifiable up front: put legal entity, data location, support location and key custody in writing.
Settle the exit during procurement, not at termination – a complete self-service export belongs in the specification.
Define the role model before migration; correcting permissions afterwards costs more than the data transfer itself.
Prefer standard protocols: IMAP, CalDAV, CardDAV and WebDAV keep legacy clients usable during parallel operation.
Migrate in waves and offer an office hour per wave – this noticeably lowers ticket load compared with a big-bang cutover.
Update the record of processing activities and the impact assessment right after decommissioning, while details are fresh.