Data Protection & Tenant Isolation

1. Segregate Sensitive Data Categories From General Account Data

Health, payment, and other high-sensitivity fields live in their own tables (or a separate data store entirely) rather than mixed into general-purpose user/account tables — so access to "the users table" doesn't automatically mean access to health metrics or payment details.

users table: id, email, display_name
health_metrics table (separate, stricter ACL):
user_id (FK), weight, height, recorded_at

2. Encrypt Highly Sensitive Fields Separately, With Their Own Keys

Beyond default at-rest encryption for the whole database, fields carrying health or payment data get their own application-level (column/field) encryption with a dedicated key — so a database-level compromise doesn't hand over the most sensitive data along with everything else.

health_metrics.weight stored via
KMS envelope encryption, separate CMK from
the general database encryption key

3. Maintain a Data Inventory and Document Data Residency

Know, in one place, what categories of data you store and which country or region the servers holding them live in — this is the first thing any client security review or data-processing agreement asks for, and it shouldn't require an engineer to go find out.

Data inventory doc: field → sensitivity →
storage location (e.g. "payment tokens: Stripe,
US-East; health metrics: RDS, us-east-1")

4. Tenant Isolation for Multi-Client Infrastructure

When multiple clients' data lives on shared infrastructure, enforce isolation in the data layer itself — a tenant ID scoping every query, row-level security, or separate schemas per client — so no application bug can make one client's data reachable through another's session.

Postgres row-level security policy:
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id'));

5. Database Backup

• Enable automated backups for RDS / Aurora with a retention period of at least 7 days
• Enable cross-region backup replication for critical databases
• Enable DynamoDB point-in-time recovery (PITR)

6. File Upload Backup (S3)

• Enable S3 Versioning on all buckets containing critical data
• Enable S3 Object Lock (WORM) on backup buckets
• Enable S3 Cross-Region Replication (CRR) for critical file storage
• Implement lifecycle policies to move old backups to cheaper storage (Glacier/Deep Archive)
• Avoid storing backups in publicly accessible S3 buckets

7. File Upload Backup (Google Cloud)

• Enable Object Versioning
• Enable Object Lifecycle Management (move old versions to Nearline/Coldline/Archive)
• Enable Retention Policy (Object Lock / WORM)
• Enable Cross-Region Replication
• Use Google Cloud Backup and DR
• Enable Bucket Logging

8. File Upload Backup (Azure)

• Enable Blob Versioning
• Enable Soft Delete (for blobs and containers)
• Enable Immutable Storage (WORM)
• Enable Geo-Redundant Storage (GRS or GZRS)
• Use Azure Backup for blobs
• Enable Lifecycle Management
• Enable Point-in-Time Restore (preview)