TR-C study materials
TR-C study resources

Data Residency and Key Management for a Multi-Tenant SaaS

TR-C · Put your knowledge to work in context.

All case studies

Data Residency and Key Management for a Multi-Tenant SaaS

A SaaS provider stores personally identifiable information for 2,000 tenants in a shared multi-tenant PostgreSQL database hosted in us-east. About 30% of tenants are in the EU. A new EU enterprise contract requires data residency in the EU, encryption at rest with customer-managed keys (CMK), and audit-log retention of one year. The current platform uses provider-managed AES-256 encryption at rest and retains audit logs for 90 days. The company has six months to comply with the contract. One existing tenant has also invoked a right-to-erasure request that includes backups. The engineering team proposes copying the entire database to an EU region and adding a per-tenant key column. Legal and security must assess gaps, prioritize remediation, and define governance so that residency, key custody, audit retention, and erasure are provable.

1. Perform a gap assessment against the four requirements and prioritize remediation by risk and contract deadline.

Read the worked answer

There are four gaps. Data residency: the shared us-east database stores EU tenant PII outside the EU, a contract and regulatory breach. CMK: provider-managed keys do not give the customer key custody or independent revocation. Audit retention: 90 days is short of the one-year requirement. Erasure: backups are not addressed, so a deletion request cannot currently be completed with evidence.

Prioritize residency and CMK first because they are contract blockers and carry the highest regulatory risk. In month 1-3, deploy an EU cluster and tenant routing, and stop replicating EU PII to us-east. In month 3-4, introduce envelope encryption with customer-managed keys. In month 4-6, extend audit logs to immutable one-year storage and implement a tested erasure procedure that covers backups. The existing erasure request should be handled under legal direction as a priority workstream, not deferred to the end. Copying the entire database to the EU is not sufficient because it creates a new residency problem for non-EU tenants and may replicate PII across regions.

2. Design the tenancy, regional routing, and key-management architecture. Explain how you avoid cross-region PII replication.

Read the worked answer

Use a global control plane that stores only tenant ID, home region, and non-sensitive configuration. Each region has its own PostgreSQL cluster and object storage. API requests resolve the tenant's home region and route there; EU tenants are pinned to the EU cluster. Do not replicate PII across regions. Backups stay in the same region and are encrypted with regional keys.

Use envelope encryption: each tenant has a data key, and the data key is wrapped by a regional customer-managed key in the cloud KMS. Store only the wrapped key and key ID in tenant metadata. Decrypt data keys in memory only, and log key usage to the audit pipeline. Key rotation re-wraps data keys without re-encrypting all tenant data. For the CMK requirement, give the customer control of the regional key policy and revocation. Tokenize or remove non-essential PII from logs and analytics. Enforce row-level security by tenant ID as defense in depth.

3. Propose a defensible right-to-erasure approach that covers backups, and the governance evidence you would retain.

Read the worked answer

Use crypto-shredding for encrypted tenant data: delete the tenant's data key and mark it irreversible. Without the key, primary data and backups become unreadable, which satisfies erasure without rewriting every backup. Also delete or tombstone row-level records that are not encrypted, and let backup retention expire naturally. Test the process on a non-production tenant and verify that a restored backup cannot decrypt the tenant's data.

Retain evidence: the approved erasure ticket, the key-deletion event and KMS audit log, the backup catalog showing the tenant's encrypted objects, the restore test result, and legal sign-off. Record the date and scope of deletion, including replicas and caches. Document any legal-hold exception before deletion. Governance should include a data processing agreement, records of processing, access reviews for keys, one-year immutable audit logs, and a quarterly test of the erasure workflow. This makes residency, key custody, retention, and erasure provable to the customer and auditor.