7 Data Privacy Practices for Cloud Workloads

Data privacy in the cloud is a topic that attracts a lot of vague advice. "Encrypt everything" is true but not useful. "Know where your data lives" is true but not useful. Here are seven practices that are both true and useful — the specific controls we implement for customers who are serious about privacy, not just the ones who want to check a box.

1. Encryption at Rest: Default On, BYOK for Sensitive Data

Every major cloud provider encrypts storage at rest by default. If you've done nothing, your data is encrypted with vendor-managed keys. That's fine for most workloads and inadequate for a few.

When vendor-managed keys are fine: Internal tools, non-regulated data, anything where "Microsoft/AWS/Google can technically decrypt this" is acceptable.

When you need customer-managed keys (CMK): Regulated data (PHI, PCI, CJIS), anything under contractual data protection requirements, workloads where the business impact of a cloud-level key compromise would be material.

When you need BYOK or HYOK (Hold Your Own Key): Extremely sensitive workloads where you want the ability to revoke cloud access to your data entirely. The key lives in your HSM, the cloud borrows it at runtime, and if you pull the key the cloud cannot read your data. Rare, but real for some customers.

Azure Key Vault Premium, AWS KMS with CloudHSM, and Google Cloud KMS with Cloud HSM all support these patterns. The complexity is higher than vendor-managed keys. Use it where the risk justifies it.

2. Encryption in Transit: TLS 1.2 Minimum, Prefer 1.3

TLS 1.0 and 1.1 are dead. Disable them. TLS 1.2 is acceptable for legacy clients but TLS 1.3 is faster and cleaner.

Specifics that matter:

• Certificate management: Use an automated process (cert-manager in Kubernetes, AWS Certificate Manager, Azure Key Vault certificates). Manual cert rotation is how outages happen.
• HSTS headers: Set them on public endpoints with preload.
• Mutual TLS for internal traffic: Between services that should trust each other, mTLS is a significant security upgrade over "assume the network is trusted." Service meshes (Istio, Linkerd) make it practical.
• Database connections: Require TLS on every database connection. "Internal VNet traffic is safe" is not true if an attacker gets inside.

3. Key Rotation That Actually Happens

A key that never rotates is not as secure as a key that rotates quarterly. A key that rotates automatically is better than one that rotates when someone remembers.

Use the cloud provider's automatic key rotation. AWS KMS, Azure Key Vault, and Google Cloud KMS all support it. Set it to annual minimum, quarterly for sensitive workloads.

Watch out for: Applications that cache keys and break when they rotate. The fix is to use envelope encryption — the app caches a data encryption key, and only the key encryption key rotates.

4. Data Classification That Informs Controls

Not every piece of data needs the same level of protection. Classifying data by sensitivity lets you apply expensive controls (HSM-backed keys, strict access, extensive logging) to the data that needs it without crippling the rest.

A simple classification scheme that works:

• Public: Marketing, public documentation. Default cloud encryption is fine.
• Internal: Employee data, internal documents. Standard cloud encryption with RBAC.
• Confidential: Customer data, business-sensitive documents. CMK, access logging, DLP controls.
• Regulated: PHI, PCI cardholder data, regulated financial data. CMK ideally HSM-backed, strict network segmentation, comprehensive audit logging.

Tag cloud resources with their classification. Enforce different policies per classification automatically.

5. Data Residency and Sovereignty

Know where your data lives, which laws apply to it, and whether your cloud vendor can move it without telling you.

Practical guidance:

• For EU personal data, use EU-only regions and ensure your vendor's sub-processors are also in-scope. Standard Contractual Clauses are table stakes since Schrems II.
• For Canadian data subject to PIPEDA provincial laws (particularly BC and Nova Scotia), verify the vendor's support and backup locations, not just the primary region.
• For Australian government data, check the IRAP certification level.
• For US CJIS or ITAR data, you need restricted-access regions (Azure Government, AWS GovCloud).

Data residency is usually about where the data lives at rest. Data sovereignty is about whose courts can subpoena it. They're related but different; the cloud vendor's physical region addresses residency but not sovereignty.

6. Data Minimization and Retention Limits

The most private data is the data you don't have. Before you build controls around data, ask whether you need the data at all.

Concrete steps:

• Delete old data. Enforce retention policies automatically. If you don't need the data from five years ago, don't keep it. Regulatory minimum retention is not a target.
• Anonymize where possible. Analytics that use aggregated data don't need raw user records.
• Limit field-level collection. If you don't need date of birth, don't collect date of birth.
• Short-lived logs. Logs contain surprising amounts of PII. Rotate them out on a schedule and scrub sensitive fields at write time.

The GDPR "right to erasure" is dramatically easier to support if you've been deleting old data all along.

7. Audit Logging That Catches Exfiltration

The privacy control that matters most during an incident is the one that tells you what was accessed. Logs that capture API calls are necessary but not sufficient. You also want logs that capture data access patterns — queries against databases, file reads from object storage, bulk exports.

What we enable for privacy-sensitive workloads:

• Database audit logs at the row level where the platform supports it
• Object storage access logs with full request detail
• Alerts on bulk operations (mass download, bulk query, unusual export sizes)
• Alerts on geographic anomalies (access from countries you don't operate in)
• Retention of audit logs for at least the regulatory minimum, in immutable storage

The goal is not perfect prevention. The goal is that if something bad happens, you can reconstruct what happened and notify the people who need to be notified.

What We'd Actually Do

For a typical customer handling some regulated data:

1. Enable CMK for all regulated storage. Pull keys into a separate Key Vault or KMS account.
2. Tag every resource with a data classification. Enforce via policy.
3. Implement TLS 1.3 everywhere, including internal. Retire TLS 1.1 endpoints with a hard deadline.
4. Set up automated retention. Delete what you don't need.
5. Centralize audit logs in an SIEM with alerting on bulk access patterns.

Three Takeaways

1. Customer-managed keys are the most under-used high-leverage privacy control. Default vendor keys are fine for most workloads but not for sensitive ones.
2. Data you don't have can't leak. Minimization is the most underrated privacy strategy.
3. Audit logs are how you respond to a breach. Invest in them before you need them.