After a lone worker incident,
the first 24 hours

The part of the policy nobody writes until it is needed

Read a dozen lone working policies and they follow the same arc: identify the risks, put controls in place, give people a way to raise an alarm. Then they end. What happens after the alarm — who does what, in what order, and what gets written down — is usually improvised on the day by whoever happened to pick up the call.

That is a problem, because the hours immediately after an incident decide three separate things: whether the person is looked after, whether you meet reporting duties with statutory deadlines attached, and whether you still have the facts when the incident is examined months later. None of the three survives improvisation well.

Hour one: the response, not the paperwork

The first hour has one job — get help to the person and establish their condition. Everything administrative can wait, and trying to do it in parallel is how escalation stalls.

In practice that means: confirm the alarm is real and reach the worker if possible; get the emergency services or a responder to a *specific location* rather than a general area; keep one named person owning the incident rather than several people half-handling it; and, where there is a family or next-of-kin process, know who makes that call and when. Deciding that in the moment is how a family finds out from the wrong person.

The single most common failure in this hour is diffusion: three managers each assume someone else is on it. Name an incident owner at the start, out loud.

Hours two to four: secure what you will need later

Once the person is safe, capture the facts while they are fresh and before systems overwrite them. Ask what the location history shows, what the last check-in was and when, what the alert timeline looks like — raised at what time, seen by whom, acted on when — and what the worker and any witnesses can recall.

Do it now rather than next week. Recollection degrades fast, shifts change, and phones get wiped and replaced. An incident timeline assembled the same day is worth more than a reconstruction assembled from memory a month later, both for the investigation and for the worker's own account of events.

Also make the small decision that avoids a large problem: if equipment was involved in the incident, take it out of use and keep it rather than repairing it. You may need it exactly as it was.

Within 24 hours: the reporting duties

Reporting is where organisations most often slip, usually because nobody was sure whether an incident qualified. The relevant framework in the UK is RIDDOR, and the deadlines are short: a death or a specified injury must be reported to the HSE without delay, with the formal report following within ten days; an injury that leaves someone unable to do their normal work for more than seven days must be reported within fifteen days. Certain dangerous occurrences are reportable even where nobody was hurt.

Two practical points. First, you also have to *record* injuries that keep someone off their normal duties for more than three days, even where they are not reportable — so the internal record is not optional just because the HSE report is not triggered. Second, the reporting decision needs to be made by someone who knows the rules, not by the first manager to hear about it. Write into the policy who that person is.

Violence and aggression deserve a specific mention, because lone workers absorb a great deal of it and report very little. An assault that results in injury is reportable on the same basis as any other injury, and a pattern of unreported near-misses is the thing that makes a serious incident look, in hindsight, entirely predictable.

The same day: looking after the person

An incident does not end when the physical injury is treated. Someone who has been assaulted, threatened, or left injured and alone until help arrived has had an experience that a return-to-work form does not address.

The things that make a real difference are unglamorous: a call from a manager that is not about the paperwork; a clear statement that they will not be sent back to the same situation unchanged; access to occupational health or employee assistance without having to ask twice; and a return to work that is discussed with them rather than scheduled at them. Whether a lone worker raises the next alarm at all is decided largely by how the organisation behaved after this one.

Within the week: what the incident tells you about the controls

The investigation question is not 'did the worker follow the procedure'. It is 'what did this incident reveal about the controls we thought we had'. Four questions get to that quickly.

Did the alarm reach a human who acted, and how long did that take? Was the location accurate enough to send help to? Did the check-in interval mean this was found in minutes or in hours? And was there a near-miss pattern before this that nobody had escalated?

Then change something specific. A review that concludes 'staff reminded of procedure' has changed nothing — the same incident is available to happen again next month. A review that shortens an interval, removes a lone visit, adds a second person to a risk category, or fixes an escalation list that pointed at someone who had left is a control that actually moved.

How Vygard supports the aftermath, not just the alarm

Most of the first 24 hours is a question of records you either have or do not. Vygard keeps the alert timeline, the check-in history and the location trail with the incident, so the timeline you need at hour three already exists rather than being assembled from screenshots and recollection.

Escalation is defined in advance rather than in the moment — who is notified, in what order, and what happens if nobody answers — which is what prevents the diffusion problem in hour one. Howie, our AI dispatcher copilot, briefs whoever picks up the alert in seconds, so the responder starts with the facts rather than working them out.

And because every alert, check-in and response is recorded, the RIDDOR-ready trail and the internal record come out of the system rather than out of someone's inbox. If you want to test your own post-incident process against a realistic scenario, book a demo and we will walk it through with your policy open.