EU Data Residency and Key Custody for a Hospital Contract
Nordhaven Health provides patient-scheduling software. A German hospital chain will sign a €900,000/year contract only if all patient data - including backups and replicas - remains in the EU and the hospital retains control over the encryption keys. The platform currently runs in a single US region, relies on provider-managed encryption at rest, and writes nightly backups to a second US region. The provider offers an EU region, an HSM-backed key service supporting customer-supplied key material, and a 'sovereign' tier at 40% higher cost that guarantees EU-resident support staff. Engineering proposes moving only the compute tier to the EU and leaving backups in the US, arguing encrypted backups are 'not really processing'. The migration budget is €150,000 and the customer's security questionnaire is due in three weeks.
1. Assess engineering's proposal. Will it satisfy the customer and the applicable data-protection rules? Identify the flaw and state what actually has to move.
Read the worked answer
The proposal fails on both counts.
- Storing personal data is processing. A backup containing patient identifiers, appointment records, or contact details is in scope whether or not it is encrypted.
- Encryption at rest does not take data out of scope. Data encrypted with a key that the provider can retrieve remains personal data for the controller and processor; it is a security control, not an anonymisation technique.
- If the controller is the hospital and Nordhaven is the processor, the contract will require a data processing agreement, a sub-processor list, and a lawful transfer mechanism for anything leaving the EEA. An encrypted backup in a US region is exactly the transfer the customer is refusing.
What has to move, not just compute
- Primary storage and the database, plus snapshots.
- Backups and their replication target - use a second EU region for DR, not the US region.
- Logs, traces, and support telemetry, which routinely capture identifiers in URLs and error payloads.
- The key store and any provider service that silently replicates globally.
- The support-access model, because staff reading production data from outside the EU is an access concern independent of storage location.
Practical check
Walk the data-flow diagram end to end and verify no cross-region replication feature is silently enabled. Then answer the questionnaire with evidence, not intent.
2. Recommend a key-management design. Compare provider-managed keys, customer-managed keys inside the provider's HSM, and customer-held key material, and address revocation and loss.
Read the worked answer
The three options trade control against availability
- Provider-managed keys. Keys generated and held by the provider in a multi-tenant HSM. Lowest operational burden, no customer control over rotation or policy. Fails the 'we control the keys' requirement outright.
- Customer-managed key in the provider's HSM (BYOK). The customer owns the key policy, controls rotation, can disable the key, and gets an audit trail, while the key material sits in an HSM in the chosen EU region. This is usually the balance point: real control, no new availability dependency.
- Customer-held key material outside the provider (HYOK, or an external KMS reached over the network). Strongest control and it enables crypto-shredding on exit, because destroying the key destroys the data. The cost is a hard dependency: if the external KMS is unreachable, decryption stops and the service fails. Every decrypt becomes a network call, or a cached key that weakens the guarantee.
Recommendation
BYOK, with a separate key per tenant so the hospital chain's data can be cryptographically erased at contract end without affecting other customers. Put the key store in the same EU region as the data, and document a break-glass procedure with dual control.
Revocation and loss
- Disabling a key makes the data unreadable immediately - that is the point of the control, and it is also the biggest operational risk. Require multi-person approval and a scheduled-deletion window (days, not minutes) before key destruction.
- Decide explicitly whether key material is escrowed with the customer and where. If it is lost, the ciphertext is unrecoverable, so the DR runbook must cover the key store as a first-class dependency.
- Test restoring a backup using a rotated key before signing, not after.
3. Should Nordhaven buy the 40% sovereign tier? State the criteria you would use and give a recommendation.
Read the worked answer
Criteria
- Does the customer's DPA or works council actually require EU-resident support access, or is the requirement only about storage location?
- Under standard support, can a non-EU engineer reach production data or metadata? Read the access model, not the marketing page.
- What does €360,000/year against a €900,000 contract do to gross margin, and is the tier reusable across other EU customers who will ask the same question?
Recommendation
- Do not buy by default. First test whether standard support plus contractual and technical controls satisfies the customer: customer-approved access only, an EU-only on-call roster, session recording, no screen-sharing of production data, and a demonstrated audit log of every access.
- If the requirement is genuine and non-negotiable - for example, the hospital's regulator or works council demands EU-only personnel - then price it into the deal rather than absorbing it, and check whether the tier becomes a differentiator for the rest of the EU pipeline.
- Sequence matters: answer the questionnaire with the controls you can evidence in three weeks, and treat the sovereign tier as a priced option. Committing to a 40% cost increase to win a security questionnaire is how margin disappears.