Become the Highest Paid Engineer at Your Company/

...

/

Privacy and PII

Privacy and PII

Build systems that treat privacy as a feature, not an afterthought—map, minimize, encrypt, and delete PII by design.

We'll cover the following...

If your system touches personally identifiable information (PII)—emails, SSNs, addresses—you’re now in “please don’t get subpoenaed” territory. One misstep and you could be dealing with various legal, reputational, and architectural consequences.

As a Staff+ engineer, you’re expected to design systems that minimize privacy risk and bake in data protection and auditability by default.

Most privacy failures are simply design oversights. In this lesson, we’ll show you how to catch them early and fix them fast.

We’ll cover 6 best practices:

  1. Map a PII data map.

  2. Minimize, tokenize, and encrypt.

  3. Set retention with TTLs.

  4. Redact logs and traces.

  5. Build security-aware observability.

  6. Prepare for incident response.

Let’s get into it.

6 best practices for treating PII with care

Here’s how to treat PII with care:

1. Make a PII data map

List what PII you use, why, and where it lives.

Export example (mini map):

  • Fields: Email, full_name (Sensitive), country (Internal)

  • Purpose: Let customers export data, send a download link

  • Storage: DB + exports/*.csv bucket

  • Processors: Email provider, storage

  • Retention: Exports auto-delete after 7 days

This keeps reviews honest and the scope clear.

2. Minimize, tokenize, encrypt

  • Minimize: Don’t export columns you don’t need (drop phone, address).

  • Tokenize/pseudonymize: Use IDs instead of raw values internally.

  • Field-level encryption: Store sensitive columns with KMS-backed keys.

Customer data export example: The CSV excludes phone by default, email is encrypted at rest, and logs show customer_id, not email.

3. Set retention with TTL

Data shouldn’t live forever.

  • TTL jobs auto-delete exports (e.g., nightly).

  • Define retention SLAs (what’s kept, how long, why).

  • Support legal holds as an exception path.

Customer data export example: Export files are deleted after 7 days; DB cleanup runs monthly.

4. Redact logs and traces

Logs are evidence, not PII dumps.

  • Add a redaction filter → only safe fields pass.

  • Structured logs: user_id, resource_id, operation, result, trace_id.

  • Privacy tests fail if PII sneaks into logs.

Good audit event: AuthorizationDecision: user=u_123 action=export.create resource=export_987 result=allow trace=abc123

5. Build security-aware observability

Detect anomalies without leaking data.

  • Signals: Deny spikes, volume bursts, failed MFA, odd file sizes.

  • Dashboards: Allow/deny trends, export counts by tenant.

  • Alerts: Export volume above baseline, download link abuse, egress denied spikes.

6. Prepare for incident response

No guessing mid-crisis. Have a one-page runbook.

  • Loop: Detect → Contain → Eradicate → Recover → Learn.

  • Roles: IC (runs call), comms (updates stakeholders/customers), scribe (captures facts).

  • Tools: Export stop switch, canned customer update, evidence checklist.

  • Cadence: Status report every 30–60 minutes until stable, then a clean hand-off to postmortem.

Customer data export example: Suspicious downloads → flip export_freeze, rotate link secrets, cut customer note, pull audit logs, trigger cleanup job.

Shift-left (design + tests)

  • Design doc must include a PII data map (fields, purpose, storage, processors, retention) and the retention/TTL decision before coding.

  • Add privacy acceptance tests: no PII in logs; redaction active; audit events present and linked by trace_id.

  • Note the stop switch and the incident contact channel in the doc.

You can now map and minimize PII, encrypt the sensitive bits, redact logs, and set TTLs, so your system protects people by default. You’ve also wired audit trails and a clean incident routine (stop switch, roles, comms)—making you the calm, reliable anti-John who ships safely at scale.

Ask