Collect Less: Privacy as a Security Control

Ask a team what would go into the breach notification if the marketing database leaked tonight. Somebody names the obvious fields: name, email, company. Then somebody remembers the free-text box on the enquiry form, where people have pasted contracts, staffing plans and, once, a password. Nobody in the room can say how far back the records go, or whether the rows from the previous form are still sitting in the same table.

That gap, between what a system was designed to hold and what it has quietly accumulated, is where most privacy risk actually sits. Not in the cipher suite. Not in the firewall rules. In fields that seemed harmless the day somebody added them and have never been reviewed since.

Data minimisation usually gets filed under compliance, somewhere between the cookie banner and the privacy policy. That filing is the mistake. It belongs in the security programme, and near the top of it. The cheapest control you will ever ship is a field you decided not to collect, and the second cheapest is one you deleted.

The argument here is narrow and, we think, hard to argue with. A field that no longer exists cannot be breached, exported by a compromised account, mishandled by a processor you have never met, or produced in a legal request long after the person who added it left the company. Every other protection you put around that field is a running cost. Deletion costs once.

The cheapest control is a field that does not exist

Every security control you add carries a maintenance tail. Encryption at rest needs key management and somebody who knows where the keys are when the person who set it up is on leave. Access control needs a review cycle, otherwise it decays into whatever the organisation chart looked like two reorganisations ago. Monitoring needs a human who reads the alerts, and alerts nobody reads are a cost with no benefit. All three are worth doing. All three enter the budget permanently.

Deletion is the exception. It has an upfront cost and no tail at all, which makes it the only control that gets cheaper the longer it has been in place. A field you no longer hold cannot:

• Appear in a breach notification. The scope of what you have to disclose is set by what was in the system, not by what you intended to keep there.
• Be exported by a compromised account. Most damaging exports use legitimate credentials and legitimate features. There is nothing to detect except volume.
• Be argued over in a subject access request. You cannot be asked to produce, correct or explain a record you do not have.
• Sit in a backup nobody has rotated since the last migration. Old backups are the most common place a deleted record turns out to be alive.
• Be passed to a sub-processor you have never heard of. Data you never collected does not travel down a chain you cannot see the end of.

The honest limitation: minimisation is not free at the moment you perform it. Removing a field means finding every consumer of it, and there are always more than the diagram shows. A report somebody built in a hurry. An automation that silently breaks. A dashboard three people rely on and nobody documented. That work is real, it is boring, and it is why these projects stall halfway. What makes it worth finishing is that the cost stops when the work does. The cost of keeping the field never stops.

Where the data you forgot came from

Nobody sets out to hold personal data they cannot account for. It arrives by three routes, and the routes are worth naming separately because each needs a different fix.

The form that grew

Forms accrete. The enquiry form launched with four fields. Then sales wanted company size, because qualification was slow. Then somebody wanted "how did you hear about us", which nobody has read since. Then a campaign needed a job title and the field stayed after the campaign ended. No field has ever been removed from that form, because removing one requires an argument and adding one requires an afternoon.

This is the rare place where the privacy argument and the commercial argument point the same way. Shorter forms are a standard finding in conversion optimisation work, and every field you cut to raise completion is also a field you no longer have to store, protect, retain, export or explain to a regulator. Take the win twice. It is the same edit.

The analytics you inherited

The second route is the tag container: a stack of scripts added over years by people who have since left, each one loading in the visitor’s browser with the same privileges as your own code. Almost none of them were reviewed as collection decisions, because nobody experiences pasting a snippet as collecting personal data. It is. We have written about the wider problem in the code your marketing team added, and the privacy half of it is simply this: every tag is a party you have introduced to your visitors without introducing them back.

The exports nobody tracks

The third route is the copy. Personal data leaves its system the first time somebody exports a spreadsheet to look at it properly. That file then lives in a shared drive, an email attachment, a chat thread and a laptop, and it does not expire, because files do not have retention policies. The database has access control and an audit log. The spreadsheet has a filename.

