Self-hosted customer identity for EU data sovereignty

A transfer impact assessment needs a map of where every copy of customer identity data sits, who can reach it from outside the EEA, and what third-country law could compel disclosure. For a self-hosted Keycloak, ZITADEL or Ory deployment, the inputs are the hosting region of the database, backups, logs and metrics stores, the list of people and support vendors with remote access, and the legal exposure of each supplier. The EDPB Guidelines 05/2021 treat remote access from a third country, even just viewing a screen, as a transfer, so support sessions must be in the assessment. This is evidence for your own assessment, not a certification.

Your records of processing should describe the purposes of the identity service, the categories of data (profile attributes, credentials, consent state, login metadata), the recipients, the transfers, the retention periods and the security measures. Map each category to the component that holds it, such as the realm database, the event store, the metrics endpoint and the backup set. Keep the record under your own control and review it whenever a realm, identity provider or sub-processor changes. Auditors use it as the starting point for every other question on this list.

Auditors will look for three things: where the data is stored, which administrative accounts can read it, and a log of when they did. In Keycloak, admin events and user events can be enabled in the realm settings and shipped to a central log store, and the database hosting region is documented in your infrastructure records. For ZITADEL, audit and action logs and the PostgreSQL host location serve the same purpose. Confirm the retention of these logs against your own policy, and confirm that the logs themselves stay inside the EU region where you claim the data sits.

Consent records should capture who consented, to which purpose and wording version, when, through which channel, and whether consent was later withdrawn. Store consent as attributes or in a dedicated consent service linked to the user identifier, and write an event each time it changes. Withdrawal must be as easy as giving consent, so test that the withdrawal path updates the same record. Keycloak user events and custom attributes, or ZITADEL user metadata and actions, can carry this data, but confirm with your legal team which schema meets your consent obligations.

Each erasure and portability request should show when it was received, who verified the requester, what data was exported or deleted, which systems were touched, and when the response was sent. For a self-hosted identity platform, the evidence comes from the admin event trail, the export output from the user management API or SCIM records, and a checklist that covers downstream applications and backups. SCIM provisioning records help show that deprovisioning reached connected applications. Ask your engineers to test a full erasure in a staging copy and keep the test results.

A backup deletion procedure describes how erased data is removed from backups or how backups expire, and how the restore process avoids bringing erased users back. Document the backup schedule, retention window, encryption, the restore runbook, and the step that reapplies erasure after a restore. Database backups of Keycloak or ZITADEL PostgreSQL instances usually hold the full identity store, so the retention period is the main factor a data protection authority will test. Confirm retention periods with your backup vendor or operations team, because they set how long personal data survives after a request.

Auditors will ask for a data processing agreement with each supplier, a current list of sub-processors with their locations, transfer mechanisms such as standard contractual clauses where they apply, and evidence that you were notified of changes. Open-source software itself is not a processor, but any hosting provider, managed database, support firm or implementation partner that touches the data is. Ask each supplier to state where support staff access data from and whether they can be compelled by third-country authorities, then record those answers in your assessment. Legal review of these terms is your responsibility, and the contract is the document an auditor will read first.

Cost follows scope: how many customer populations, applications and identity providers you connect, how many existing accounts must move, and how the platform is made highly available. Self-hosting shifts spending from a per-user subscription to recurring infrastructure in your own EU cloud account or data center, plus one-time implementation work. Ask any partner to price the migration, the identity provider connections, the high availability design and a support retainer as separate lines, so you can see which costs recur and which are one-time.

A capable platform team can run Keycloak or ZITADEL alone, but the first build usually needs skills that are scarce in most teams: database and clustering design, protocol configuration, upgrade planning and security hardening. Many organizations split the work, keeping day-to-day operation in house and buying implementation, hardening and upgrade support on a fixed-scope basis. Check whether your team has staff on call for login outages, and who will apply vendor security releases within your change window.

Legal must confirm the lawful basis for each processing purpose, the transfer position for any remaining third-country access, and the contract terms with every processor, including the hosting provider and any support vendor. Security must approve the data flows, encryption, key custody, administrator access and logging. Both teams should sign off the consent model and the erasure and export procedures before go-live, because changing them after users have registered is costly.

Duration depends on the number of user records, the password hashing formats you must carry over, the number of applications that must switch to new login flows, and how many customer organizations bring their own identity providers. Each of these adds testing and cutover planning. Ask for a written schedule that separates design, build, parallel running and cutover, and confirm how the plan handles a staged rollout by customer group. No general duration applies to every organization, so treat any single figure with caution until it is tied to your inventory.

Both are open source, can be self-hosted in EU infrastructure and support OpenID Connect and SAML. Keycloak is a mature option with a large community, broad protocol coverage and documented high availability designs that need a synchronously replicated database. ZITADEL offers instances as isolated virtual tenants, organizations per customer, passkeys and SCIM provisioning in the product, and is licensed under AGPL-3.0, which the team must review. Choose after testing your B2B tenancy model, passkey requirements and license obligations against real use cases.

The move should copy customer records into your EU environment under a documented plan, then stop the old service's processing and confirm deletion or return of records under your contract. Plan for the data in logs, backups and replicas, not just the primary store. Password hashes often need a migration path that avoids forced resets. Ask the provider for its export format and notice terms, and check the data processing agreement for sub-processors that could still access the data. Confirm the exit steps with counsel before cutover.

After go-live, the recurring work is patching, upgrades, monitoring, backup testing, incident response and periodic reviews of consent and erasure processes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most implementation work is agreed as a fixed scope with written deliverables before it starts. Ask any partner which upgrades are included, how they handle the Keycloak operator's manual approval mode or ZITADEL release changes, and what response expectations apply to your environment.