Residency or sovereignty: two different questions
When you buy an e-signature API, you almost always hear the same sentence: "Our servers are in the EU." That is usually true and still not the answer your customers ask. Data residency describes where data physically sits. Data sovereignty describes who controls it and which law can reach the operator. A data centre in Frankfurt answers the first question; the second stays open once the operator belongs to a group outside the EU.
For software vendors this distinction is not academic. Law firms, clinics, public bodies and financial services increasingly ask for ownership and access rights in RFPs. Naming only the location invites follow-up questions, and in the worst case a deal fails for an answer that could have been given in a few words.
The Cloud Act in one sentence
The US CLOUD Act (bill text at the US Congress) can, under certain conditions, oblige US providers to produce data they control even when it sits on servers outside the USA. How far that reaches in a given case is legally complex. For buying decisions the core is enough: server location alone does not protect against third-country law if the operator is subject to that law. We cover the GDPR interplay in depth in GDPR vs US Cloud Act for e-signature APIs.
Sovereign operations as the answer for the signature API
Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems. Operations sit with a European provider under European law. That lets you answer the ownership question briefly and in a way that can be checked—exactly what regulated customers expect. This is not a certification and not a guarantee against every risk, but a clean basis for security documentation and processing agreements.
Role clarity matters for the signature itself: Sign2x is the API layer for SES, AES and QES. We are not a qualified trust service provider; QES qualification runs through a partner QTSP such as Sign8. Legal foundations of the levels are in the eIDAS Regulation; security guidance is available from the BSI.
Read next: deeper articles on sovereign signing
This post is deliberately a short overview. For depth we recommend:
- Open Sovereign Cloud for the e-signature API
- Cloud Act and Open Sovereign Cloud for e-signatures
- White-label e-signature on the Open Sovereign Cloud
- eIDAS signatures in the sovereign cloud
- DORA Article 30 and the signature audit trail
To map your own situation first, use the Sign2x Quiz. Technical basics are in the Developer Hub, terminology in the Help Center, practice cases under Use Cases, and more articles in the Sign2x Blog. For a conversation about requirements, use Contact.
Map sovereignty with the Sign2x Quiz
FAQ
Is an EU data centre enough for data sovereignty?
No. Location only answers where data sits. What matters is who controls the operator and which law can reach them.
What does the US Cloud Act regulate?
It can, under certain conditions, oblige US providers to produce data they control even when stored outside the USA. Reach in a given case is legally complex.
Where is Sign2x hosted?
On the Open Sovereign Cloud (OSC) from T-Systems, European operations under European law.
Is OSC hosting a certification?
No. It is a statement about platform operations and jurisdiction and replaces neither your own privacy review nor compliance evidence.
Is Sign2x a qualified trust service provider?
No. Sign2x is the API layer for SES, AES and QES. For QES, qualification runs through a partner QTSP such as Sign8.
