HR and people teams accountable for the rollout

Deploy it without the part that goes wrong

When employee monitoring fails, it is rarely because the wrong data was captured. It fails at consultation: a tool is rolled out, a works council or employee representative body was not involved, and the deployment is suspended regardless of how proportionate the capture was. The rest of the failure mode is familiar to anyone who has handled a subject access request about monitoring data — the request arrives, and nobody can say precisely what was collected, under what configuration, or who changed it.

What goes wrong today

If none of these are familiar, this probably is not your problem.

  • A rollout planned as an IT project, where the binding constraint is a consultation requirement nobody owned.
  • No defensible answer to "what exactly is being collected about me", which is the first question in any grievance or subject access request.
  • Monitoring scope widened quietly over time, with no record of who changed it or when.
  • Erasure and access requests answered by hand, slowly, from a system that was not designed to answer them.
  • A proportionality argument that has to be made after a complaint rather than documented before deployment.

What changes

With privacy-by-default metadata tracking.

  • A per-country account of what applies where — the legal instrument, whether consultation with a works council or employee representatives is required, and the order the steps have to happen in.
  • A precise answer to what is collected: window and process metadata, never keystroke content, with screen capture off by default and behind a compliance review.
  • Configuration changes audited, so who widened a scope and when is a record rather than a recollection.
  • Scope that can only be narrowed as it is inherited, never widened, so a team-level setting cannot quietly exceed the organisation's policy.
  • Erasure of an individual's captured data supported as a function of the product rather than a manual database exercise.

What the design guarantees

audited-config
Every change to what an organisation captures is written to an audit log with who changed it and when.
rtbf
An erasure deletes the person's captured activity and the raw archive it came from, and anonymises the account itself — name, address, devices and memberships go with it; approved timesheets are kept as payroll evidence unless the organisation turns that off.
sensitive-capture-off-by-default
Screenshots and input-activity capture are off by default, and a narrower scope can never widen what a broader one allows.
transparent-agent
By default the person being monitored can see what is being captured on their own machine and can pause capture. The one exception is a covert investigation, which is Enterprise-only, unavailable in the EU, capped at 90 days, and audited.

Questions from teams like yours

Do we have to consult a works council before deploying this?

In several jurisdictions, yes — and it is the step that most often stops a rollout. In Germany the works council has a co-determination right over technical monitoring systems; the Netherlands, Belgium, Austria, France, Spain and Italy each have their own form of employee representative involvement. The per-country guides state which instrument applies and what happens if the step is skipped. They are a starting point for your own legal advice, not a substitute for it.

An employee submits a subject access request about monitoring data. What can we give them?

The activity captured about that person, and the configuration in force when it was captured. Because scope changes are audited, the answer covers not only what was collected but under what settings and who set them.

Can we delete one person's data without affecting the rest?

Yes. Erasure of an individual's captured activity is supported, and each organisation's data lives in its own database rather than in a shared table, so the operation acts on your data alone.

How do we demonstrate the monitoring is proportionate?

Largely by what is not collected. Keystroke content is never captured; screen capture is off by default and gated behind a compliance review; no productivity score is produced. Configuration can only narrow as it is inherited, so a documented organisation-level policy cannot be exceeded further down. That combination is the proportionality argument, and it is evidenced by the configuration rather than asserted in a policy document.

Can a manager quietly enable more capture for one person?

Not silently and not beyond the organisation's policy. Inherited scope narrows only, and configuration changes are audited. Covert investigation exists as a separate, deliberately constrained path: Enterprise-only, unavailable in the EU, capped at 90 days and audited.

See where the hours actually went

Free for up to three people. Windows and macOS. No keystroke content on any plan, and screenshots off unless an administrator turns them on.