Emergencies and Business Continuity
This article suggests that the use of Business Continuity techniques could provide help in some emergency situations. The author has no intention of commenting on actual events or the activity of involved parties therein. Situations are referred to only in general terms and simply used to provide a context for discussion.
A recent tragic event involving fire at a London high rise building have raised, in my view, a serious challenge from a Business Continuity perspective. The Emergency Services have observed, as I understand, that there is no benefit in providing recovery plans for situations that are so extreme as to be unanswerable and unique. That makes a lot of practical sense. Do not try to evacuate the stricken building if there is no safe escape path to follow. Likewise, do not plan for a recovery that cannot be launched and driven to a successful end. That is a sensible and responsible stance, but it is incomplete.
Regardless of circumstance a valid recovery plan must cater for all possible disaster events. It may well be that the event is so far reaching, such as a natural or military catastrophe, that one’s own recovery plan becomes a mere sub-set of an overall strategy. Nevertheless, all possibilities must be catered for at some level of planning. The recovery plan scope defines what each plan does and points to where each excluded recovery is covered. There can be no circumstance that has neither a planned recovery response nor an explicit exclusion. Further, where a specific disaster event is excluded its profile needs to be defined.
For instance, say the event is a building fire initially the result of the failure of domestic equipment. It later transpires that the building had poor communal safety procedures and later still that the building did not have a properly fire-retardant design. The initial fire triggers the first level of planning and recovery. Get the people out. The Emergency Services have the resources, skill and courage to carry out this recovery. However, their work is impeded by the poor communal safety procedures. Folk are running about spreading panic, trying to use the lifts, getting in the way. More fatally Emergency Services work is stopped altogether in some instances by the design failing of the building. Fire spreads rapidly and cannot be controlled. In as far as the Emergency Services mission to save lives fails it does so because their level of the recovery plan will not work in isolation from the higher-level fire prevention plans.
This may all seem like being wise after the event. It isn’t. It’s being wise before the event which is what Business Continuity planning is all about. Running the scenario backwards suggests a way forward.
If the building had been designed with fire retardance in mind, if the building occupants had fire drill training and if the tenant had been more aware of the danger then the Emergency Services might not have been required. So, the levels of recovery plan may be:
- Plan for all new build and all refurbishment to include fire resilience.
- Plan for all multiple occupants to have fire awareness training.
- Plan for all domestic equipment to include fire safety features.
- Enable recovery at the Operational level.
Now this not going to happen. People will be faced with other priorities, people will move on, people will forget.
What could happen is that the essential content of each of those plans (1-3) be fed along to the operational level. Whether or not a building behaves predictably in a fire could then, to a useful degree be pre-determined. This would allow the Emergency Services to dynamically adapt their recovery plan to the actual risk. Of course, the Services will go in anyway but forewarned is forearmed.
Business Continuity, as a discipline, offers techniques to help feed recovery requirements and capabilities to the operational level. These are expressed via international standards that are both generally understood and specifically relevant to our challenge. For the seasoned planner I’m referring to ISO22301 (Business Continuity), ISO22320 (Incident Response) and ISO22330 (Crisis Management), but that does not really matter here. What does matter is that we are not left alone trying to reinvent the recovery wheel. People have been there already and sometimes got it right and sometimes blundered badly and learnt thereby.
Let’s have a fire-based example, but first clear up a point. “Business” here means any process. In this context putting out a fire is business, as is checking compliance with a building standard or teaching basic safety.
A key Business Continuity technique is Business Impact Analysis (BIA). BIA examines each business process that makes up the overall operation and asks what would happen to the operation if that process stopped. Users and implementors of that process and operation are both asked the same question. If the answers are along the lines of “not a lot” or “someone may get told off sometime” then move on. However, if the answers are like “stop that process then the whole operation comes to a halt” then we have detected an impact. The critical process is examined to see what it depends on what it delivers and what depends on it. For instance, putting out a fire could be said to depend on finding its source and arriving with the correct skills and resources to deal with the fire. The process of fire containment and extinguishment follows. Once done dependent tasks such as declaring the building safe follow. This chain of input-process-output may break if for instance the fire cannot be contained. In this example a standard model for the process of putting out the fire has been used but has failed. That is because the Level 1 (see above) input was not picked up by the Level 4 Operational team. So, they were not aware that the expected fire resilience was not in place in this building. If they had been, a different recovery plan might have been used with a better outcome.
In theory the best thing to do is to survey every single building and have a recovery plan based on its defects. In reality, buildings fall into a variety of categories and the best shot may be to have a model for each category. But how do we know that might work? Business Continuity has another trick up its sleeve, Disaster Recovery (DR) testing.
So, you take the critical output from the BIA, the chain of vital activities, and create a recovery procedure for each category adding in special steps as required by the differing exposures of each category. Build a version of each building category and set fire to it. Then you try to put the fire out using the procedure designed for that category. DR testing is focussed on failure not success, so we are looking for things wrong with the recovery procedure. For a better DR test a vital process or support may be removed or inhibited. Something like: “OK guys you put the fire out now try doing it again without any telecoms”. Testing goes on as long as it can be afforded, each cycle looking to see what happens if a vital process cannot be used and trying out alternatives. Finally, in DR speak all single points of failure are eliminated. You may not get there but each attempt makes the plan stronger.
In addition, as the DR runs as a single event driven plan the role played by each Emergency Service can be coordinated so that each service deploys their skills and resources at the correct moment. Again, using these same Business Continuity techniques, that combined deployment can be tested and, if used for real, tuned to the emergency circumstance.
What this is leading up to is the suggestion I started with that Business Continuity practices can be used in advance of any potential emergency event to pave the way for quicker recovery.
By Roger Jarvis, MBCI