The UK Information Commissioner’s Office (ICO) took enforcement action against Serco Leisure and several associated trusts for using facial recognition and fingerprint scanning to monitor staff attendance across dozens of leisure facilities. The regulator ordered them to stop processing biometric data for this purpose and to delete existing biometric records within three months, highlighting the high bar for lawfully using such intrusive technologies in the workplace.
What happened?
Serco Leisure and the relevant trusts deployed facial recognition technology and fingerprint scanners to record employee attendance at 38 leisure centres.
Biometric templates of employees’ faces and fingerprints were created and stored, with the systems used as the default method of clocking in and out.
Employees had limited or no meaningful ability to opt out and use a genuinely equivalent alternative method.
The organisations sought to justify the systems on the basis of preventing “buddy punching” and falsified time records, arguing this made the processing necessary for contract performance and/or legitimate interests.
The ICO concluded there was no valid lawful basis, issued enforcement notices requiring all biometric monitoring to cease, and mandated deletion of biometric data not required for legal purposes. [1]
Why was this a problem?
Biometric data (such as facial images and fingerprints used for identification) is special category data, attracting stricter safeguards under UK GDPR and requiring an additional Article 9 condition, which the organisations had not properly established.
Less intrusive measures as key fobs or card-based systems were available but not seriously considered or properly evidenced, undermining any claim of necessity and proportionality.
Staff monitoring engaged fundamental privacy and employment rights, yet the organisations failed to demonstrate a compelling justification, clear transparency information, or a robust assessment of impacts and alternatives.
As a result, the processing fell short of the requirements of Articles 5, 6 and 9 UK GDPR, and of the ICO’s expectations for fair, proportionate use of biometrics in the workplace.
What does it mean for your organisation?
This case underlines that convenience, perceived efficiency, or fraud reduction alone will rarely justify routine use of biometrics for employee monitoring. Regulators expect organisations to evidence why such technology is strictly necessary, to document why less invasive options will not work, and to embed biometrics within a wider governance framework rather than treating them as an easy fix.
To avoid similar pitfalls, organisations must:
Treat biometrics as high‑risk by default: classify biometric templates as special category data, apply enhanced safeguards, and carry out a documented data protection impact assessment before deployment.
Rigorously test necessity and proportionality: record, in writing, why existing or alternative tools (badges, PINs, time sheets) are insufficient and keep this analysis under regular review.
Nail the lawful basis and Article 9 condition: ensure any reliance on legitimate interests or contractual necessity is properly balanced, and pair it with an appropriate special category condition, such as employment‑law obligations where applicable.
Provide real choice and transparency: offer employees a genuinely equivalent, non‑biometric option without detriment, supported by clear, accessible privacy notices and consultation with staff or representatives.
Embed governance and retention controls: define strict retention periods, deletion procedures for biometric templates, and regular audits of access, accuracy and scope of monitoring.
The lesson is clear: using biometric technology for everyday workforce control is a regulatory red flag unless organisations can prove it is truly necessary, proportionate, and grounded in a robust legal and governance framework.
Tales from the coalface
Each month, we examine Data Protection issues encountered by our clients. This month, we focus on why every organisation needs a robust Security Incident Log, and what happens when incidents are not captured, escalated, and learned from as they should be. A well‑designed log is more than an administrative record; it is a cornerstone of accountability, breach response, and continuous improvement under the GDPR.
Security Incidents Happen. What Matters Is the Record
No organisation is immune to security incidents, whether it is a misdirected email, a lost laptop, a phishing attempt, or a system outage affecting availability. What sets mature organisations apart is not the total absence of incidents, but their ability to detect them quickly, document them consistently, and use that information to reduce future risk. An incomplete or fragmented incident log makes that work almost impossible.
What is a Security Incident Log for?
A Security Incident Log is a central register where all actual and suspected security incidents are recorded, regardless of whether they ultimately qualify as a personal data breach under the GDPR. It should capture, at a minimum:
A brief description of what happened, including systems and data involved.
Dates and times (discovery, occurrence, containment, notification decisions).
Initial risk assessment and whether personal data was affected.
Decisions on notification to the supervisory authority and data subjects, with reasons.
Follow‑up actions, lessons learned, and control improvements.
Why weak logging is a problem
When incident logging is ad hoc, handled in email threads, or underestimated in any way, important details are quickly lost. That creates several risks:
Incomplete breach assessment: Without a consistent log, it is harder to demonstrate whether an event was assessed correctly, or whether it crossed the threshold for notifying the supervisory authority within 72 hours.
Poor trend visibility: If incidents are dispersed across inboxes or ticketing tools, recurring patterns (e.g., repeated mis‑addressed emails, recurring attacker IP ranges) are not spotted and addressed.
Accountability gaps: Under Articles 5(2) and 24 GDPR, organisations must be able to demonstrate compliance. Without a reliable log, it is difficult to show regulators that incidents were recognised, assessed, and managed appropriately.
Weak evidence in investigations: In the event of an audit, complaint, or enforcement action, regulators will expect to see how incidents were recorded, who made decisions, and on what basis.
What good looks like
An effective Security Incident Log is structured, centralised, and actively used by both IT and the Data Protection function. It is supported by a clear policy and standard operating procedure that tell staff when and how to record an incident. Ownership is defined (often the DPO or Information Security team), and the log is reviewed at regular intervals to identify themes and drive corrective actions. Crucially, staff are trained to report “near misses” as well as confirmed incidents, recognising that close calls often reveal important weaknesses.
How to strengthen your Security Incident Log
Organisations that want to improve their logging practices should:
Define “security incident” clearly: Cover confidentiality, integrity, and availability issues, and make clear that staff should report even if they are unsure whether personal data is involved.
Use a single, central register: Whether a spreadsheet or a case‑management tool, make sure all incidents end up in one place, with consistent fields and timestamps.
Integrate the log into breach procedures: Recording the incident should be a formal step in your breach response workflow, not an optional extra.
Link incidents to risk and training: Use log data to inform risk registers, staff training content, and technical improvements, closing the loop between events and action.
Review and report regularly: Schedule periodic reviews (e.g. quarterly) where management and the DPO examine the log, discuss trends, and agree priorities.
A Security Incident Log should not be a dusty document that is only opened when a regulator calls. Treated properly, it becomes a practical tool to demonstrate accountability, refine controls, and show that your organisation learns from its mistakes. If your organisation needs help designing or reviewing its Security Incident Log, aligning it with GDPR obligations, or embedding it into your incident response playbooks, Ambit Compliance can help.
Do not hesitate to contact us at info@ambitcompliance.ie and check further about us on our website https://www.ambitcompliance.ie/.
Contributors to this blog: Gillian Traynor, Dwayne Morgan, and Facundo Heredia.
