PII handling
Personal data is a liability that compounds. Every field you keep is something
you can leak, something a subpoena can reach, and an obligation you carry until
you delete it. The discipline is to collect less, guard what stays, and purge on
a clock instead of hoarding by default.
Method
- Classify each field before it lands. Tag every column public, internal,
PII, or sensitive PII (health, biometric, financial, government id). Keep the
map in code or a data catalog so masking and retention rules key off the tag,
not off a person remembering which column held a birth date.
- Minimize at the point of collection. Store what you use and nothing else:
the last four digits of a card, not the full number; an age band, not a date
of birth; a coarse region, not raw coordinates. A field you never collected
is a field that cannot leak.
- Mask on the way out. Redact in logs and errors (
a***@x.com), tokenize
card numbers, and back reads with database views that expose masked columns
by default, so a stray SELECT * does not spill raw values into a dump.
- Pseudonymize before data reaches analytics. Swap direct identifiers for a
per-subject token in the warehouse and in non-production copies, and keep the
re-identification key in a separate, tightly scoped vault. Analysts get the
shape of the data without the people in it.
- Set retention per class and enforce it in a job. Give each dataset a TTL
(support tickets two years, auth logs 90 days) and run a scheduled purge that
deletes rows for real. "Keep forever" must be a deliberate choice, never the
default nobody revisited.
- Build one lookup path that finds every copy. An access or deletion
request has to reach the primary store, replicas, backups, the search index,
and analytics. A GDPR or CCPA erasure that skips the warehouse copy is not an
erasure.
- Encrypt sensitive PII at the field level. Put envelope encryption on
government ids and health data on top of disk encryption, so a raw table dump
is not a breach by itself.
Checks
- Pick a user id: can you list every place their personal data lives in under a
minute?
- Does a raw email, card number, or national id ever surface in logs, stack
traces, or analytics events?
- When retention expires, does a job actually delete the rows, or does the
policy live only in a wiki page?
Boundaries
Classification thresholds and lawful basis are legal calls; defer to your data
protection officer. The encryption mechanics belong to data-encryption. This
skill decides what to protect, how coarsely to keep it, and for how long.
1---2name: pii-handling3description: Minimize, classify, mask, and expire personal data so any leak or legal request reaches as little of it as possible. Use when designing storage, logging, or analytics that touch names, contacts, identifiers, or other personal data.4---56# PII handling78Personal data is a liability that compounds. Every field you keep is something9you can leak, something a subpoena can reach, and an obligation you carry until10you delete it. The discipline is to collect less, guard what stays, and purge on11a clock instead of hoarding by default.1213## Method14151. **Classify each field before it lands.** Tag every column public, internal,16 PII, or sensitive PII (health, biometric, financial, government id). Keep the17 map in code or a data catalog so masking and retention rules key off the tag,18 not off a person remembering which column held a birth date.192. **Minimize at the point of collection.** Store what you use and nothing else:20 the last four digits of a card, not the full number; an age band, not a date21 of birth; a coarse region, not raw coordinates. A field you never collected22 is a field that cannot leak.233. **Mask on the way out.** Redact in logs and errors (`a***@x.com`), tokenize24 card numbers, and back reads with database views that expose masked columns25 by default, so a stray `SELECT *` does not spill raw values into a dump.264. **Pseudonymize before data reaches analytics.** Swap direct identifiers for a27 per-subject token in the warehouse and in non-production copies, and keep the28 re-identification key in a separate, tightly scoped vault. Analysts get the29 shape of the data without the people in it.305. **Set retention per class and enforce it in a job.** Give each dataset a TTL31 (support tickets two years, auth logs 90 days) and run a scheduled purge that32 deletes rows for real. "Keep forever" must be a deliberate choice, never the33 default nobody revisited.346. **Build one lookup path that finds every copy.** An access or deletion35 request has to reach the primary store, replicas, backups, the search index,36 and analytics. A GDPR or CCPA erasure that skips the warehouse copy is not an37 erasure.387. **Encrypt sensitive PII at the field level.** Put envelope encryption on39 government ids and health data on top of disk encryption, so a raw table dump40 is not a breach by itself.4142## Checks4344- Pick a user id: can you list every place their personal data lives in under a45 minute?46- Does a raw email, card number, or national id ever surface in logs, stack47 traces, or analytics events?48- When retention expires, does a job actually delete the rows, or does the49 policy live only in a wiki page?5051## Boundaries5253Classification thresholds and lawful basis are legal calls; defer to your data54protection officer. The encryption mechanics belong to data-encryption. This55skill decides what to protect, how coarsely to keep it, and for how long.