Building access and security, built for the compliance era.

Facial recognition and other touchless biometric readers have become the default for higher-security environments. In healthcare, food production, and anywhere hygiene matters, eliminating the shared fob or card also eliminates a touch point.

Speed is the practical benefit alongside hygiene. A facial recognition reader processes an entry in under a second. No fumbling for a card, no shared fobs among colleagues, no tailgating because someone held the door for the queue building behind them.

The GDPR concern comes up regularly in these conversations, and it is worth being clear on the answer. Compliant biometric systems do not store photographs. They store an encrypted mathematical hash derived from the facial geometry, and the original image is discarded immediately. The stored value is closer to a coded lock combination than a picture of your face.

That said, biometric data remains special category data under UK GDPR. You still need a Data Protection Impact Assessment, an appropriate legal basis, and clear retention rules. A reputable supplier should support you with template DPIA documentation, not leave you to draft it yourself.

Two features matter a great deal here and do not get talked about enough. They sound technical, but they are the difference between a system that holds under pressure and one that does not.

The question IT departments always ask: what happens when the network goes down?

The answer, on a properly designed system, is nothing bad. Doors continue to operate in offline mode using locally cached access permissions. Entry decisions are made at the reader. When connectivity is restored, all activity syncs back to the cloud. There is no gap in the access log, and at no point do doors default to open.

This matters more than it might seem. Under Martyn's Law or the Building Safety Act, "the network was down" is not an acceptable explanation for an uncontrolled access event. The system has to keep functioning, and it has to keep logging, even when the link to the cloud platform is gone.

The paper sign-in book is a liability. It does not verify identity. It does not check certifications. It cannot pre-screen visitors. And it is unreadable in an emergency, when somebody actually needs to know who is inside.

A proper visitor management module replaces all of that. Visitors are pre-registered before they arrive, with an email invitation that captures their details and any required health or travel declarations. When they arrive, they sign in at a kiosk, their host is notified automatically, and they are issued a time-limited access credential tied to their record.

For contractors, the same workflow can include competency verification. Does this person have a valid CSCS card? Is their DBS current? Has the site induction been completed? The system can check all of that before access is granted, and the record is stored automatically as part of your golden thread for the Building Safety Act.

For schools and colleges working under KCSIE expectations, this is where most of the safeguarding posture lives. A parent volunteer, a peripatetic music teacher, a contractor coming to fix a boiler, all of them go through the same screening before the system issues a badge. The audit trail is what an Ofsted inspector wants to see.

Automatic Number Plate Recognition extends your access control perimeter to the car park, which is often the weakest point in an otherwise tightly managed site. Barriers open automatically for registered staff and expected visitors. Unrecognised plates are logged and can trigger an alert.

Vehicle entry and exit times are recorded against staff or visitor records, giving you a complete picture of site occupancy that includes people who arrived by car and might otherwise have bypassed the main entrance. For a multi-occupancy building or a campus site, this is significant. The reception sign-in tells you who came through the front door. ANPR tells you who actually arrived on site.

For large sites and shared estates, ANPR also solves the long-running problem of reserved spaces being used by the wrong people, without anyone having to manage it manually.

Access control events can be linked directly to your Video Management Software. When a door access event is logged, the system tags the corresponding CCTV footage automatically. A forced door, a failed access attempt, a held-open alarm, all of them are linked to verified video the moment they happen.

If there is an incident, you do not need to search through hours of footage. You pull the access log for the door in question, click the event, and the relevant footage is queued. Incident investigation moves from a slow manual process to a five-minute task.

This matters increasingly for insurer expectations around incident response, and for satisfying regulators who want to see that events can be reviewed promptly. Under the Building Safety Act, evidence that an incident was investigated, documented, and resolved is part of the golden thread. A platform that links access events to verified footage with timestamps makes that evidence trivial to produce.

The access control market has the same structural problem as time and attendance: software companies who do not properly understand the hardware, and hardware resellers who can fit a reader on the wall but do not have depth in the software configuration.

For most of the year this does not matter. The doors open, the dashboard works, the visitor log generates as expected. The split only becomes visible when something goes wrong. A door is not opening for a particular access group. An alarm is not triggering when it should. The dashboard is not reflecting reality.

At that moment you need one organisation to own the problem from reader to cloud. If your supplier cannot tell you, in one sentence, who is responsible for diagnosing and resolving a hardware fault end to end, that is a significant risk to understand before you sign anything.

There is a more subtle version of the same problem. A supplier who presents as fully integrated can still be subcontracting the physical install to third-party engineers who have never worked with the software and have no ongoing relationship with the support team that will look after you afterwards.

The questions to ask are straightforward. Are the engineers who install our system employed directly by you? Will the same team handle commissioning and ongoing maintenance? Who do we call if there is a fault on site six months after go-live, and is that person the one who will turn up?

The answers tell you considerably more about what working with the supplier looks like in practice than a product demonstration ever will. A polished demo is a marketing exercise. A clear answer about who turns up when something breaks is operational reality.

Under Martyn's Law and the Building Safety Act, your access control platform is no longer just an operational system. It is part of the evidence base you rely on if a regulator asks how you manage risk across your estate. The supplier who installs and supports it is, in practical terms, part of your compliance posture.

If a door fails to lock during a drill and your access control provider tells you it is a hardware issue while the company who fitted the reader tells you it is a software issue, with neither accepting responsibility, the gap between them becomes your problem. In a drill that is embarrassing. In an incident, or an audit, or an Enhanced Tier review, it is something else entirely.

Single-vendor accountability is not just a procurement preference. It is the structural decision that determines whether your platform supports your compliance story or undermines it.