Personally Identifiable Information

Treat data as one block and the rules have to be one block too. Lock the whole thing down and analysts need approval every time, so nobody looks at data at all; leave it loose and names and contact details ride into any screen. Both are wrong and there is no middle, because the granularity of the rule is wrong rather than its strictness.

The loose version produced the incident first. A table copied for analysis carried user email addresses straight across, and a dashboard built from that table put 200 email addresses on screen. The column had been brought along to make account names readable, which is how most of these copies get created.

The bigger problem appeared at the moment of trying to remove it. Nobody knew which tables held that email address or how many copies existed. Deleting it at the source left it in four derived tables, one of which was shipping to an external analytics tool every day. The copies are the whole difficulty; the original is easy.

So instead of treating data as one block, the practice became marking which columns single out a person. With the marking in place, rules attach to those columns rather than to everything. Abbreviated PII, the term is what the rest of the controls hang from — nothing else in the policy can be specific without it.

Start by deciding what qualifies. It splits two ways.

1. Values that identify someone on their own: name, phone number, email address, national identification number, bank account number.
2. Values that identify in combination. Date of birth, postal code, and gender together often leave exactly one person in a given area. This side is the one that gets missed, because each value looks harmless alone, and two of the three are often already public. So the criteria for marking get written down and new columns get checked against them.

The marking goes on columns. In the inventory recording what data lives where, each qualifying column carries a flag, and the rules below apply automatically from that flag. Judging case by case collapses the moment there are 200 tables, and the flag is what makes the controls mechanical.

Four rules attach.

1. Narrow the read access. Only the roles that need it can open a table holding such a column; everyone else gets a view with the column removed.
2. Set a separate retention period. Even where the rest of the data is kept three years, these columns get deleted once their purpose is served. Keeping something because deleting it takes work is not a retention policy.
3. Strip them from anything leaving. Files handed to partners and data flowing to external analytics tools both fall here, and the list of destinations is usually longer than anyone expects.
4. Log the access. A record of who read the column and when is what makes it possible to scope an incident afterward; without it, the extent of a leak gets answered by estimate.

Reducing it at collection is the cheapest approach of all. The principle of gathering only what's needed is data minimization, and a value never collected needs no rule and no deletion. If what analysis needs is a group tendency rather than an individual, send it through anonymization first. Most dashboards need counts rather than people.

Handling access and deletion requests presupposes the inventory. When the data subject who owns the information asks for it to be deleted, columns that aren't written down anywhere won't all be found inside the response deadline.

Five places open this distinction.

1. Access design. The flag is the basis for which role can open which table. Because it cuts at column level rather than table level, giving an analyst the table while masking the email column becomes possible. Table-level permissions force a choice nobody wants to make.
2. The analysis environment. When building a dataset copied for analysis, these columns get stripped or replaced with derived values. If users have to be told apart, an internal identifier replaces the email address.
3. Anything leaving the company. Files handed to partners, external analytics tools, and customer support tools all fall here. Every new tool adds a step of checking what flows into it — one more tool is one more path out.
4. Responding to access and deletion requests. A request arrives and you open the inventory to find every affected column.
5. Incident response. After a leak you have to answer what went out within hours, and the flags plus the access log are the raw material for that answer. Hours is the realistic window, which rules out reconstructing anything by hand.

"Flag this column. It's being copied straight into the analysis tables."

Without the flag, no rule applies.

"A deletion request came in. Pull every affected column from the inventory."

Answering inside the deadline presupposes the inventory.

"Use the internal identifier instead of the email. We only need to tell users apart."

What's needed is distinction rather than identity.

Pagedeck did this cleanup over one quarter. Theo swept 110 tables and counted 34 columns that single out a person, eleven of which were copies living in analysis tables. The one place they belonged was a single accounts table.

The eleven copies came out and the analysis tables kept only internal account numbers. When the first deletion request arrived two months later, finding everything took 20 minutes. Before the cleanup, asking where it all lived would have taken a day, with no way to be sure the answer was complete.

The most common belief is that only names and contact details qualify. Those two are the clearest, so the assumption is natural. But a device identifier or an address that carries no name still follows one person continuously and gets the same treatment, and three ordinary-looking values that together leave one person do too. Narrowness feels safe and produces the opposite. Read it narrowly and half the columns needing rules stay unflagged — and that half is the half that matters when something goes wrong.

The other frequent belief is that deleting it ends the matter. Removing it at the source makes it look gone. But the same value is scattered across derived tables, logs, backups, and external tools. If the service log was recording request bodies verbatim, it remains there until that log's retention expires. A decision to delete has to come with a list of where.