Most monitoring agents are built by adding features. The hard part is subtraction: deciding what the agent will not collect even though it technically could.
That list is not a legal nicety. It determines the blast radius of a breach, the amount of data you must disclose, and whether an administrator can defend a decision six months later.
What to collect (and why)
| Field | Why it is defensible |
|---|---|
| Session start / end / idle transitions | Answers "was the desk staffed", no content |
| Application and window titles | Answers "was the licensed tool used" |
| File copy / move / print events (path + size) | Data movement, not content |
| USB insert and file write | Exfiltration signal |
| Keystroke count per interval | Workload intensity without content |
Every one of these can be explained in a sentence to the person being recorded. That is the test: if the explanation needs a paragraph of justification, the field probably should not exist.
What to refuse
- Typed content. Full keystroke logging captures passwords, personal messages, medical information, and everything a customer said. Store counts, not text.
- Clipboard contents. It is the single most sensitive buffer on a machine. Store "copy event in app X" if you must, never the payload.
- Screen recording by default. Screenshots on an interval are already intrusive; continuous video multiplies storage by 20–60× and captures whatever happens to be on screen, including unrelated people.
- Webcam and microphone. Almost never justified in an employer-employee context.
- Location outside work hours. Company device or not, tracking after hours is a different legal animal.
- Personal device content. If BYOD is allowed, scope to work applications, not the whole machine.
- Chat and mail bodies. A separate module, off by default, with its own retention.
Why "we might need it later" is the wrong default
Three concrete costs:
- Breach scope. Content you never collected cannot leak. A breach report that says "session metadata" reads very differently from one that says "keystrokes and clipboard".
- Disclosure obligations. More categories means more jurisdictions where you must notify, and longer incident reports.
- Insider risk. Every extra field is something an administrator can misuse, and something you must audit access to.
Make the refusal visible in the product
A refusal that lives only in a policy document is not a product decision. Put it in the UI:
- A "what we do not record" block on the compliance page, in the language of the buyer
- A settings screen where the sensitive modules are off by default and labelled as exceptions
- An audit log of who enabled what, with a date
If a customer asks "can it capture keystrokes?", the honest answer should be "counts, not content" — and the interface should say so before the salesperson does.
The exception path
Some organisations genuinely need content-level audit: regulated environments, a specific leak investigation, shared machines handling sensitive data. Those cases need:
- Written authorisation with a named approver
- A time bound (start and end date)
- Access logging, so the audit is itself auditable
- A removal step when the case closes
That is a very different posture from a toggle that stays on for the whole company for three years.
A test you can run before buying
Ask the vendor for the field list of what the agent sends, then ask them to strike out anything they would not want recorded about themselves. The size of the remaining list tells you what kind of product it is.
We build iMonitor EAM with exactly this list: session and application metadata, file operations, USB events, keystroke counts, on-demand screenshots — and the content modules off by default, on your own server, with a retention job that actually runs.
General information, not legal advice.
Top comments (0)