🧹 Log Redaction, Backups, and Privacy by Design

Intro: Privacy-by-design becomes real when it shapes logging, support tooling, export workflows, and backup scope. This page is about the engineering places where privacy debt usually accumulates.

What this page includes

log-redaction rules that keep detections useful

backup and snapshot questions Product Security should ask

privacy-by-design checks for new features

what to test before release

Log-redaction rules

Always review whether the product logs:

tokens and session identifiers;
raw customer payloads;
authentication factors or recovery codes;
identifiers that let one tenant discover another.

Redaction should happen as close to event creation as possible. Do not rely only on downstream SIEM masking.

Backups and snapshots

Ask:

who can restore and where;
whether a partial restore is possible;
how deleted customer data is handled in backup lifecycles;
whether backup copies receive the same classification and audit treatment as production data.

Privacy-by-design review prompts

Is the product collecting more than it needs?
Can the workflow succeed with derived or masked forms instead of raw values?
Is there a user-visible or operator-visible reason this data exists?
What is the cleanup behavior when the feature is disabled or an account is deleted?

Release checks

Before release, verify:

logs do not capture secrets under normal and error paths;
support and analytics exports are appropriately minimized;
deletion workflow covers secondary stores;
dashboards and admin tools do not reveal fields they do not need.

Good habit

Treat privacy review as part of product design and data architecture, not as text pasted into a launch checklist at the end.