If you inherited the estate rather than built it, assume all three routes ran unsupervised for years. The discipline is the same one that applies to auditing a site you have just taken over: start from what exists, never from what the documentation claims exists.

Retention is a control, not housekeeping

Retention is where minimisation stops being a principle and becomes operational. A policy sentence that says you keep personal data "only as long as necessary" is not a control. It is a sentence. A control is a job that runs on a schedule, deletes rows, and writes somewhere a human can check that it ran.

Here is the shape we look for, class by class. The last column is what we usually find instead, and the pattern in it is more interesting than any individual row.

Read the last column again. In almost every row the failure is not that the retention period is wrong. It is that no period was ever chosen, so the effective policy became "forever", decided by nobody, defended by no one, and discovered during an incident.

Then there is the copy problem again, in its most expensive form. Deleting a row from production does nothing to the same row in last quarter’s backup, which is correct behaviour and should stay that way, provided the backup set itself expires. If your archive goes back indefinitely, your retention policy is decoration. That is a separate question from whether the backup would actually restore, and both need answering by the same person on the same afternoon.

The analytics nobody reads and everybody stores

Most teams collect event-level behavioural data they have never queried and would not know how to query. It accumulates because the default configuration collects it, because the vendor’s onboarding suggested it, and because switching something off feels like losing something. Storage is cheap, so nothing forces the conversation. Then the data becomes a liability and the conversation happens under pressure.

Start from the question instead. Write down the decisions your measurement is meant to inform this quarter, then collect what answers those. That is the ordinary starting point for analytics a team can act on, and it happens to be the correct privacy posture as well. A measurement plan is also a collection limit, if anyone treats it as one.

The distinction that does most of the work: aggregates answer nearly every question a marketing team actually asks, and individual event rows answer a small number of them. Sessions, sources, page performance, funnel drop-off, campaign comparison. None of that needs a permanent record of what one identifiable person did on a Tuesday. Keep the aggregate for as long as it stays useful. Keep the raw rows briefly.

Collect for a question you have written down. Everything else is inventory, and inventory has a holding cost even when it sits still.

There is a real counter-argument, and it deserves saying properly rather than being waved away. You cannot analyse data you did not collect, and the question you will want in six months is not the question you have today. That is true. It is also the exact reasoning that justified every over-collecting system ever built, which is why it needs a boundary rather than a rebuttal. Ours: collect broadly at the aggregate level, narrowly at the identifiable level, and add a new identifiable field only when a named person can say which decision it changes.

Consent, asked for honestly

Consent is the part everybody performs and few do honestly. The performance is familiar: a banner where accepting takes one click and refusing takes three, a bundled tick box covering analytics, marketing and "our partners" in a single sentence, and a withdrawal route that technically exists on a page nobody can find. All of that is theatre, and theatre is the one thing that makes a privacy programme look worse than doing nothing at all.

What honest consent looks like

• Specific. One purpose per request. If two purposes are genuinely different, they are two questions.
• Separable. Refusing analytics must not also refuse the newsletter the person actually asked for.
• Symmetric. Rejecting takes the same number of clicks as accepting, in the same visual weight.
• Revocable. A withdrawal route that works, is findable, and takes effect in the systems downstream.
• Recorded. What was shown, which version of the wording, when, and what the person chose.

The pattern that does the most damage is asking for consent for something you were going to do anyway. It converts a lawful, explainable activity into a promise you will break, and it teaches your visitors that the choice is decorative. If you genuinely need an email address to deliver the thing somebody requested, do not dress that up as a choice. Say what you do, why, and for how long, in a sentence a person can read once and remember.

Consent also travels, which is the part that gets missed. The moment data reaches a processor, your promise becomes their obligation, and the only thing carrying it across is the contract. Ours is published as our data processing terms, and the clauses worth settling before anybody signs are set out in what a data processing agreement should say. Sub-processor lists and deletion-on-termination are the two people skip and later regret.

