Most cloud vendor contracts are not written by lawyers who have read HIPAA, GDPR Article 20, or FedRAMP's continuous monitoring requirements. The BAA your cloud provider gives you covers the period of the engagement. It says nothing about what happens to your audit trails, your encryption keys, or your regulatory reporting chains when you leave. That is your problem, and it should be an architectural constraint from day one.
The BAA Termination Problem
When a Business Associate Agreement with a cloud provider terminates — whether through migration, provider exit, or contract dispute — HIPAA requires that the covered entity either retrieve or destroy all PHI held by the business associate (45 CFR §164.504(e)(2)(ii)(J)). "Retrieve" sounds simple. In practice, a healthcare organisation that has been operating in a cloud provider for five years has PHI in object storage, relational databases, caches, backup snapshots, log archives, and ML training datasets. Identifying all PHI locations, extracting it in portable formats, and verifying deletion from the provider's infrastructure is a multi-month project — not a BAA termination clause execution.
The portability problem is worse for audit trail data. HIPAA requires that audit logs be retained for six years. If those logs are in a proprietary format in the provider's log management service, exporting them in a format that can be queried five years after migration requires either maintaining access to the original provider or having exported in an open format during operations. Most healthcare organisations choose neither until they need to, at which point the option that was affordable during operations (ongoing export to open format) has become expensive remediation.
The GDPR data portability right (Article 20) gives data subjects the right to receive their personal data in a structured, commonly used, machine-readable format. This is a data subject right — but it creates an architectural obligation on the controller. If your cloud deployment uses proprietary data formats that cannot be exported in machine-readable form, you are creating a standing GDPR compliance exposure, not just a migration inconvenience.
Key Escrow and Encryption Continuity
Regulated data is typically encrypted at rest. The encryption keys are managed by a key management service — either the cloud provider's (AWS KMS, Azure Key Vault, GCP Cloud KMS) or a customer-managed HSM. When you exit a cloud provider, the keys managed by that provider's KMS are not portable. Data encrypted with AWS KMS customer master keys cannot be decrypted without AWS KMS — even if you have the ciphertext. The exit plan must address key re-encryption: decrypting data with provider-managed keys and re-encrypting with portable keys before migration, which requires maintaining access to both environments simultaneously.
The FedRAMP continuous monitoring requirement adds another dimension: your ATO is specific to your cloud architecture. Migrating to a different cloud provider or region requires either a new ATO or an approved significant change request — a process that takes 3-6 months. During the migration period, you may be running systems that are technically outside your authorized boundary. NIST SP 800-37 Rev 2's system authorization boundary definition must be updated to reflect the migration state.
Building Exit-Ready Architecture
- Use BYOK (Bring Your Own Key) for all encryption — store master keys in provider-agnostic HSMs (Thales Luna, AWS CloudHSM with exported key material), not in provider-managed KMS
- Audit log exports: configure all audit log streams to write to open-format immutable storage (S3 with WORM, Azure Immutable Blob) in addition to provider-native log services
- Data format standards: mandate open formats (Parquet, Avro, FHIR JSON, DICOM) for all regulated data storage — no proprietary formats without an export pipeline
- BAA exit clause: negotiate explicit data destruction timelines and format requirements for PHI retrieval into your BAA — the standard BAA addenda from major providers do not contain these terms
- Dependency mapping: maintain a live inventory of regulated data locations, classified by sensitivity — this is the prerequisite for any exit execution
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.