The personal data nobody remembers you're holding

There is personal data on your company's laptops that nobody has thought about in months. Not in the database - someone designed the database. It's the spreadsheet a colleague exported for a report last March. The customer list somebody pulled for a migration that finished a year ago. Under GDPR you're accountable for the personal data you hold, including the copies you've forgotten you're holding. EmberHound is a desktop agent that finds it. It runs on the endpoint, reads the file formats people actually use, and matches against the identifiers GDPR cares about - names, emails, dates of birth, national ID numbers, bank details. The detection happens on the machine. Sensitive values are masked on-device before anything is transmitted. Which matters more than it sounds. A scanner that uploads your files somewhere to analyse them has just made a second copy of the exact problem you're trying to measure.

Signup starts with the plan. I'm taking the Free GDPR Scan. You'll get one device, one seat, five hundred gigabytes of scanning, one scan. You do not need a credit card. That's a real scan on a real machine, not a sandbox - enough to find out whether you have a problem. There's a free PCI tier alongside it if card data is your concern, and paid tiers when you need more than one endpoint.

No card, no sales call, no procurement. Account created.

Before scanning anything, there's one piece of setup, and it's the most interesting thing in the product. Think about what happens when someone exercises their right of access. They write in and ask: what data do you hold about me? Under GDPR you've got a month to answer, and the answer has to be complete. To answer that, you need to search your estate for one specific person. But EmberHound deliberately doesn't store the personal data it finds - it masks it. So how do you search for a person in a system that doesn't keep anyone's details?

So EmberHound mixes in a secret before fingerprinting. That secret is the pepper. Without it, the fingerprints can be reversed by brute force. With it, they can't - because the pepper isn't in the findings, isn't in the report, and isn't transmitted with your results. It's generated once, it's versioned, and it has a fingerprint of its own so you can confirm which pepper produced which results without ever exposing the pepper itself. One consequence worth knowing: replacing the pepper invalidates every fingerprint made with the old one. Your data's fine, but old and new results stop matching. So generate it at the start and leave it alone.

Now the agent itself. Normal desktop install - no server to stand up, no infrastructure, no deployment tooling.

While that installs, here's the other half. The web console and the agent are two separate things. The console is where findings live and reports are generated. The agent is what does the scanning, on the machine. They need to be connected, and this is what connects them. An enrolment token. Note the properties: it's single-use, it expires in thirty days, and it's scoped. So it isn't a permanent credential sitting in a config file somewhere - it's a one-time code that links one specific device to your organisation, then it's spent. Which means if it leaks, the damage is bounded. Someone would have to use it before you did, inside thirty days, and you'd see the enrolment appear in your device list.

In the agent: get the code, paste it in, confirm. Three steps. And what that's doing is more than authentication - it's pulling down your organisation's data discovery policy. The device isn't just logging in, it's inheriting how your organisation has decided scanning should work. Enrolled. The agent picks up a device identity, syncs, and goes online.

The agent shows what it's been told to do. File types - and note that includes mail stores and images, so attachments and scanned documents are in scope, not just text files. A schedule. Background behaviour. Client-side suppression rules. Most of this says server policy, because it came from the console. The device is following your organisation's rules, not its own.

Those rules live here. GDPR EU General is the default - email, phone, name, address, date of birth, IBAN. And there are regional variants, because GDPR isn't uniform in practice. Germany adds the Personalausweis. France adds the NIR and the Carte Nationale. If you operate across borders, the identifiers you're liable for change by country, and the policy reflects that. Policies are versioned. Editing one creates a new version rather than silently changing the old - so you can always show an assessor which ruleset produced which findings, and when it changed. Inside: data classes, file types, OCR, scan scope, schedule, resource throttling. Some things are gated on the free tier - external drives and locally-synced cloud folders need a paid plan.

Back to the agent. Scan now.

This is CPU-bound and it's local. It's walking the filesystem, opening supported files, and matching content against the policy rules. There's no upload step here - nothing is being streamed anywhere while this runs.

And here's the picture. Findings by severity, thirty-day trend, DSAR posture, and an Article 30 inventory view - which is the record of processing activities that GDPR requires you to maintain and that most companies write from memory. This one's written from what's actually on the estate.

Broken down by device.

Open a finding. This one's an IBAN - high risk, flagged as GDPR personal data. Look at the detected value: masked. EmberHound will tell you what it found, where, and how confident it is, without ever showing you or storing the number itself. That's the same design decision as the pepper, showing up again at the presentation layer. And the confidence score is doing real work. This one has a valid checksum and was read as typed text. The scoring reflects how the data was read - typed text scores near a hundred percent, text recovered by OCR around sixty, handwriting around forty. So you're not just told there's a match, you're told how much to trust it. Which is what makes triage possible. You can act on the high-confidence checksummed findings first and treat the low-confidence OCR matches as things to look at, rather than treating all two hundred results as equally urgent. Each finding can be marked a false positive, suppressed, or whitelisted - with the decision recorded, so next month's scan shows you what's new rather than what you already decided about.

Across the estate: the full findings list, an overview by category, and a data catalogue - what types of personal data you hold and where they live. That last one is the thing that's hardest to produce by hand and the thing every GDPR conversation eventually needs.