Notice, consent, and monitoring: a deployment checklist for MSPs

The single most common way an MSP creates a problem for a client is deploying monitoring first and handling disclosure afterwards. Almost every other mistake is recoverable. That one is not, because the collection has already happened.

What usually creates an obligation

Requirements are usually triggered by the combination of what is collected, whose device it is, and where the employee is located. As a rough orientation, obligations tend to attach when:

• Activity is attributed to an identifiable individual rather than aggregated
• Screen contents are captured, as with periodic screenshots
• Collection continues outside working hours or off company premises
• Employees are located somewhere with a specific notification statute, or in a jurisdiction that treats monitoring as processing of personal data
• A works council, union agreement, or employment contract covers the workforce

Some jurisdictions require notice. Some require consent. Some require consultation with a body before anything is decided. These are different obligations, and satisfying one does not satisfy the others.

Who has to be told

Employees on monitored devices, obviously. The ones people forget:

• Contractors and temporary staff using company devices, who may be covered by different rules than employees
• Staff in other countries, where your client's home-jurisdiction notice may not be sufficient
• New joiners, who need the notice as part of onboarding rather than as a one-time announcement
• Anyone who shares a monitored device, including support staff who log in occasionally

What a notice usually covers

A workable notice tends to state what is collected, what is not, when collection happens, who can see it, how long it is kept, and who to ask. Being specific about the boundaries is what makes the notice credible to the people receiving it.

SnitchOS publishes a notice template and an employee FAQ written to be handed to staff directly. Both are starting points for counsel to adapt, not finished documents.

What to document before you deploy

• Confirmation that the devices are company-owned or company-controlled
• The date notice was given, and to whom
• Where consent was required, how it was captured
• The named people who may view screenshots and detailed activity
• The retention period that applies, and that it is a platform default rather than a per-client choice
• Anyone whose monitoring is paused, and why
• Who approved the deployment on the client side

If a dispute arrives a year later, this list is what answers it. Settle access and any per-person pauses before rollout rather than after someone asks.

Order of operations

1. Confirm the devices are eligible for workplace monitoring
2. Have the client's counsel confirm the notice and consent position
3. Give notice, and capture consent where it is required
4. Set client access to match the policy, and pause monitoring for anyone the policy excludes
5. Install on one representative test device and confirm behavior
6. Expand in controlled groups

Step two is the one that gets skipped under time pressure, and it is the one that costs money.

The honest limitation

We deliberately do not publish a state-by-state or country-by-country table. Such a table goes stale quickly, and a stale legal table read as current is more dangerous than no table at all. Your client's counsel is the correct source for their jurisdiction, and asking them is a smaller cost than any of the alternatives.