Your Task API agent is working well. Velero backs it up nightly. Chaos Mesh confirms it recovers from failures. Then your sales team closes a deal with a German healthcare company, and you get a message from legal: "We need to discuss GDPR compliance for the backup infrastructure."
Suddenly, technical decisions about where S3 buckets live become legal decisions. The backup storage location you chose for convenience might violate data residency laws. The audit logs you never configured might be required for compliance certification. The encryption you assumed was "good enough" might not meet regulatory standards.
Data sovereignty transforms backup strategy from "store it somewhere reliable" to "store it where the law allows, prove you did it correctly, and encrypt it to specific standards." This lesson explains what data sovereignty means, how it affects your Velero backup configuration, and what audit trails you need to demonstrate compliance.
Data sovereignty is the principle that data is subject to the laws of the country where it physically resides. When your Kubernetes backup sits in an S3 bucket in Virginia, US law governs that data. When the same backup sits in an S3 bucket in Frankfurt, German and EU law governs it.
This matters because different jurisdictions have different rules about:
The core question for disaster recovery: Where does your backup storage physically exist, and what laws apply there?
The General Data Protection Regulation (GDPR) is the EU's data protection law. It affects any organization that processes data of EU residents, regardless of where the organization is based. If your Task API has users in Germany, GDPR applies to you even if your company is in California.
Data Residency: GDPR doesn't require data to stay in the EU, but transferring data outside the EU requires legal mechanisms. Since the Schrems II ruling in 2020, transfers to the US require additional safeguards beyond the standard contractual clauses that were previously sufficient.
Practical impact: If your Velero backup storage is in a US region and your application processes EU personal data, you need legal review. Many organizations choose the simpler path: keep EU data in EU regions.
Right to Erasure (Article 17): Users can request deletion of their personal data. This includes data in backups. You need a process to either delete specific records from backups or document why full deletion isn't technically feasible.
Data Protection by Design (Article 25): Encryption isn't optional. Backups containing personal data must be encrypted at rest and in transit. The encryption must be "appropriate to the risk."
For GDPR compliance, the safest approach is geographic isolation:
For Velero, this means configuring separate BackupStorageLocation resources for each region:
EU backup location (conceptual configuration):
US backup location (conceptual configuration):
The key insight: backup location isn't just about latency or cost. It's about legal jurisdiction.
GDPR is the most discussed regulation, but it's not the only one affecting backup strategy:
The pattern: Every regulation requires encryption, most require audit trails, many specify retention periods or deletion capabilities.
What this lesson covers vs. doesn't cover:
Regulatory compliance almost universally requires encryption. But "encrypted" isn't a binary state. Compliance requires specific encryption configurations.
Data stored in backup files must be encrypted. For Velero with S3-compatible storage:
Server-Side Encryption (SSE): The storage provider encrypts data when it's written. Options include:
For most compliance scenarios, SSE-KMS provides the right balance: AWS manages encryption operations, you control keys and policies, and you get audit logs of key usage.
Data moving between your Kubernetes cluster and backup storage must be encrypted. This typically means:
Encryption is only as strong as key management. Compliance requires:
Encryption protects data. Audit trails prove you protected it. When a compliance auditor asks "Who accessed this backup on March 15?", you need an answer. When a regulator investigates a breach, you need logs showing what happened.
Backup operations:
Restore operations:
Access to backup storage:
Kubernetes has built-in audit logging that captures API server activity. For backup compliance, you need logs showing:
The audit policy determines what gets logged. For compliance, you typically need at least Metadata level logging for backup-related resources and Request or RequestResponse for sensitive operations.
Velero generates detailed logs for each backup and restore operation. These logs show:
For compliance, these logs should be stored in a separate, tamper-evident location (not just the Velero pod logs that rotate and disappear).
S3 and compatible storage systems can log all access requests. Enable server access logging to capture:
These logs go to a separate bucket that the backup system cannot modify, providing tamper-evident access records.
Technical teams often approach compliance as a checkbox exercise: "Enable encryption. Done." But compliance is actually about demonstrating a system of controls:
Design: Document why you made specific choices (EU region for GDPR, SSE-KMS for key control)
Implement: Configure systems according to documented design
Monitor: Continuously verify that controls are working (audit logs, compliance dashboards)
Respond: Have procedures for when things go wrong (data breach notification, audit response)
The backup configuration is just one piece. Compliance requires the full lifecycle: design documents, configuration evidence, ongoing monitoring, and incident response procedures.
Real-world applications often have users in multiple jurisdictions. A multi-region backup strategy addresses this:
Region affinity: Route user data to the appropriate region based on user location or preference. Backups inherit this affinity.
Separate backup locations: Configure Velero with multiple BackupStorageLocation resources, one per compliance region.
Namespace organization: Consider organizing namespaces by compliance region (e.g., production-eu, production-us) to simplify backup targeting.
Retention differences: Different regulations may require different retention periods. EU data might have shorter retention (purpose limitation), while US financial data might require 7+ years.
These prompts help you apply data sovereignty concepts to your own deployment scenarios.
Prompt 1: Compliance Requirements Analysis
What you're learning: How to analyze your application's data to determine which regulations apply and how they affect infrastructure decisions. AI helps you think through the regulatory landscape before making technical choices.
Prompt 2: Audit Trail Design
What you're learning: How to design audit infrastructure that satisfies compliance requirements. AI helps you map compliance needs to specific Kubernetes and cloud logging configurations.
Prompt 3: Encryption Review
What you're learning: How to identify compliance gaps in existing configurations. AI helps you analyze configurations against regulatory requirements and prioritize necessary changes.
Safety note: This lesson provides educational guidance on compliance concepts. Actual compliance certification (GDPR, HIPAA, SOC2) requires legal counsel and may require third-party auditors. Use this material to understand concepts and ask informed questions, not as legal advice.
You built an operational-excellence skill earlier in this chapter. Test and improve it with data sovereignty knowledge.
Ask yourself:
If you found gaps: