The Business Continuity industry, consultants and associations have created a long list of standards, best practices guides, methodologies and certification processes. Sometimes, implementing these recommendations as part of an organizations’ BCM program becomes an obsession or an end unto itself. Perhaps it is time to take a step back and change perspective.
Simplifying the Business Continuity Management Lifecycle would be a start. Why not readjust the approach and expectations of a BCM program? Simply “retargeting” the objective of a BCM program – to the ability to respond to any disruption – can lead to a simplified BCM model, boiled down to Planning, Plan Development and Incident Response.
Planning: If the ultimate goal of BCM is Incident readiness, the planning process can focus on gathering necessary data for generating information useful in that incident response process. To make sound decisions at the time of an incident, Incident Managers require information related to process SLA commitments, financial impacts, regulatory impacts, casualty chains, resource requirements, and other dependencies.
There is already plenty of existing data within organizations – whether in HR or purchasing system, an IT CMDB, or a facility management application – that can form the foundation or the starting point of the planning phase.
Once the data is gathered, identifying the dependencies between the assets – people, facilities, technology, suppliers and other business processes – can be accomplished with a lightweight BIA.
If regulations require, the planning process may include formalized Risk Assessment, BIA, Gap Analysis, Current Capability Assessment, Strategy development and other data collection efforts.
Ultimately, no matter what route is taken, the critical objectives are threefold:
- Identify the most critical Processes and IT Services (those which directly support delivery of the organization’s products and services).
- Stratify the criticality of Processes and IT Services (which, if a disruption need to be recovered first in order to enable recovery of the others).
- Identify critical dependencies (linking the assets on which critical Processes and IT Services rely).
Plan Development: The Planning process should lead to Plan Development. What constitutes a plan?
Business Continuity plans have to provide a sequence of actionable tasks that lead to restoration of one or more business functions, while IT Disaster Recovery plans maintain focus on resuming interrupted IT services. An actionable sequence is important; without one, precious time will be lost developing an action plan – when one ought to already exist.
Developing facility-wide or departmental plans shifts the focus away from restoring tangible assets (such as process, IT services, suppliers and people) simply because their scope of responsibility is too large. By narrowing planning to individual business processes or IT systems, the sequence of restoration for dependent assets (including multiple strategies for different situations) is made easier.
Plans should, when activated, also define an expected time of completion that is associated with the underlying Process or IT Service Recovery Time Objective (RTO).
Roles & responsibilities for executing the various tasks should be assigned and documented in the plans. These assignments have to be flexible enough to accommodate the actual staff resources available for the incident response.
Plans can contain reference materials: embedded supporting documents, forms and lists that might be of use at the time of incident response. Plans have to be exercised frequently to identify gaps, establish validity and maintain their currency.
Incident Response: The only fact that is immediately known at the time of a disruption is that some asset – a facility, people, a process, an IT service, or a supplier – is unavailable. That lack of availability might impact the organization’s ability to deliver critical products or services. Incident Managers need to have access to information that will allow them to quickly analyze the impacted asset(s) as the starting point and identify its downstream impacts to create a picture of current and potential impacts. The data for this decision making is what should have been gathered in the Planning phase.
This incident assessment should naturally lead to the knowledge of which Business Continuity or Disaster Recovery – plans associated with the impacted assets – should be activated. And if those Plans have been carefully developed, they will define the responsibility for plan execution and the resources required to undertake the recovery tasks.
The Planning process and Plan Development efforts have to be aligned to a simple objective: the capability to respond to any unacceptable disruption. Understanding what is needed for effective Incident Response should drive both the Planning and Plan Development phases. Building backward – or applying reverse-engineering – will assure that Incident Managers have everything they need to effectively and efficiently respond to any disruption – not just a predetermined set of ‘scenarios’.
The chief reason this simplified approach to BCM makes sense: it is easier for both Management and participants to comprehend. It helps BCM practitioners to focus efforts across the organization. And it sets simple, obtainable goals. Don’t throw out your BIA process, your risk assessments or your KPI’s. But perhaps it’s time to start looking at them – and your entire BCM program – in a more simplified light.
Related blog:
Assumptions: Business Continuity Plan Killers
