Collection

Screenshot monitoring without creating a liability

Screenshots are the highest-risk capability in any monitoring product, including ours. A screen capture shows whatever was on screen — a personal message, a medical portal, another person's data. In SnitchOS capture is always on, so the question is not how you configure it. It is whether a client can live with it.

Published · Updated

Start from the risk rather than the feature. A monitoring product that counts application time collects a category of data you can describe precisely. A product capturing screen images collects an open-ended category you cannot describe in advance, because it depends entirely on what the employee happened to be looking at.

That does not make screenshots illegitimate. It makes them the part of the deployment that needs the most explicit decisions.

The five things that determine your exposure

Most writing on this subject treats all five as dials you turn. In SnitchOS three of them are fixed by the platform and only two are yours, so it is worth being explicit about which is which before you sit down with a client.

Screenshot exposure factors and where SnitchOS lands on each
FactorWhat it controlsWhere SnitchOS lands
Whether capture happensWhether any of this appliesAlways on. There is no enable/disable switch, in the dashboard or anywhere else
CadenceVolume of images capturedFixed at one frame every 60 seconds, set at install. Not a dashboard control
RetentionHow long the exposure persistsPlatform-defined: 30 days in primary storage, archived through day 365, then deleted. Not per-client
Viewing accessWho can see themPer client. Grants are per client, roles are Admin or Manager, changes land in a three-year audit history
Who is in scopeWhich people are captured at allPer-person pause, which stops every signal for that person. It is the only exclusion mechanism

Ask what question this answers

The useful test with a client is to ask what decision a screenshot would change. "We want to be able to look" is not an answer that survives a dispute. "We bill a client for contractor hours and need corroboration" is.

Here is where our advice differs from what you will read elsewhere. Elsewhere the conclusion is "then leave screenshots off and rely on application and website activity." We cannot offer you that, because SnitchOS has no off. So if nobody at a client can articulate the question, the honest conclusion is not a configuration change — it is that SnitchOS is currently the wrong product for that client. We would rather you hear that on this page than discover it three weeks into a rollout.

Per-person pause handles the narrower version of the problem. A role whose screen genuinely should never be captured — an HR lead, in-house counsel, an employee assistance contact — can be paused, which stops screenshots and every other signal for that person while the rest of the deployment carries on. It is a per-person switch and nothing finer: there is no way to exempt a particular application, window, or website from capture while leaving that person otherwise monitored.

Cadence and deduplication

Higher frequency does not usually produce more insight; it produces more images to store, secure, and eventually explain. SnitchOS captures one frame every 60 seconds. Frames are skipped while the machine has been idle for more than a minute, and a frame whose perceptual hash matches the previous one is discarded rather than uploaded, so volume tracks actual activity rather than wall-clock time. The interval is written to the endpoint at install; it is not exposed as a per-client setting. Work out the realistic volume per employee per day before you roll out across a client, because that number is not something you can tune down afterward.

Retention is the exposure clock

Retention decides how long a captured screen remains something that can be requested, breached, or disclosed. In SnitchOS that clock is platform-defined rather than per-client: screenshots sit in primary storage for 30 days, move to archive storage through day 365, and are deleted after that. Activity events are kept indefinitely by default. Neither can be shortened per client today. That is worth stating to a client during the pilot rather than during their first data-subject request.

Access is the control clients ask about

"Who can see these?" is the first question employees ask and the one clients are least prepared for. Answer it with a named list rather than a role. In SnitchOS, grants are per client — a Manager sees only the clients assigned to them — and every access change is recorded in a three-year audit history. Combine that with a written statement of which people hold that access and you have an answer that holds up.

Tell people before, and in specifics

Notice that mentions monitoring in general terms but not screenshots is the notice that causes problems later. State that screen images will be captured, at what cadence, who may view them, and how long they are kept. The notice template and employee FAQ both cover screenshots explicitly for this reason. Requirements vary by location — see the notice and consent checklist and involve counsel.

The honest limitation

No configuration makes screenshot monitoring risk-free. Even with a modest cadence, bounded retention, tight access, and clear notice, a captured frame can contain something nobody intended to capture. The controls reduce the probability and the blast radius; they do not eliminate either. If a client cannot accept that residual risk, the correct answer is not a cleverer configuration. It is a different product — SnitchOS captures screens, and that is not something we can switch off for you.

Decide before you deploy, not after

Cadence and retention are fixed by the platform. Access is per client; pause is per person. Work out during the pilot whether that shape fits your clients.