Skip to content
LobbyExpress
Search

Analysis

ID scanning and watchlists: where the line is

Scanning a driving licence and checking visitors against a list feels like good security. Often it is more data than the risk justifies. A case for starting with the decision the check will change, and working back from there.

By LobbyExpress Editorial

Many visitor systems can scan a passport or driving licence, read the data from it, and compare the visitor against a list of people who should not be let in. Some can compare a live photo against a stored one. In a demo these features look like a clear upgrade on a receptionist glancing at a card.

They are an upgrade in one sense: they produce more data, more consistently. Whether that is better security depends on what you do with it. An identity document carries far more information than most front desks need, and a watchlist is a list of people your organisation has decided to treat differently. Both deserve more thought than a tick in a feature column.

Our view is simple. Start with the decision the check is meant to change, use the least intrusive method that supports that decision, and do not switch on a watchlist until someone owns it.

Start with the decision, not the feature

Every identity check exists to change a decision: let this person in, let them in with an escort, or do not let them in. If no outcome of the check would change what reception does next, the check is theatre, and the data it collects is a liability with no matching benefit.

Ask, for each visitor type, what you actually need to be confident of. For a delivery driver, it may only be that they are from the carrier they say they are. For a contractor, that they are the named person whose insurance and induction you have on file. For a visitor to a secure area, that the person at the desk is the person who was pre-approved. These are different questions, and they justify different levels of checking.

The figure below sets out a ladder of options. Each rung up collects or keeps more about the visitor. The right rung is the lowest one that answers your question.

A ladder of identity checks, from least to most intrusiveA table of six identity-check options in rising order of intrusion: name typed in; ID shown to staff but not recorded; ID scanned, checked and the data discarded; ID scanned and the image stored; screening against a watchlist; and face matching against stored images. For each, the table lists what is kept, and a row of up to six dots shows relative intrusion, from one dot to six.CHECKWHAT YOU KEEPINTRUSIONName typed inID shown to staff, not recordedID scanned, data discardedID scanned, image storedScreened against a watchlistFace matchingWhat the visitor typedA note that ID was seenResult of the check onlyFull document imageMatch results and the listBiometric templates
The dots show relative intrusion, not a measured score. Most sites find the answer to their real question somewhere in the top three rows.

Checking is not the same as keeping

The most useful distinction in this whole area is between verifying an identity and retaining the evidence. A receptionist can look at a driving licence, compare the photo to the face, and record “ID checked” without storing a single field from the document. Some scanning products can be configured to do the machine equivalent: read the document, confirm it, and keep only the result.

That matters because an identity document is dense with personal data. A typical card carries a date of birth, a home address and a document number, none of which a front desk usually needs, and all of which become your responsibility the moment you store them. The UK and EU GDPR principle of data minimisation asks you to collect what is adequate, relevant and limited to what is necessary for the purpose. Storage limitation asks you not to keep it longer than needed.

Example: what an ID scan captures against what the desk needsAn illustrative example. On the left, a stylised identity card shows the fields a scan can read: photo, full name, date of birth, home address, document number, expiry date and nationality. On the right, each field is marked as needed or not needed for a front desk whose only question is whether the visitor is the pre-registered person. Photo, name and expiry date are marked as needed to perform the check; date of birth, address, document number and nationality are marked as not needed to keep.EXAMPLEA scan can read every field on the card.The question is what you keep afterwards.FIELDKEEP?PhotoFull nameExpiry dateDate of birthHome addressDocument numberNationalityUse to checkAlready heldUse to checkNot neededNot neededNot neededNot needed
Example only. For a desk confirming that a visitor is the person who was pre-registered, most fields on the card are needed briefly or not at all. Your own purposes may justify more; write down why.

If you do decide to store document images, treat them as a separate category in your retention schedule, with the shortest period you can defend, and make sure the privacy notice at sign-in says so in plain language.

Watchlists are a policy, not a feature

A watchlist turns a visitor system into a tool for treating named people differently. Sometimes that is entirely right: a person subject to a court order, a former employee who made threats, someone banned from a school site. But a list that anyone can add to, that nobody reviews, and that nobody can challenge will drift. Names are added in the heat of an incident and never removed.

Before switching one on, settle these points in writing:

Question Why it matters
Who owns the list? Someone must be accountable for every entry.
What gets a person added? Written criteria stop ad hoc additions.
When is each entry reviewed? Circumstances change; entries should expire unless renewed.
Who is told about a match? Matches should reach trained staff, not whoever is at the desk.
What data is held about each person? Hold the least needed to recognise them and act.
How can a person challenge their entry? Data subjects have rights, including to access and rectification.

Some lists bring extra legal weight. Information about criminal offences is subject to additional conditions under UK and EU GDPR, and in the UK the Data Protection Act 2018 sets out when it can be processed. Face matching uses biometric data to identify people, which is special category data. Both are likely to need a data protection impact assessment. These are questions for your DPO and legal team before configuration, not after an incident.

What happens when there is a match

The match itself is where most real harm occurs, because names are not unique. Common names, different spellings, transliteration between alphabets and shared dates of birth all produce possible matches that are wrong. Independent evaluations of face recognition have also found that error rates can differ between demographic groups, depending on the algorithm. A system that treats every match as a confirmed identification will, sooner or later, embarrass an innocent visitor in front of a queue.

Handling a possible watchlist matchA flow diagram. A visitor signs in and is checked against the list. If there is no possible match, sign-in continues as normal. If there is a possible match, the kiosk shows a neutral message asking the visitor to see reception, and a quiet alert goes to a trained, named person. That person verifies the match against the full record. If it is not the person, the alert is cleared and the false match logged. If it is confirmed, staff follow the agreed, written procedure.Visitor signs inchecked against listPossible match?Neutral message“Please see reception”Quiet alertto a named personHuman checkagainst full recordNot themclear and logConfirmedwritten procedureNormal sign-inno alert raisedNoYes
No step in this flow shows the match on a public screen or treats it as confirmed without a person checking. Logging cleared false matches helps you see whether the list itself is causing problems.

Three design choices make the difference. The kiosk should never display a match; it should show the same neutral message it would for any other reason to see reception. The alert should go to a small number of trained people, not to every host or a shared inbox. And a person, not the software, should decide what happens next. Where a system would refuse entry automatically, check with your DPO whether the rules on solely automated decisions apply.

Governance that keeps it honest

The test of a watchlist is not whether it catches someone once. It is whether, a year later, you can say who is on it, why, who added them and when they will be reviewed. Build that into the system from day one: an owner, an audit log of additions and removals, scheduled reviews, and a regular look at how many matches turned out to be false.

The same discipline applies to ID scanning. Review the retention setting at least as often as you review the rest of the system, and check that what the kiosk keeps is what you decided it should keep.

Where to go next

Our guide to GDPR and visitor data covers lawful basis, privacy notices and retention schedules in more depth. Schools weighing identity checks for parents, volunteers and contractors should read visitor management for schools. When you assess a product’s ID and watchlist features, pair this with security questions to ask a visitor management vendor. To see which kinds of product might offer these features, browse the directory, including access control platforms with a visitor module and dedicated VMS products.