Most incident response plans are written around customer data. Monitoring data rarely appears in them, which is odd, because it is one of the more damaging things an organisation can lose and one of the few datasets where every affected person has an employment relationship with you.
Worth thinking about before rather than during.
Why it is worse than it looks
The instinct is to rank it below customer payment data and above, say, an internal wiki. That underrates it, for a specific reason.
Monitoring data is longitudinal and behavioural. A payroll record says what someone earns. An activity archive says when they work, how that changed over eighteen months, which applications they use, how long they spend in each, when they stopped working late, when they started again.
From that, things can be inferred that you never set out to collect and have no lawful basis for holding. Sustained late-night activity followed by a fortnight of nothing suggests something about health. Repeated visits to a particular category of site suggests something about beliefs, or a medical condition, or a job search. Working-hours changes correlate with caring responsibilities and with relationship breakdown.
None of that is in your dataset as a field. All of it is inferable from the dataset, which is why the risk assessment cannot stop at "it is only app names and timestamps."
Add screen captures and the position changes qualitatively rather than by degree: now the archive contains whatever was on the screen, including other people's personal data, client confidential material and the employee's own private accounts.
The 72-hour clock, and what actually consumes it
Under GDPR and UK GDPR a notifiable personal data breach goes to the regulator within 72 hours of becoming aware of it. The clock is short and the work is front-loaded.
In practice the time goes on three questions, and the third is the one that catches people.
What was in the archive? Not what the product brochure says it collects — what your deployment actually held, at field level, for the retention period in force. If nobody can answer that in hours, the notification is written on assumptions.
Who is affected? Monitoring data covers your whole workforce by design, so the answer is usually "everyone", including leavers whose records you kept.
And what can be inferred from it? This is the risk assessment, and it is the part that determines whether you are notifying individuals as well as the regulator. It cannot be done well without the field-level inventory from the first question.
Telling the workforce
The formal test is whether the breach is likely to result in a high risk to individuals. The practical answer for monitoring data is usually to tell them anyway, and to do it before they hear it elsewhere.
Two reasons. They will find out — breaches surface, and a workforce that learns from a news report that their behavioural records leaked, after the employer decided the threshold was not met, has a trust problem far larger than the breach. And they may need to act: if the archive could support inferences about them, they are better placed than you to judge what that means for their circumstances.
The communication that works is specific rather than reassuring. What was held, what was taken, what can and cannot be inferred from it, what you are doing, and what you got wrong. Vague reassurance invites people to assume the worst, and in this case the worst is plausible.
There is also an uncomfortable disclosure embedded in the exercise. If employees learn from the breach notice that you were collecting something they did not know about, you have two incidents. This is the same test as a subject access request: can you describe your own collection accurately to the people it covers? If the answer is no, that is a present problem, not a hypothetical one.
Shrinking the blast radius
Controls matter, but the two decisions that set the size of an incident are made long before it:
How much you collect. A metadata-only archive is a bad loss. A screen-capture archive is a much worse one, and the difference is not marginal. The least-collecting tool that answers your question is also the smallest incident you can have. The screen monitoring piece covers the cases where capture is genuinely required, which are narrower than the market implies.
How long you keep it. Four years of behavioural records is roughly four times the incident of thirteen months, and the older data is almost never the data anyone uses. Retention is a security control first and a compliance obligation second — the retention guide covers setting periods that survive being questioned.
Then the ordinary controls, which apply with more force here than people assume: access logging on the monitoring tool itself, including vendor-side access; restricting who can open individual records at all; and knowing whether "deleted" in your tool means deleted from backups, because backup retention is where most retention promises quietly fail.
A short tabletop worth running
Thirty minutes, four questions, in a room with whoever owns security and whoever owns the monitoring deployment:
What exactly does our monitoring archive contain today, at field level? What is the oldest record in it? If our vendor told us at 9am on a Friday that it was exposed, who writes the regulator notification and from what source of truth? And what would we tell the workforce?
Organisations that have never run this discover the gap is almost always the first question, and the first question is the one everything else depends on.
Where ProdView fits
The honest version of our pitch here is about blast radius rather than defence. ProdView holds activity and application metadata — never screen content, never keystrokes — so the worst case is a smaller worst case. Retention is configurable, so you choose how much history exists to lose. Employees see their own data, which means a breach notice cannot be the first time they learn what was collected. SOC 2 Type II, and the report is available under NDA if your security team wants to read it rather than the badge.
When not to pick us: a mandate requires session recording. Then the archive is larger by necessity, and the incident-response planning around it matters more, not less.
Try before you commit
Three seats are free forever. The useful exercise is pointing your own tooling at the agent and seeing exactly what leaves the machine — that tells you what you would be notifying about, which no datasheet does.
General information as of October 2026, not legal advice. Breach notification thresholds and deadlines vary by jurisdiction; take advice on a live incident.