The locking system only knows today

Someone leaves the organisation. Accounts are disabled, the laptop comes back, the transponder ends up in a drawer. A year later somebody wants to know when this person's access to the server room was withdrawn.

The locking system cannot answer that. It holds the current state, not the decision behind it: who can unlock a door today is in there. Who could yesterday, and why that ended, is not.

A question about history

ISO 27001 A.7.2 and the BSI building blocks of layer INF require evidence of who has access to areas worth protecting, and that authorisations are withdrawn on departure or transfer. That is a question about the record, not about the state, which is precisely why the system does not answer it.

Four elements carry this: the locking system as the bracket, the access area as the thing being unlocked, the authorisation group as a bundle of areas, and the authorisation as an assignment to a person, with issued medium, date of issue, reason and expiry.

Revoke rather than delete

An authorisation that no longer applies is revoked. Date, reason and whether the medium was returned all remain on record.

This sounds like a detail and is the actual purpose of the register. A deleted record proves nothing: in an audit it cannot be distinguished from an authorisation that never existed. Evidence that something was withdrawn only exists if the transaction stays. Deletion is therefore reserved for data-entry errors.

The reason is mandatory. “Departure”, “transfer” or “medium lost” is exactly the detail that gets asked about.

The transponder without a number

Every authorisation records which medium was issued and its identifier. Printed number or serial feel like pedantry until a transponder goes missing. Without the identifier you know that someone held a medium, but not which one, and you cannot block it in the system.

What the cockpit shows first

Three figures, matching the three questions asked in an audit. Expired, not revoked: the time limit has passed, but the authorisation is still live in the system. This is the classic finding with contractors and temporary staff. Alongside it, groups with overdue review and areas with high protection requirements, each with the number of groups that open them.

Groups without a review date deliberately do not count. A missing date is a statement, not a reminder, otherwise every newly created group would inflate the figure.

No replacement for locking-system software

The register programs no locks. It is deliberately vendor-neutral, because mechanical systems, electronic systems and mixed estates run side by side and all have to be manageable. Today it is maintained by hand.

Two fields are prepared for a later reconciliation: manufacturer records which system is the leading source, and identifier in the leading system holds the reference used there. Anyone planning an integration should maintain both from the start. It costs little and saves manual matching later.

More on the physical access authorisations module page.