A monitoring tool is an unusual purchase from a security standpoint. You are agreeing to install privileged software on every endpoint you own, and to concentrate behavioural data about every employee in one system run by someone else.
Most evaluations spend their time on the dashboard. The dashboard is the least consequential part.
What follows is the review we would want run on us, which is a reasonable test of whether a vendor is being straight with you.
Start with a field-level data inventory
Ask the vendor for a list of every field the agent collects and transmits, at schema level.
This single request separates vendors more effectively than anything else in a security review. A vendor who has thought about minimisation can produce it, because they had to decide what to collect. A vendor whose answer is a paragraph about activity insights either does not have the document or does not want you reading it.
You need this for three reasons beyond curiosity. It is the input to your DPIA or privacy assessment — you cannot assess proportionality against marketing copy. It is what your notice to employees has to describe accurately, which in Australia is a legal requirement with a notice period attached. And it is what a works council will ask for in Germany or the Netherlands, where the deployment does not proceed without agreement.
Specific things to confirm rather than assume: whether window titles are captured (they frequently contain document names, client names and subject lines, which is a much larger disclosure than "application usage" implies), whether URLs are captured in full or truncated to domain, whether clipboard content is touched, whether file paths are recorded, and what happens with applications the taxonomy does not recognise.
Then the agent, which is your real exposure
The agent runs with elevated privileges on every machine and updates itself from the vendor's infrastructure. That is a supply-chain path into your fleet, and it is the part of the product that can hurt you worst.
Questions worth asking. Are releases code-signed, and can you verify the signature independently? Can you pin a version and stage updates through your own change process, or does the vendor push to everyone? What is the rollback story when a release breaks something? What is the agent's resource footprint under load, and what happens when it cannot reach the backend — does it queue, drop, or degrade the endpoint?
And: has the agent been through third-party penetration testing, and will they share the summary? A vendor who has done this is usually willing to discuss findings at a high level. One who has not will tell you about their SOC 2 instead.
Access, retention and deletion
Three questions about what happens to the data once it exists.
Who at the vendor can see customer data? The honest answer is never "nobody" — support engineers need access to debug. What distinguishes a well-run vendor is that such access is role-limited, requires justification, is logged, and the log is available to you. Ask whether you can see a record of vendor access to your tenant. Few customers ask; the answer is revealing.
Is retention customer-controlled and does it actually delete? A retention setting that hides data from the interface while it persists in storage and backups is not retention. Ask specifically what happens at expiry, and what the backup retention is, because that is usually where the promise fails. Our retention guide covers what periods to set once you know they work.
What does deletion on termination look like? You will stop being a customer eventually. Get the commitment in writing, with a timeframe, including backups, and ask what evidence of deletion they provide.
Data residency and subprocessors
Where the data is processed, not just where it is stored, and the difference matters for cross-border transfer analysis.
Get the subprocessor list. A monitoring vendor typically uses a cloud provider, possibly a separate analytics or logging service, maybe an offshore support function. Each is a party with potential access, and in Europe each needs to be in your transfer analysis. Ask how you are notified of changes to that list — a vendor who can add subprocessors without telling you has made your assessment permanently provisional.
For firms in regulated sectors or with client contracts specifying data handling, check residency against the obligation before the commercial conversation rather than after.
If the shortlist is two mainstream analytics and time-tracking products, ActivTrak vs Hubstaff covers why they are usually not substitutes for each other.
The question that ends evaluations
Ask the vendor to state plainly, in writing, what the product does not collect.
A vendor with a deliberately narrow collection design will answer immediately and specifically — no keystroke content, no screen recording, no camera, no microphone, no clipboard, whatever applies. A vendor whose product collects broadly will produce qualifications, because the honest answer is "very little, if you enable everything."
This matters practically beyond the security review. The "does not collect" list is what makes your employee notice short and credible, what a works council negotiates over, and what you will rely on if someone asks whether their private browsing was captured. If the vendor cannot write it down, you cannot write your policy.
The review is also your incident-response preparation. If the vendor is breached you remain the controller with a 72-hour clock, and you will need the field-level inventory to describe what was lost — if your monitoring data leaks covers that dependency.
What the review should produce
Three artefacts worth having at the end.
A field-level data inventory you can hand to legal and to employees. A record of the proportionality reasoning — what you considered and rejected, which is what a UK or Canadian assessment consists of. And a configuration decision, written down, saying which optional collection you turned off and why, because defaults drift and in two years nobody will remember the deployment was deliberately narrow.
Where ProdView fits
We would rather be reviewed this way. The collection surface is deliberately small — activity and application metadata, never screen content, keystrokes, camera, microphone or clipboard — which makes the "does not collect" list short and verifiable rather than a list of settings. One Rust agent across Windows, macOS and Linux, code-signed, SOC 2 Type II with the report available under NDA. Retention is customer-configurable. Employees see the same data their manager does, which is itself a control: a hidden collection layer is hard to maintain in a product where the subject can see the output.
When not to pick us: your requirement is session recording or DLP. Those products necessarily collect far more, and the review above gets correspondingly harder — but if a mandate requires them, run the review anyway and scope the deployment to the seats the mandate covers.
Try before you commit
Three seats are free forever, which is enough to point your own tooling at the agent and watch what it actually sends. That is a better security review than any questionnaire, and we would encourage it.
General information as of October 2026, not legal or security advice. Certification scope and subprocessor arrangements change; verify current details with any vendor directly.