What Not to Capture

Some capture is available and should not be switched on. Ruling it out at configuration time is far cheaper than removing it after deployment.

Keystroke content

Available in several products and almost never necessary.

It captures passwords, into a store that was not designed to hold them.

It captures private messages typed in any window.

Event counts answer every legitimate question that content would: how much typing a task involves, where retyping happens.

Switch it off, and say that it is off.

Clipboard content

Copy and paste events are the single best automation signal, because they show data moving between systems by hand.

The event is what you need. The content is not.

Capture that a copy happened, from which application to which, and discard what was copied.

Screen content outside the allow list

Screenshots capture whatever was visible, including other applications, personal windows and third-party data.

Restrict capture to the applications in scope, by allow list.

Blank or blur the rest, which most agents support and few deployments configure.

Personal use

It will happen and capturing it serves no purpose.

Exclude personal application categories technically.

Do not report on it, even where it is incidentally visible.

A study whose output includes someone's browsing has failed at scoping, whatever it found about the task.

Idle time as a productivity measure

Idle detection is legitimate for excluding gaps from a task duration.

It is not a measure of whether someone was working, since thinking, reading paper, talking to a colleague and answering a phone all register as idle.

Do not report idle time per person, which is the drift point most deployments reach within months.

Individual comparison

Any output ranking participants.

Any per-person dashboard.

Any figure that would appear in a performance conversation.

The study characterises a task, which is an aggregate across participants, and individual traces are working material to be discarded.

Anything you would not explain in detail

The test: would you be comfortable describing this capture, precisely, to the people it applies to, before it starts?

If not, that discomfort is the answer.

Apply it at configuration, because removing a capture later requires admitting it should not have been enabled, which most organisations avoid by keeping it.

Recording the refusals

Write down what was ruled out and why.

Include it in the consultation, because a list of what will not be captured reassures far more than a list of what will.

It also answers the question when the same capability is proposed again next year, which it will be.

The configuration checklist

Six settings to verify before deployment, not after.

Keystroke content: off.

Clipboard content: off, events only.

Screenshots: off, or restricted to allow-listed applications.

Personal application categories: excluded.

Capture hours: working period only.

Individual reporting views: disabled.

Verify each in the agent, not in the policy, and record the verification. A setting assumed to be off is the most common finding in a review.

Explaining what is not captured

Most objection comes from assumed capability rather than actual capability.

Say specifically what is off: keystroke content, clipboard content, personal applications, out-of-hours activity.

Say what is captured: application name, window focus duration, event counts, transitions.

Offer to show a sample of the raw output, which is usually a table of timestamps and application names and settles the matter faster than any assurance.

Publish the configuration summary, which is what makes the explanation checkable rather than a promise.

Excluding by configuration

Policy exclusions fail; configuration exclusions hold.

Applications out of scope not captured at all, rather than captured and filtered.

Personal use, banking, health portals, messaging excluded by application and domain.

Password fields never captured, which requires explicit configuration in most tools.

Screen content off unless specifically justified, and then only for named applications.

Publish the exclusion list, which is what makes the assurance credible and invites correction if something was missed.