Who needs to know, and how fast: escalation after an incident
A well-written incident report, produced the next morning, does not help if the client needed to know within the hour and found out from someone else first. Escalation and notification are a separate problem from the report itself, and they happen — or fail to happen — in the minutes right after the incident, not at the point someone sits down to write about it. See incident reports that still make sense six months later for the report itself.
Two different clocks
An incident report can reasonably take time to get right. Notification usually cannot — many client contracts set out specific timeframes for being told about certain categories of incident, and those timeframes are contractual commitments, not general good practice. Confirm what your own contracts actually require, since this varies between clients and is easy to assume rather than check.
What an escalation path needs
- A clear order of who gets contacted first, second and third, rather than everyone being called at once or nobody being sure whose job it is
- Contact details that are actually current, checked periodically rather than assumed
- A defined threshold for what triggers immediate escalation versus what can wait for a routine report
- Out-of-hours cover for escalation itself, since incidents do not confine themselves to office hours
- A record of when notification happened and by what means, alongside the incident record itself
The last point matters because a missed or late notification is, itself, something you may need to account for later — and the only way to show it was not missed is a timestamped record, not a memory of a phone call.
Where this connects to reporting more broadly
A client who learns about a serious incident from your own timely notification, followed by a clear report, forms a different impression from one who reads about it for the first time in a monthly summary. See client reporting: what to send, how often, and what it costs you for how the two connect.
Escalation paths that were never tested
Most escalation procedures are written once and assumed to work. They are executed by an officer at three in the morning, from a list that may be out of date, for a situation the procedure did not anticipate. The predictable failures are a named contact who has left, a number that is no longer monitored, and no guidance on what to do if nobody answers.
Testing the path occasionally — calling the numbers, confirming who is actually on call — is unglamorous and catches all three. So does recording what happened each time the path was genuinely used, because that is where its weaknesses show.
The client's own notification expectations
Clients frequently have their own requirements about what they are told, how quickly, and by whom, and those requirements sit in the contract rather than in the operational procedure. Where the two have never been reconciled, the contractor follows its own process and the client experiences a breach of theirs.
Common mistakes
- Escalation lists that are not periodically verified
- No guidance on what to do when nobody answers
- Client notification requirements never reconciled with internal procedure
- No record of who was notified and when
- Procedures written for anticipated incidents only
- Never reviewing how escalation actually performed after a real incident
What separates a path that works at 3am
Having been tested. Verified numbers, a named person who is genuinely on call, an agreed time limit before escalating further, and explicit guidance on what to do when nobody answers — which is the scenario procedures most reliably omit.
The other distinguishing habit is reviewing how escalation actually performed after each real incident. That is where the gaps show, and it is a far better source of improvement than rewriting the procedure in the abstract.
One practical test: ring the numbers
Take the escalation list for your largest contract and ring each number, in order, on a weekday evening. Note who answers and how long it takes.
Lists decay silently — people leave, numbers change, a contact moves to a role that no longer covers it. Testing the path costs twenty minutes and almost always finds at least one link that would have failed, which is considerably better than finding it during an incident.
- Verify escalation contacts periodically rather than assuming
- Give explicit guidance on what to do when nobody answers
- Reconcile your procedure with the client's own notification requirements
- Record who was notified and when
- Review how escalation performed after each real incident
- Notification and report-writing run on different clocks — notification is usually the urgent one
- Check your actual client contracts for notification timeframes rather than assuming general good practice covers it
- An escalation path needs a defined order, current contact details and out-of-hours cover
- Record when and how notification happened, not just that it eventually did
- Timely notification changes how a client reads the incident report that follows it
About this article
The SecureOptix team
Written by people who work daily with security contractors on SIA licensing, screening and the records that hold up under an inspection.
- Published
- 7 July 2026
- Last revised
- 27 September 2026
- Topic
- Operations
How this is researched, dated and corrected is set out in our editorial standards. If something here is wrong or out of date, email hello@secureoptix.co.uk — corrections to a regulated detail are made as soon as we can confirm them, and the revision date above moves when they are.