Your monitoring platform has just told you that one of your employees appears in a fresh stealer log. Good — that is the system working. But pause before you open the record, because what is in there is not only a security finding. An infostealer takes everything from an infected device: alongside the corporate VPN password sits, potentially, the employee's personal banking login, the health service they use, the dating app, the second email account. From the moment that log matched your domain, you stopped handling only threat intelligence and started handling personal data about a person who works for you.
How you respond is therefore a data protection decision as much as a security one. Handled carelessly, a credential-leak response can do real damage to the person involved and expose the organisation to exactly the kind of scrutiny it was trying to avoid. Handled well, it is fast, clean, and private. Here is the walkthrough.
Step 1: Decide Who Needs to Know What — Before Anyone Looks
UK GDPR's data minimisation principle — personal data must be "adequate, relevant and limited to what is necessary" (ICO guidance) — applies to your incident response process, not just your marketing database. Work out the minimum each party needs:
- The security team needs to know: a corporate credential is exposed, from which device class, and whether session cookies or tokens are involved. It does not need the employee's personal passwords, and it does not need the list of personal services in the log.
- The employee needs to know everything about their own exposure — theirs is the only pair of eyes that should see the personal detail, because only they can act on it.
- HR and line management almost always need to know nothing at all. A malware infection is not misconduct. Treat it like a phishing click: a hazard of being online, not a disciplinary matter.
Step 2: Kill the Corporate Risk Directly
For the accounts you control, act without ceremony: force-reset the corporate password, revoke active sessions (stolen session cookies bypass MFA entirely, so resetting the password alone is not enough), and check authentication logs for use of the credential since the exposure date. None of this requires anyone to see personal data — it is standard containment on assets that are yours.
Step 3: Let the Employee Fix the Rest — Privately
Here is where programmes go wrong. The exposed data usually includes personal and third-party logins the organisation cannot reset — the reused password on a personal email account is often the most dangerous item in the log, because personal email is the recovery path to everything else. Somebody has to fix those, and the only somebody with the right and the knowledge to do it is the employee.
The wrong way: an analyst reads through the log, compiles a list of the employee's personal services, and walks them through it in a meeting. You have now processed far more personal data than necessary, created a record of it, and taught the whole company that being infected means being inspected.
The right way: notify the person privately and hand them a tool that shows them — and only them — what was exposed, guides them through changing each password, and reports back nothing but completion. This is data protection by design doing real work: the sensitive detail never enters the organisation's records, so it can never leak from them. It is how we built Lens, and the privacy property is architectural, not procedural — administrators could not read the personal detail even if they wanted to.
Step 4: Deal With the Device
A stealer log means an infected device somewhere. If it is corporate, your existing malware response applies. If it is personal — and with stealer logs it usually is — you can advise and support, but tread carefully: demanding to inspect an employee's personal laptop is a bigger intrusion than the malware. Offer guidance (our infostealer infection guide is written for exactly this hand-off), and let the credential evidence tell you whether corporate assets keep reappearing in fresh logs, which is the signal that the infection persists.
Step 5: Know Your Reporting Triggers
A credential exposure can be a reportable personal data breach in its own right. The test under UK GDPR is risk to individuals: if the exposure is likely to result in a risk to people's rights and freedoms, it goes to the ICO within 72 hours (ICO: report a breach). One employee's harvested browser passwords will not usually clear that bar; a stealer log revealing exposure of customer data, or credentials for systems holding it, can. Record the assessment either way — the deliberation is itself a compliance artefact. Our UK data breach response guide covers the full decision tree, including the separate 24-hour clock the Cyber Security and Resilience Bill starts for in-scope providers.
The Principle Underneath
Every step above follows one rule: route the personal detail to the person, and the risk signal to the organisation. Security gets what it needs — exposure counts, remediation status, device-health signals, audit trail. The employee gets what they need — the full picture of their own exposure and the means to fix it. Nobody gets what they do not need. That is data minimisation as an operating model rather than a policy line, and it is the difference between a monitoring programme staff trust and one they quietly work around.
Lens notifies affected staff privately — admins see completion, never passwords.