The personal data hiding in your file exports

A privacy lead at a UK logistics company sent me a spreadsheet last spring and asked whether it was safe to share with an external auditor. It was a customer export, about 4,000 rows, pulled from their operations system. She had already done the obvious thing: deleted the columns headed full_name, email and phone. What was left looked like reference numbers and delivery statuses. Anonymised, more or less. She wanted a second opinion before it left the building.

The second opinion took about ninety seconds. One column, headed delivery_notes, was free text typed by drivers and dispatchers. It contained sentences like "left with Mrs Okafor at number 14, she is the daughter," and "customer called from 07700 900312, said the buzzer is broken, flat is under the name Grewal." A second column held postcodes at full resolution. Neither column had a name in its header. Both were full of people.

That spreadsheet is a small, ordinary example of the thing that makes data protection genuinely hard in practice: personal data does not stay in the fields labelled for it. It leaks sideways, into notes and attachments and reference numbers, and the person who exported the file usually cannot see it, because they are looking at column headers rather than contents. This post is about where personal data actually hides in the exports UK organisations handle every day, and why the tools most teams reach for to find it come up short.

Where personal data actually hides

The mental model most people carry is that personal data lives in obvious fields. Name, email, address, date of birth. Redact those and you are done. That model is wrong in a way that is easy to demonstrate and expensive to ignore.

Free-text is where the model breaks

Structured columns are the easy case. A field headed email_address contains email addresses, and any tool, or any careful human, can find and handle it. The trouble is that most operational systems also have somewhere for a person to type a sentence. Notes fields, comments, internal messages, case histories, call logs, "additional information" boxes on a form. These are where the substantive personal data ends up, because they are where humans record what actually happened.

A notes field does not announce what it contains. It might hold nothing personal for a thousand rows and then, on row 1,001, a paragraph naming three people and describing one of their medical appointments. You cannot know which rows matter without reading the contents, and at export time nobody does.

Documents and email carry data in layers

The problem compounds when the export is not a spreadsheet but a bundle of files. A ZIP from a shared drive or a mailbox export contains documents inside folders, and often documents inside documents: a PDF attached to an email, a spreadsheet embedded in a slide deck, a scanned letter saved inside a case file. Each layer can carry personal data, and each layer has to be opened to be seen.

Email is the sharpest version of this. The personal data in an email thread is rarely just in the body. It is in the header block, the addresses in From, To and Cc, and it is in the attachments, which are frequently the actual point of the message. A forwarded complaint with a PDF attached carries most of its personal data in the PDF, not the two lines of covering text. Treat the email as a body-only object and you miss the part that matters.

The quiet formats nobody thinks to check

Then there are the formats people forget are readable at all. Log files with IP addresses and user identifiers. Configuration or environment files with a support email or an account name baked in. JSON and XML exports where the personal data sits several levels deep in a structure nobody opens by hand. These are not exotic. They turn up in ordinary bundles, and because they do not look like "documents," they are the files a manual review is most likely to skip.

Why keyword search under-counts

When a team does try to find personal data in an export, the tool they reach for is search. Open the file, search for the subject's name, review what comes back. It feels thorough. It is not, and it under-counts in two directions at once.

The first is that a name is a bad key even for finding the name. People appear as "Mohammed," "Mohamed" and "Mohd." A married name differs from the name on an older record. A typo in a hand-typed note, "Grewel" for "Grewal," is invisible to an exact search and completely legible to a human reading the line. Search keyed on one spelling of a name silently drops every record that spelled it differently.

The second direction is worse, because it is structural rather than a matter of spelling. A person is identifiable by their data, not only by their name. A National Insurance number identifies exactly one person whether or not their name appears beside it. So does a full postcode plus a house number, a bank account, a vehicle registration, a customer reference that maps back to an individual. These identifiers routinely appear in exports without the associated name anywhere nearby, precisely because the system already knew who the record belonged to and did not bother repeating it. Search for the name and you will never find them.

A person is identifiable by their data, not only by their name. Search for the name and you miss the postcodes, reference numbers and identifiers that point to them just as precisely.

There is a third, subtler failure that even good search cannot solve: distinguishing a substantive mention from an incidental one. A document that contains the subject's name might be their employment contract, or it might be a distribution list they happened to be on. Both match the search. Only one is personal data about them in the sense a DSAR cares about. That judgement is human, and no amount of better matching removes it, though better matching does decide how many documents a human has to make the judgement on.

Mapping exposure back to the source file

Finding personal data is only half the job. The other half is knowing where it is, which file, which row, which attachment, so that the finding is actionable rather than just alarming.

This matters for two obligations at once. For a subject access request, you have to produce the data held about one person, which means you need to know every file it appears in, not merely that it appears somewhere in a 4,000-file bundle. For a breach assessment, the clock and the severity both depend on knowing exactly which records were exposed; "some customer data" is not an answer you can give a regulator, and "these 312 rows across these 4 files, including 19 with special category data" is.

A raw count of how many times a pattern matched is close to useless on its own. What a privacy team can act on is exposure organised by source: this file holds data on this many people, of these categories, so this file is the one that needs review, redaction or exclusion first.

What is hard about this

I would be overselling if I implied that scanning contents instead of headers makes the problem disappear. It changes the shape of the work; it does not remove the judgement.

Automated detection over-fires. A string that looks like a National Insurance number can be a product code. A postcode-shaped token can be a warehouse location. Turn sensitivity up and you drown a reviewer in false positives; turn it down and you miss real data. The honest position is that detection is a triage layer that decides what a human looks at first, and how much of the haystack they can safely ignore, not a replacement for the human deciding what is actually personal and actually about the subject.

Context is the part machines are worst at. Whether a mention is substantive, whether a document is genuinely about the subject or merely references them, whether a redaction would strip out a third party or the subject's own data, these are calls that still need a person who understands the case. A tool that claims to close a DSAR with no human review is either overstating what it does or being trusted by someone who has not thought about what happens when it is wrong, on a document that later has to be defended to the ICO.

What to do about it

The practical move is not to find a tool that promises to do the work for you. It is to stop trusting the column headers.

Assume, as a working default, that any export containing free-text fields, attachments or human-entered notes holds more personal data than its structure suggests, and that the data is spread across formats a name search will not surface. Review contents, not labels. Prioritise by where the exposure actually concentrates rather than working through a bundle file by file in whatever order the folder happened to list them. And keep a human in the loop for the judgement calls, while letting tooling carry the mechanical work of reading every file, in every format, so that nothing quietly goes unopened.

That last part, reading every file in a bundle and mapping the personal data back to the specific asset it came from, is exactly the discovery problem Sylure exists to handle. If you want to see what it surfaces in a bundle shaped like yours, that is the most honest way to judge whether it earns its place in your workflow.

See how Sylure finds and maps personal data across the files you already hold. See how Sylure maps exposure