A crisis is an event with the potential to damage the continuity of your business — where operations could stop and you cop severe financial and reputational harm.
Some events are a crisis the moment they happen: a workplace fatality or serious injury, a product involved in public injury, a product defect causing serious harm. Others start as an emergency or a quality issue and escalate into one — a natural disaster, an IT outage past a business day, adverse media at any level.
That distinction matters, because the response is completely different. An incident is handled by a supervisor with a form. A crisis needs a team, a command point, a comms strategy and a log.
Most businesses have a crisis management plan. It's a Word document, it's forty pages, and it's on a shared drive nobody can reach when the IT outage is the crisis.
The problem isn't the content. It's that a document assumes a calm person with time to read it. At 2am, with a fatality on site and a journalist calling, nobody is reading page 23. They're doing whatever they can remember, and half the team is doing something different.
The plan has to run the team, not sit there waiting to be read.
Trigger criteria, so nobody has to argue about whether this counts. Named roles with proxies, because the primary will be on a plane. A defined command centre and comms setup. Role-based checklists so each person sees only their tasks for the current phase, not the whole plan. A meeting rhythm — initial, sub-teams as needed, situation updates every two hours, full team every four. Pre-written proformas and holding statements. A live log that timestamps every decision.
That last one is underrated. When the regulator, the insurer or the lawyer comes asking six months later, the log is the only thing that shows you responded properly. Memory won't cut it.
Emergency response in WorkVault is run by Rod and Rachel Rapids. Rod covers the physical side — the event, the site, the assets, the environment — and Rachel covers the people: first aid, DRSABCD, welfare and the mental health end of it, which is the part that runs long after the event is over.
You build the plan with them by talking it through. They ask the qualifying questions, draft the trigger criteria, the roles and proxies, the command point and the phase-by-phase actions, then file the finished plan into Core Documents as a versioned, reviewable record. When something happens, you open it and Rod walks the response with you step by step rather than handing you page 23.
Everything the event generates lands in the system as it goes — Dave takes the intake in plain English, Sherlock runs the investigation to root cause, and the actions that come out are assigned to a person with a due date and chased to closure. That's your decision trail, built as you go instead of reconstructed later.
Then Peter picks it up at the management review. Emergency preparedness, incidents, welfare and the actions still open all get tabled as agenda items, so what you learned in the worst week of the year actually changes the system.
Run it once a year and after any change to the team. You'll find the same things everyone finds: a key person with no proxy, nobody authorised to speak to media, no holding statement, and a contact list two years out of date.
Finding that in a drill costs you an afternoon. Finding it during a fatality costs a great deal more.
- Anything that can stop the business. A fatality, a product causing public harm, adverse media, a natural disaster, or an IT loss past one business day.
- Triggers, roles, command point, checklists. Plus a meeting rhythm, pre-written proformas, a live decision log, and a close-out covering recovery and employee support.
- Yearly, and after team changes. A plan nobody has run is a document, not a capability. A short scenario finds the gaps while they're still cheap.
- Both 9001 and 45001. Documented procedure, training and improvement on one side; emergency preparedness and worker welfare on the other.
