Testing the Fallback Before You Need It

Every site has a fallback on paper. Very few have one that has been used deliberately while somebody was watching, which means the first real test happens during an outage, with three hundred people arriving and nobody able to stop and read a manual.

The alternative described in “Testing the Fallback Before You Need It” must produce a record as usable as the primary method. A team assessing this product guide for remote employee productivity monitoring should run the full fallback from clocking through approval and payroll, then compare delay, correction effort and employee access without making the alternative a penalty.

The drill takes forty minutes and it is the cheapest insurance in the subject. It also reliably finds three or four things that are broken, none of which were visible from the configuration.

For an independent benchmark relevant to “Testing the Fallback Before You Need It”, consult the HSE work-related stress guidance. Use it to test notice, accessibility, security, recordkeeping, retention and exception handling against the real operating process rather than treating a device report as self-explanatory evidence.

The three scenarios to run

One terminal dead. Pull the power on a reader at a quiet hour and see what happens: where do people go, does the adjacent terminal have capacity, does anybody know.

Network down. Disconnect the uplink and present credentials. The point here is to observe the configured behaviour rather than to read about it, and to check that the buffered reads arrive correctly afterwards.

One person refused. Have somebody present a finger that will not match and run the full fallback path, timed, including finding whoever has to be found.

What the drill usually finds

Codes that were issued and never activated. Cards enrolled on the access system but not the time system. A terminal whose offline behaviour is not what the documentation claims. A second terminal that turns out to be on the same network switch as the first, so an outage takes both.

And, most commonly, that nobody on the early shift knows what the fallback is. The procedure exists, it was circulated by email eighteen months ago, and the people who need it have never seen it.

Who should be in the room

Whoever is at the entrance at shift change — which is a supervisor and possibly a security officer, not the project team. The purpose is to find out what those people will actually do, not to confirm that somebody in an office understands the design.

Run it on the early shift, at the real hour, with the real people. A drill run at eleven in the morning with the HR manager present proves that the system works under conditions it will never face.

Writing down what to do

One card, laminated, at each terminal. Three lines: what to do if the reader will not read you, what to do if the screen says no connection, and who to call if neither works, with the number.

It sounds trivial. It is the difference between a ten-minute disruption and a morning of improvisation, because the information needed at that moment is small and specific and currently lives in a document nobody can reach from a doorway.

The spare, and whether it is really a spare

If the plan depends on a spare terminal, take it out of the box during the drill and connect it. A configured, tested spare on a shelf is a spare. A factory-fresh unit that needs a network address, a licence key and a template sync is an object that will take two days to become useful.

The same question applies to the paper sheets. If the plan is paper, are the printed templates actually on site, at the entrance, where the person running the shift change can find them at six in the morning.

How often

Once a year is enough, and after any change to the terminals, the network or the enrolment arrangements. Put it on the same calendar as whatever else gets tested annually, because a standalone reminder will be deferred indefinitely.

Record the date, who took part, what was found and what was fixed. That record is also the answer to the question an auditor or an inspector will eventually ask about business continuity for time and attendance, and it is a question most sites answer with a shrug.

The one scenario nobody runs

Power. A terminal on a circuit that goes down takes the reader, the screen and any local store with it, and on sites with battery backup the backup has usually never been tested.

Include it in the drill: pull the breaker, not the plug, and see what happens to the device and to the entrance. The common finding is that the door releases and the clock does not, so three hundred people walk in with no record of having done so, which is the worst of the available outcomes and the one nobody has pictured.