Notice, and What People Should Be Told
The seven things a monitoring notice has to contain, why the notice is also a design document, and what to do about systems that were installed without one.
A monitoring notice has to be specific enough that somebody could act on it. "We may monitor use of company systems" tells nobody anything, which is why it is the sentence most handbooks contain and why it answers nothing when the question actually arises.
The control described in “Notice, and What People Should Be Told” should be matched by transparent operating rules. Organisations considering examine the platform overview for getting teams to meet deadlines can make that use more credible by publishing the purpose, selecting only necessary settings, limiting manager access and fixing a review date before the first record is collected.
What is legally required differs by jurisdiction, by sector and sometimes by agreement, and is a question for somebody qualified in the place concerned. What follows is the operational version, which is a higher standard and considerably easier to write.
A broader reference for the question in “Notice, and What People Should Be Told” is the Ontario employment standards guide. Read it alongside the local facts so that an external framework informs the assessment without replacing case-specific judgement.
The seven things
- What is collected, named system by system.
- When it is active, including whether it runs outside working hours.
- What it is used for, specifically.
- Who can see it, by role.
- How long it is kept.
- What happens if something is found.
- Who to ask, by name or role.
Seven lines per system. Most organisations can write six of them and stall on the second, because nobody has checked whether the tracking stops at six o'clock.
The notice as a design document
Writing the notice is the cheapest design review available. Anything that cannot be described comfortably to the people it concerns is worth reconsidering on that ground alone.
That test catches the deployments that cause trouble, and it catches them before the money is spent rather than afterwards. It also surfaces the settings nobody chose, because describing them requires finding out what they are.
Specific beats general
A general warning covers everything and informs nobody. A specific notice — this system, this data, these people can see it, kept for this long — is both more useful and easier to stand behind.
It also constrains the organisation usefully. A notice that says data is used for payroll accuracy is a commitment not to use it for something else, which is a discipline worth having.
Systems installed without one
Common, and fixable going forward rather than backwards. The sequence is to inventory what is running, write the notice, issue it, and decide separately what to do about data already collected.
That last decision is a question for somebody qualified where you operate. What is not advisable is continuing to run undisclosed monitoring on the basis that nobody has asked.
Changes, which need their own notice
A system whose scope widens — continuous tracking rather than check-ins, screenshots added to application logging, retention extended — is a new arrangement and needs telling again.
Scope widens quietly, usually through a vendor update or a configuration change made for an unrelated reason. Reviewing the notice when anything changes is the only thing that catches it.
Who the notice is for
The people monitored, obviously. Also their managers, who are frequently less clear about what is collected than the people they manage and who will be asked.
And whoever handles a case, because the scope of the notice determines what can reasonably be relied on. A manager producing data nobody was told about has created a problem larger than the one being investigated.
The conversation it prevents
Almost every dispute about monitoring is a dispute about surprise rather than about the monitoring itself. People object far less to being told what is collected than to discovering it.
That is worth knowing, because it means the notice is not an administrative cost attached to the system. It is most of what determines whether the system is accepted, and it costs an afternoon.
Where the notice lives
Not buried in a handbook nobody opens. The notice belongs where somebody would look for it and where it can be shown to have been issued: with the contract, in an induction record, in a message sent to each person.
Evidence of issue matters here for the same reason it matters for any rule, and a notice that cannot be shown to have reached people is a notice that will be argued about at exactly the wrong moment.
Reviewing it against reality
Once a year, take the notice and compare it with what each system is actually configured to do.
Drift is the normal state: a vendor update adds a feature, somebody enables a module, retention is extended for storage reasons. The notice quietly becomes inaccurate, and an inaccurate notice is worse than a general one because it is a statement that turned out to be untrue.
Keeping the inventory
One page: each system, what it collects, when, who sees it, retention, date of last notice, date of last review.
That page is both the notice's source and the answer to every question in this section. Organisations that keep it find monitoring questions easy; those that do not have to reconstruct the answer from vendors and administrators each time anybody asks.