The exposure of data you forgot you held

Forgotten data is not dormant. It is data whose risk you have stopped pricing, and it surfaces at three moments, all of them inconvenient.

The first is a request from an individual. Someone asks what you hold about them, and the honest answer has to cover every system: the spreadsheet, the support archive, the marketing platform nobody ever migrated off. Teams that have never run this exercise discover that the request itself is the audit. It arrives with a clock attached and no budget behind it.

The second is an incident. Notification scope is set by what was in the compromised system, so a table you forgot about widens the disclosure, the number of people you must contact, and the seriousness of what you have to tell them. A minor misconfiguration in a service holding three fields is an afternoon. The same misconfiguration in a service holding years of unclassified free text is a different kind of week entirely.

The third catches people out because it is commercial rather than legal: the security questionnaire attached to a deal you want. Enterprise buyers ask what you collect, where it lives, how long you keep it, and who else touches it. "We are not sure" is a slow answer, and slow answers lose deals to competitors who wrote theirs down two years ago. Minimisation shortens that questionnaire more than any control you could buy.

How to run a data minimisation pass

This is the sequence we would run, in order. For a typical marketing estate it is days of work rather than weeks, and the first pass always finds more than the second, which is the point of booking a second.

1. Inventory by system, not by intention. Open each store and list the fields that are actually there. Do not start from the privacy policy, which describes an idealised estate that has never existed.
2. Give every field an owner and a question. Name the person who uses it and the decision it informs. Fields that cannot find an owner in a week are your first deletions, and they are usually the majority.
3. Fix collection before you clean up storage. Deleting the archive of a field the form still captures is bailing without turning off the tap. Change the form, the tag and the integration first.
4. Set a period per class, and write down the reason. The reason matters more than the number, because the reason is what lets the next person adjust it defensibly instead of guessing.
5. Turn periods into scheduled jobs. A policy nobody automated is an intention. The job needs a log, and somebody needs to read that log on a cycle.
6. Chase the copies. Search index, warehouse, email platform, support tool, exports folder, backup set. Each needs its own expiry, or the deletion is partial and you will describe it as complete.
7. Book the next pass before you finish this one. Collection creeps back as soon as the next campaign launches. Annually is the minimum; after every major launch is better.

The output of a pass is a list of findings, and findings are only useful when each one carries a severity, an owner and a recommendation somebody can act on this month. That is the shape a tool like Prooflin produces: AI-assisted findings, severities, priorities and recommendations resolved into professional, reviewable reports. Our parent company has written about what belongs inside one of them in the anatomy of a finding, which is worth reading before you write your first list.

Where we would start, and when this reverses

If the choice is between spending next quarter adding another control and spending it collecting less, collect less. The second option reduces the number of things the first option has to protect, and it is the only work in security whose benefit does not decay the moment somebody stops maintaining it. Nothing else on the roadmap has that property.

Now the reversal, because there is one and pretending otherwise would be dishonest. In regulated contexts the obligation frequently runs the other way: financial, medical and safety records carry mandatory retention that overrides any instinct to delete, and deleting them early is itself the violation. In those environments the rule becomes narrower rather than opposite. Collect less at the point of capture, keep exactly what the law requires, segregate it from everything else, and let the general-purpose systems hold nothing that belongs in the regulated one.

Security telemetry is the other exception worth naming. Logs are the one class where you generally want more rather than less, because an incident you cannot reconstruct is an incident you cannot close. The discipline there is different: collect the events, keep them for a defined investigation window, restrict who can read them, and resist the temptation to enrich them with personal detail that turns a diagnostic record into a profile.

The pass is not the work. The work is the job that runs every month after the pass, the field somebody refuses to add next spring, and the review that catches the tag a campaign left behind. That is why retention belongs inside ongoing maintenance rather than in a project that closes. If you want a second pair of eyes on what your forms and tags are collecting today, tell us what you are running and we will start with the free-text box.