What an Employee Monitoring Consent Form Must Contain
A monitoring consent form that is one checkbox saying "I agree to be monitored" is worth nothing. Under GDPR it fails on at least three separate grounds, and in an employment dispute it will not help you. This page lists what a form has to contain to be worth the paper, clause by clause, with the reasoning attached.
We build monitoring software with a consent system in it, so we have a commercial interest in you taking this seriously. We also have a strong interest in not being the vendor whose customers get fined, which is the same direction. Nothing here is legal advice — get your form reviewed by someone qualified in your jurisdiction before you deploy it.
First: consent is usually the wrong legal basis at work
This is the part most vendors skip, and it changes everything downstream.
GDPR requires consent to be freely given. The European Data Protection Board's position is that in an employment relationship this is rarely satisfied, because the power imbalance means an employee cannot meaningfully refuse. If saying no risks your job, your yes was not free.
So for routine monitoring — screenshots, activity levels, application logging — most employers should rely on legitimate interests (Article 6(1)(f)) and document a legitimate interests assessment, not collect consent. We covered how to structure that in the GDPR employee monitoring checklist.
Where consent genuinely is required, and cannot be substituted, is special category data under Article 9. Biometrics processed to identify someone — face recognition, fingerprints — sit here. For those, Article 9(2)(a) explicit consent is typically the only workable route, and then the form below matters enormously.
The practical rule: do not ask for consent to things you will do anyway. A form that says "I consent to screenshots" when refusing means losing the job is worse than no form — it documents that you sought consent, obtained an invalid one, and relied on it.
The nine things a valid form must contain
1. The specific identity of the controller
Legal entity name, registered address, and contact details. Not a brand. If a processor is involved — your monitoring vendor — say so, and name them. If your DPO is a person or a service, give their contact route.
2. Each purpose, separately, with its own opt-in
This is the clause most forms fail. Consent must be granular. Bundling "monitoring, biometric verification and marketing analytics" behind one tick invalidates all of them — Recital 32 is explicit that consent should cover all processing activities for the same purpose, but separate purposes need separate consent.
In practice that means a form with individual, independently checkable items:
- Face verification of tracked work sessions
- Storage of a reference photograph for that purpose
- [each further special-category purpose, on its own line]
None pre-ticked. A pre-ticked box is not consent — that is settled, both in Recital 32 and in Planet49 (CJEU, 2019).
3. Exactly what data is collected
Not "usage data". Name the categories: a facial template derived from a photograph; images captured at intervals during tracked time; the timestamp and result of each verification. If you compute a derived biometric template rather than storing the image, say that too — it is more favourable to you and more accurate.
4. Retention period, as a number
"As long as necessary" is not a retention period. State a duration and the deletion trigger: "Facial templates are deleted within 30 days of your employment ending, or within 30 days of withdrawing consent, whichever is sooner."
If you operate anywhere touching Illinois, this is not optional in a different way: BIPA §15(a) requires a publicly available written retention and destruction policy for biometric identifiers. Publishing a consent form while having no such policy demonstrates awareness of a requirement you are not meeting.
5. Who receives the data
Internal roles that can view it — and be specific, "management" is not a recipient. Any processors. Any transfers outside the EEA, with the safeguard relied on. If your monitoring vendor stores data in a third country, that belongs on the form, not buried in a sub-processor list.
6. How to withdraw, in the same breath as how to give
Article 7(3): withdrawal must be as easy as giving. If consent is one click in an app, withdrawal must be one click in the same app. A form that says "contact HR in writing to withdraw" while consent was a checkbox is non-compliant on its face.
State what happens on withdrawal: which feature stops, what is deleted, and — crucially — that withdrawal does not affect the lawfulness of what happened before it.
7. The consequences of refusing — honestly
If refusal has no consequence, say so plainly; it is the strongest evidence your consent is free. If it does have a consequence — a role genuinely requires identity verification — state it, and understand that you have probably just demonstrated the consent is not freely given, which means you need a different legal basis or a different job design.
The dishonest version of this clause is the one that gets employers into trouble. Do not write "entirely voluntary" if the person will be moved off client work for declining.
8. The rights list, with a working route to exercise them
Access, rectification, erasure, restriction, portability, objection, and the right to complain to a supervisory authority — name the relevant authority. A rights list with no functioning mechanism behind it is worse than none, because it creates an expectation you will fail.
9. Proof of what was consented to, and when
Article 7(1): you must be able to demonstrate consent. That means storing, per person: the identity, the timestamp, the exact wording shown at that moment, the version of the form, and the specific purposes accepted. If your form text later changes, old records must retain the old wording — showing what someone agreed to two years ago is the entire point.
This is where most implementations quietly fail. A boolean column saying consented = 1 proves nothing about what they saw.
A worked example clause
For biometric face verification, a defensible version reads roughly like this:
[Legal entity], of [address], asks for your explicit consent to process biometric data for one purpose: verifying that the person tracking time on your account is you.
If you consent, we will store a reference photograph you approve, and derive a mathematical template from it. During tracked work sessions, images captured by your device camera will be compared against that template. We store the time and outcome of each comparison. Comparison images are [retained for X days / not retained].
This data is visible to [named roles] only, is processed by [vendor] on our behalf, and is stored in [region]. It is never used to assess performance and never shared with third parties.
We delete your template and all associated images within 30 days of your employment ending, or within 30 days of you withdrawing consent, whichever is sooner.
You may withdraw at any time from [exact location in the product] — the same place you gave it. Withdrawal stops verification immediately and triggers deletion as above. It does not affect processing that already took place, and it will not affect your employment, pay or duties.
☐ I explicitly consent to biometric face verification as described above.
Note what that clause does not do: it does not bundle, it does not pre-tick, it does not say "as required", and it does not promise something the product cannot deliver. If your software cannot actually delete a template on withdrawal within 30 days, do not write 30 days.
How this maps to the product
Since we build consent tooling, here is what SCREENish does concretely, so you can judge whether it supports the form above.
Consent is per feature, not per account — each purpose is its own record, given and withdrawn independently. Every give and withdraw is written to an audit trail with a timestamp, so the Article 7(1) demonstration requirement is met by design rather than by someone remembering to log it. Withdrawal is available in the same interface as consent, satisfying 7(3). Face recognition specifically is gated on explicit consent and cannot be enabled for an employee without it — see face recognition time tracking for how the verification itself works.
What the software cannot do is write your legitimate interests assessment, decide your retention period, or tell you whether your jurisdiction requires works council agreement. Those are yours.
The short version
Do not collect consent for things you would do anyway — use legitimate interests and document the assessment. Reserve consent for special category data, mainly biometrics. When you do collect it, make it granular, un-ticked, specific about data and retention, honest about consequences, withdrawable in one action from the same place it was given, and stored with the exact wording shown at the time.
If your current form is a single checkbox, you do not have consent. You have a record of asking.