Is facial recognition lawful for self-exclusion? A UK GDPR guide for gambling operators

Facial recognition can make self-exclusion work — but only if it is deployed lawfully. Gambling operators are rightly cautious: biometric data is among the most sensitive information you can process, and the Information Commissioner's Office (ICO) has made clear it expects organisations to justify its use carefully.

This guide explains the key UK GDPR questions and how to approach them.

Not legal advice. Every deployment is different. Use this guide to structure your thinking, involve your Data Protection Officer or adviser, and document your decisions.

Biometric data is special category data

In February 2024 the ICO published final guidance on biometric recognition↗. Its central point: when facial images are processed to uniquely identify a person, that biometric data is special category data under UK GDPR.

That has two consequences:

1. You need a lawful basis under Article 6 and a condition for processing special category data under Article 9 (and, where relevant, the Data Protection Act 2018).
2. You must be able to show the processing is necessary and proportionate to your purpose — not just convenient.

The purpose: a strong starting point

Self-exclusion is not marketing or general surveillance. It is a regulatory obligation designed to protect people who have asked for help. Licensees must prevent self-excluded customers from gambling, and the Gambling Commission has taken enforcement action where venues failed to do so.

That gives operators a clearly defined, protective purpose to assess against. How it maps to the Article 6 and Article 9 conditions is something to work through with your adviser and record in your DPIA.

Carry out a DPIA first

The ICO's guidance indicates that biometric recognition will almost always require a Data Protection Impact Assessment, because it involves special category data and often systematic monitoring of publicly accessible areas. Your DPIA should cover:

• Necessity: why manual methods (photo folders, ID checks) are not sufficient on their own.
• Proportionality: who is enrolled, where cameras are, and what is stored.
• Accuracy and fairness: how the system performs, and how staff confirm matches before acting.
• Security: encryption, access controls and where data is hosted.
• Retention: how long templates and alerts are kept, and how they are deleted.
• Rights: how people can access their data or raise concerns.

Design choices that reduce risk

Good system design makes compliance easier:

• Enrol only the people you need to. For self-exclusion, the database should hold people who have self-excluded, not every visitor.
• Don't retain non-matches. Faces that do not match the database should not be stored.
• Keep a human in the loop. An alert should prompt a trained member of staff to confirm and act — never an automatic ejection.
• Minimise what staff see. Show what is needed to act: the match, the name, the exclusion period.
• Signage and notices. Tell customers, clearly and before entry, that facial recognition is in use and why.
• Delete at the end of the exclusion period, in line with your retention policy.

Every deployment is judged on its own merits

The ICO's approach to biometric recognition is not a blanket yes or no. Its guidance expects organisations to show that their specific use is necessary, proportionate and fair, with safeguards built in and documented.

That works in operators' favour when the purpose is right. Self-exclusion — where the people in the database have asked to be identified and kept out — is a very different proposition from blanket surveillance of every customer. A narrowly scoped system, with a clear protective purpose, a completed DPIA and a human confirming every match, is far easier to justify than one that tracks everyone who walks through the door.

How ClientScan supports compliant deployment

ClientScan was designed for self-exclusion from the outset, as Biometric Update reported↗ at launch:

• The database holds enrolled individuals — for example, people who have self-excluded, including via the Self Exclusion Portal↗, where individuals can upload their own images.
• Alerts go to staff by WhatsApp, email or on-screen for human confirmation.
• Data is held in a central cloud database with a security-first approach, and ClientScan is Cyber Essentials certified.

Talk to us about your DPIA — we can explain exactly how the system processes data so you can document it accurately.

Checklist

• DPIA completed and signed off before go-live
• Lawful basis and special category condition documented
• Clear signage at every monitored entrance
• Privacy notice updated
• Retention periods set and deletion automated where possible
• Staff trained to confirm matches and respond discreetly
• Review scheduled, e.g. annually or when anything changes