PII Classification, Field-Level Design, Logging Redaction, Backups, Exports, and Right-to-Delete Workflows

1. AtlasMart problem: deleting the primary record is not the same as deleting the person’s footprint

A customer invokes AtlasMart’s account-deletion workflow. The application deletes profiles/u123, but the same email address appears in orders, support notes, debug logs, an export bucket, a recovery backup, and an analytics table. A “right to delete” workflow therefore needs an inventory of data copies, policy-based exceptions, evidence, and asynchronous follow-up—not a single Firestore delete().

2. Classification drives controls

Classification is organization-specific. The lesson uses labels to make the control mechanism visible; it does not claim that a field has a universal legal classification.

3. Field-level design: collect less, duplicate intentionally

Every duplicated personal field multiplies deletion and breach-response work. If orders need an immutable shipping snapshot for business/legal reasons, document that purpose and retention class explicitly. Do not duplicate current profile email into every telemetry event just because denormalization is convenient.

{  "profiles/{uid}": {    "email": {"class":"personal", "purpose":"account-contact", "retention":"account-life"},    "displayName": {"class":"personal", "purpose":"display", "retention":"account-life"}  },  "orders/{id}": {    "customerId": {"class":"pseudonymous-id", "purpose":"ownership", "retention":"order-policy"},    "shippingSnapshot": {"class":"personal", "purpose":"fulfillment", "retention":"order-policy"}  },  "events/{id}": {    "customerId": {"class":"pseudonymous-id", "purpose":"product-analytics", "retention":"30d"},    "email": {"forbidden":true}  }}

4. Log redaction is an application control, not a Firestore feature

Cloud Logging can provide powerful audit/operational evidence, but logs become another data store. Never log raw tokens, Authorization headers, service-account key material, or whole customer documents for convenience. Redact before emission so accidental sinks/exports inherit the safer payload.

const SENSITIVE_KEYS = new Set([  "authorization", "token", "idToken", "refreshToken",  "email", "phone", "shippingAddress", "serviceAccountKey"]);function redact(value) {  if (Array.isArray(value)) return value.map(redact);  if (!value || typeof value !== "object") return value;  return Object.fromEntries(Object.entries(value).map(([k,v]) =>    [k, SENSITIVE_KEYS.has(k) ? "[REDACTED]" : redact(v)]  ));}const event = {action:"order.view", email:"synthetic@example.invalid", token:"secret", orderId:"o-1001"};console.log(JSON.stringify(redact(event)));

Add tests that assert known secret/PII patterns are absent from emitted log objects. Redaction that relies only on operators remembering not to log data is not a control.

5. Deletion is an inventory workflow with states

A backup is intentionally immutable historical evidence. If policy allows retention until scheduled expiry rather than immediate mutation, the deletion workflow should record that deferred scope and the time when the copy becomes inaccessible. Do not promise immediate erasure from systems whose mechanism does not provide it.

6. Legal hold must defeat automated deletion by design

Chapter 21 established that TTL is asynchronous and unsuitable as a legal-retention engine. Model a hold explicitly. A deletion request first resolves policy: if a valid hold exists, the system records the request and blocks destructive actions for the held scope; if no hold exists, the workflow proceeds. Avoid sprinkling one legalHold boolean across unrelated collections without an authoritative owner and release process.

{  "requestId": "del-u123-20260917",  "subjectId": "u123",  "state": "IN_PROGRESS",  "policyVersion": "privacy-retention-v4",  "scopes": {    "profile": "DONE",    "orders": "ANONYMIZED",    "events": "TTL_PENDING",    "exports": "OBJECT_DELETE_QUEUED",    "backups": "RETAIN_UNTIL_2026-11-01",    "analytics": "JOB_PENDING"  },  "hold": null}

7. Failure injection: primary-only delete falsely reports success

Seed a synthetic subject into six local fixture stores: Firestore-like primary JSON, order snapshot, event file, log file, export directory, and analytics CSV. Run an intentionally incomplete deleter that touches only the primary. The test must fail because five scopes remain. Repair it with a scope registry and per-scope state. This makes “forgotten copy” observable.

const expectedScopes = ["primary","orders","events","logs","exports","analytics"];const evidence = JSON.parse(await fs.promises.readFile("governance/evidence/deletion-u123.json","utf8"));const incomplete = expectedScopes.filter(s => !["DONE","ANONYMIZED","DEFERRED_BY_POLICY"].includes(evidence.scopes[s]));if (incomplete.length) {  console.error("DELETION_INCOMPLETE", incomplete);  process.exit(1);}console.log("DELETION_SCOPE_COMPLETE");

8. Backups and exports are governed copies

Chapter 22 separated scheduled backups from managed export/import. Chapter 23 adds governance: who may create/restore/export, which encryption applies, where Cloud Storage objects reside, retention duration, and what a deletion request means for historical copies. CMEK on the primary does not prevent authorized restore/export into a different encryption posture unless IAM and organization policy constrain those actions.

Production judgment

Minimize collection, minimize duplication, isolate secrets, redact before logging, and automate a deletion inventory with resumable/idempotent states. Privacy/legal teams define policy; engineering must make the policy executable and observable. A “delete endpoint” is only complete when it accounts for every controlled copy and documents unavoidable/deferred retention.

Knowledge check

1. Why is deleting profiles/u123 insufficient for subject deletion?
2. Should raw ID tokens appear in debug logs?
3. What should happen when a legal hold exists?
4. Why must exports/backups appear in deletion evidence?
5. Does CMEK automatically enforce right-to-delete?

Authoritative references

• Firebase: Server-side encryption — Google-managed encryption, CMEK, client-side encryption distinction, and TLS in transit.
• Google Cloud: Firestore Native CMEK — availability behavior, rotation, backup/restore interaction, and limitations.
• Google Cloud: Firestore Native VPC Service Controls — Firestore service perimeter behavior.
• Google Cloud: Firestore locations — regional/multi-region topology and immutable database location.
• Google Cloud: Firestore regional endpoints — server-library data-locality endpoint behavior.
• Google Cloud: Private Google Access for Firestore with MongoDB compatibility — firestore.goog and restricted.firestore.goog private routing.