Every organization faces risks – and some of those risks may result in disruptions or other ‘incidents’. An effective response to an incident requires many things. We’ve combined them into a 5-part “Incident Horizon”: Planning, Preparedness, Initial Response, Planned Response and Extended Response. In this blog we look at the composition of one of those phases of the Incident Horizon.
Planning
For many, the term Business Continuity “Planning” is synonymous with Business Continuity Plans. Unfortunately, that misperception usually leads to inadequate Plans without underlying intelligence. Jumping right in to develop a Plan is like designing the body of a car while ignoring the chassis, engine and drivetrain needed to propel it.
Business Continuity Planning is the systematic gathering of business intelligence. The cumulative results of Planning will help determine the goals and priorities of the organization’s BCM program. At a more granular level, the intelligence during Planning provides the parameters of each Business Process’ or IT Application’s Plan – its risks, impact and dependencies.
At the same time, Planning can also provide verification of what is necessary to meet the organization’s BCM goals. Assuming the organization’s primary products and services are already known, the Planning process should validate which Business Processes are critical to their delivery. The granular view is revealed when Planning uncovers the upstream dependencies – other processes, resources, technology, data – that enable those critical processes to function effectively. Writing a Plan to recover the most critical Business Processes is important – but no more so than planning to recover other assets without which those critical Processes can’t recover.
Risk Assessment and Business Impact analyses can help provide the intelligence – but there is more to Planning than simply running a RA and BIA every year. Until you map dependencies, you won’t discover those hidden relationships that could trip up any recovery strategy.
It’s those Strategies – not the Plans themselves – that are the most crucial step in the Planning process. Risks, impacts and dependencies together provide a clear picture of what could go wrong. That knowledge enables the development of Strategies to respond to any disruption – not just a predetermined set of ‘scenarios’.
Scenario strategies are ‘risk-based’ (response strategies to specific events). Impact-based strategies, on the other hand, enable a response to any disruption – not just that fixed list of scenarios. By understanding what assets are at risk, recovery strategies can focus on recovering those assets, rather than responding to some assumptions about an event that might – or might not – occur as expected.
Of course, the Planning phase of the Incident Horizon does include the development of Response Plans.
But to meet the needs an unknown disruption may require, it is imperative that Plans be actionable – not just lists of contacts and assets. How else can you relate a Plan to the underlying RTO of the assets (Processes, locations, IT elements) it is intended to recover? The actionable tasks in a Plan should have timeframes associated with them – how long should it take to perform each task? With that understanding, it will be possible to discern whether the Plan can achieve its recovery objectives within the RTO window.
Planning isn’t just about writing Plans. Planning is the process of systematically gathering the intelligence necessary to the development of Response Plans for the critical Business Processes and IT componentry on which an organization’s critical Products and Services rely. There are no shortcuts. There are no ‘5 simple step’ methods to avoid the work of uncovering that intelligence.
But in the end, Planning lays the groundwork for Incident readiness. Plans don’t need to be based on assumptions or scenarios – if you’ve done the Planning necessary to develop real, actionable, asset-based recovery strategies.
