There is an assumption baked into most security awareness programmes that nobody ever says out loud: the employer should see everything. Who failed the phishing simulation. Whose password turned up in a breach. Which member of staff clicked the link, on which day, at what time. The dashboards are built for managers, the reports are built for auditors, and the employee — the person the whole exercise is supposedly about — is the object of the programme rather than a participant in it.
We think that assumption is wrong. Not just ethically wrong, but practically wrong: it produces worse security outcomes, harder data protection conversations, and a culture where staff hide problems instead of fixing them.
Surveillance-Shaped Awareness Doesn't Work
Consider what happens when an employee's credentials appear in an infostealer log and the standard playbook kicks in. Security opens a ticket. The ticket names the employee. Somebody — an analyst, a manager, sometimes HR — reviews what was exposed, which can include intensely personal material: the streaming services they share with an ex, the health portal they log into, accounts they would simply rather their employer not know about. Then the employee gets a meeting invitation with the word "security" in it and a knot in their stomach.
Run that play a few times and word gets around. Staff learn that being found in a breach means being investigated, so they stop reporting the personal device that might be infected, stop mentioning the reused password, stop asking questions. The programme's own data dries up. Blame-centred security culture fails precisely because people respond to it rationally — by keeping their heads down.
The security industry has understood this for years — a positive, no-blame culture is a running theme of modern security guidance, including the NCSC's Cyber Assessment Framework, which treats people and culture as part of the assessed security posture, not an afterthought. Awareness that humiliates does not change behaviour; it changes what people tell you.
The Privacy-First Alternative
Flip the model. When an employee's credentials surface in stealer-log or breach data, tell them — privately, directly, and with enough detail to act. Let them review what was exposed on their own screen, change the passwords that matter, and confirm when they are done. The organisation sees completion status and aggregate metrics: how many people were notified, how many finished their review. It never sees the passwords, and it never sees which personal services were involved.
Three things happen when you run awareness this way:
- Engagement goes up. A private nudge is a favour, not an accusation. People complete a review they control far more readily than one that feels like a disciplinary process — and a mobile-friendly, non-judgemental flow removes the last excuse not to.
- Real remediation happens. The person who actually knows which exposed account matters — because only they know which passwords they reuse where — is the one doing the fixing. An admin force-resetting the corporate account cannot reach the reused password on a personal service; the employee can.
- The security team's risk shrinks. Plaintext passwords and lists of employees' personal services are toxic data. If your programme never centralises them, they cannot leak from you, be misused by an insider, or appear in a subject access request you would rather not answer.
The UK GDPR Case
That last point deserves expansion, because privacy-first awareness is not just culturally nicer — it is what data protection law actually asks for. UK GDPR's data minimisation principle requires that personal data be "adequate, relevant and limited to what is necessary". Ask the question plainly: is it necessary for a security administrator to read an employee's exposed personal passwords in order for those passwords to get changed? No. The necessary datum is "this person has exposures and has (or has not) dealt with them". Everything beyond that is data you are choosing to hold, and would have to justify.
Data protection by design — an explicit UK GDPR obligation, not a nice-to-have — means building that answer into the system rather than into a policy document nobody reads. A tool that architecturally cannot show admins the sensitive detail is a much easier conversation with your DPO, your works council, and if it ever comes to it, the ICO, than a tool where restraint depends on analysts choosing not to look.
What This Looks Like in Practice
This is the model we built Lens around. When DarkStrata finds staff credentials in stealer logs or breach data, Lens sends each affected person a private invite. They verify their identity, review each compromised account on their own device — corporate assets flagged separately from personal and supplier logins — change what needs changing with guidance built in, and finish with a few minutes of bite-sized training. Administrators see one thing: who has completed their review. That is the whole report, and it is the only report a well-run programme needs.
Security awareness does not have to choose between effective and respectful. Done properly, respectful is effective — and it is the version of the programme you can defend to staff, regulators, and your own conscience in the same breath.
Private notification, personal remediation, aggregate reporting. Nobody looks over anybody's shoulder.