A Top Down Business Impact Analyses Method V5

A Top-Down Business Impact Analysis Method

Gabe GewurtzIS-CP Services Inc.

June 8, 2010

Agenda

• Definition of the BIA• Traditional BIA; Bottom-Up Approach• Several Issues Regarding the Traditional BIA• Re-Focus the BIA• Top-Down Approach & its Results• Bridging the two Approaches

Bottom-Up BIA Approach

Business Impact Analysis• Def 1 : The process of analyzing all business functions and the

effect that a specific disaster may have upon them (DRJ Glossary) .• Def 2: The BIA purpose is to correlate specific system

components with the critical services that they provide, (“Contingency Planning Guide for Information Technology Systems “, NIST, Special Publications 800-34, June 2002 , US Dept of Commerce)

• Def 3: BIA - a mandatory process for evaluating the impact over time of a disruption to an organisation’s ability to operate ``Business Continuity Management GOOD PRACTICE GUIDELINES 2008``, BCI, 2007 (also part of standard BC25999

• Def 4: A process to prioritize business functions by assessing the potential impact that might result if an organization was to experience a business continuity event (BC/DR vendor).

Bottom-Up BIA Approach

Business Impact Analysis: “The BIA is a logical and fundamental first step ... take the results of a BIA and turn them into actionable items.”, Where to begin a business continuity effort, Carl Greiner, August 2006

• Bottom-Up Approach (traditional):– First identify & analyze all disasters that may happen: Risk Assessment– Analyse all the Business Functions & the potential impact of a disaster

• Examine People, Process, technology & Premises supporting each business function• LOBs, business processes, functions, workflows, dependencies, units of work, volumes, load

forecast, timings, criticality, priority, required technology, time to recover technology, required electronic and hard-copy data , what data to recover, required non-tech tools, required assets, required infrastructure (network, hardware, software, etc), capacity planning at recovery site, physical locations, users, support staff, support vendors, everybody's contact info, supporting internal & external services, etc.

• Results in three definitive DRP & BCP design parameters/“requirements”:– RTO (3 – 4 categories)– Criticality (3 – 5 categories)– RPO (3 – 4 categories)

Bottom-Up BIA Approach• Very Thorough, Detailed, well accepted & Correct Approach• The more knowledge of the environment, the better the plan• Problem:

– Very Time consuming, sometimes taking months or even a year– Sometimes the BIA objective & purpose is not clearly stated, if at all– Easy to lose focus on WHY is the BIA needed

• Analysts fail to explain to Management why the detail is needed• Management may allocate only a few weeks/days for the BIA

• Job add: “BIA usually takes 3 months, but management knows what they want, BIA here will take 3 days”

• Stakeholder may have a different agenda for the BIA and stop the BCM project after the BIA.

Re-Focus the BIA

• "Disaster-recovery planning is a complex task, but organizations make it more complicated by throwing everything but the kitchen sink into the plan ... it becomes hundreds of pages ... It's analysis paralysis.“,

– Damian Walsh, Comdisco, ``Planning for the worst: Bring in the best``, BY KATHLEEN OHLSON, NWFusion journal; S P E C I A L R E P O R T Disaster Recovery & Business Continuity, Nov 2001

• ``RTO and RPO may be good objectives for setting SLAs with regard to data recovery, but they are not sufficient for measuring a business continuity solution.``, Asempra Technologies, 2007

Re-Focus the BIA

• “Backup is dead. Long live backup! “, David Freund, InfoStor August, 2004: introduced 3 new recovery parameters :– Recovery Time Granularity, Self-Consistency & Resiliency

• “Evaluating a Business Continuity Solution”, Asempra Technologies, 2007:

Introduced 8 new recovery parameters:– Recovery Time Granularity (RTG), Recovery Object Granularity (ROG),

Recovery Event Granularity (REG), Recovery Consistency Characteristics (RCC), Recovery Service Scalability (RSS), Recovery Service Resiliency (RSR), Recovery Location Scope (RLS), Business continuity Cost (RMC)

• 10 principles for business continuity operations• 1. Understand what you consider business resilience to be.• 2. Grasp what problem it is you are solving … “which one it isn't.”“Business Continuity Checklist”, IBM Advanced Tech Support, June 2007

Re-Focus the BIA

• “There is nothing glamorous about Business Continuity, it’s all about minimizing your losses and managing to stay in business.”

– Sept 11, 2001 tragedy, surviving Chief Operating Officer, American Express, CBC Venture Sept 21 2001

• Single defining statement about BIA, BCM, SCM, DRP, Testing:

Manage your Business Losses to Survive anything– MANAGE: The “C” executives must be in control, what can they tolerate– LOSSES: This is WHAT we need to manage– BUSINESS: The business must drive the process, not technology– SURVIVE: what needs to be done to stay in business tomorrow– ANYTHING: Any disaster scenario

• Chief Operating Officer will do & spend everything to survive.• He/She only cares about what losses can be tolerated before all is lost

and it’s time to file an insurance claim.

Re-Focus the BIA

• Look at the BIA definition again:– Definition 1: The process of analyzing all business functions and the effect

that a specific disaster may have upon them.– Definition 2: A process to prioritize business functions by assessing the

potential impact that might result if an organization was to experience a business continuity event.

• “LOSSES” are not mentioned anywhere; only implied.• Definition Business Continuity Management Program (DRJ Glossary):

– A management and governance process to ensure that the necessary steps are taken to identify the impact of potential losses, maintain viable recovery strategies and plans, and ensure continuity of products/services through exercising, rehearsal, testing, training, maintenance and assurance.

Re-Focus the BIA

Top-Down BIA Approach: “The Problem is How to Manage Losses.”• Identify everything & anything that can be lost in any disaster.

– What, Why/How, When & Where these losses can be experienced.• Prioritize the potential losses Quantitatively or Qualitatively. • What losses can be tolerated without irreparable damage to the

business• Leads to Meaningful Recovery Requirements more quickly

Re-Focus the BIA• Top-Down Approach identifies the Losses & Objective of the BIA• Bottom-up Analysis needed to develop the strategies &

Solutions to Mitigate, Manage & Control the potential losses – LOBs, business processes, functions, workflows, dependencies, units of work,

volumes, load forecast, timings, criticality, priority, required technology, required electronic and hard-copy data , required non-tech tools, required assets, required infrastructure (network, hardware, software, etc), capacity planning @ recovery site, physical locations, users, support staff, support vendors, everybody's contact info, supporting internal & external services, etc.

• Understanding potential Losses gives Focus to the Bottom-up Analysis

Re-Focus the BIA

Examine the Losses• Address:

– What Losses can Occur, – How/Why Losses can Occur, – When Losses can Occur & – Where Losses can Occur

• Get a different perspective of the Recovery Parameters

Top-Down BIA Approach

What can be Lost: DATA (Physical)• Recovery Point Objective (RPO) in hh:mm:ss:

– Technical Def’n: The Point in time at which data must be restored in order to resume processing transactions. DRII glossary

– The minimum time gap between the last physical (data) failure and the point-in-time where data can be recovered. Asempra Technologies, 2004

– Business Def’n: The amount of data that an organization can tolerate losing in a disaster event.

– Measured in time, not volume of data– One of the primary Disaster Recovery planning parameters/requirements– Technology allowing RPO to be near-zero– A Single RPO per Application???


What can be Lost: Data (Logical) Unavailable/Corrupt Back-up

• Corrupted data may have been physically mirrored– Verify backups– Test restores– Retention periods– Transaction, File or Block Journaling– Event Journaling– Recovery Object/Time/Event Granularity, (David Freund, Asempra Technologies)

– Risk Analysis specifically on these scenarios.– Action plan for each.


What can be Lost: Time• Recovery Time Objective (RTO) in HH:MM:SS

– Technical Def’n: The period of time within which systems, applications, or functions must be recovered after an outage. DRII glossary

– Business Def’n: The amount of production TIME the organization can tolerate losing in the event of a disaster.

– One of the primary DR & BC planning Parameters / Requirements– A Single RTO per Application???– How does the Business Function’s RTO compare to the RTO for

supporting application(s) and dependent technology?

Top-Down BIA ApproachWhat can be Lost: People• “Recovery Staffing Objective” in number of staff

– The number of people needed to recover during the recovery phases; business & technology.

– The number of people needed to operate the business function after recovery in the abnormal mode; business & technology.

• This number could be different than normal operations.– People considerations became important after 9/11 & Pandemic fears– Pandemic guideline; expect 35-50% absenteeism

• What if it’s more?• Cross-train to avoid potential loss of skills (single point of failure)

– 9/11 suggests loss of people greater that 50%• Plans need sufficient Detail & Clarity for Anyone to Execute


What can be Lost: Revenue• “Recovery Revenue Objective”

– The amount of Revenue that can be lost during the recovery phase at the alternate location.

• While recovering the technology & business functions & no operations.

• While operating in “abnormal” mode at alternate site(s).• Example: BP Oil is losing Share market value


What can be Lost: Technology (software or hardware)• “Recovery Technology Objective” problematic scenarios

– Identify scenarios that can potentially cause disasters;• Logical vs. Physical Data Loss.• Y2K.• Unsupported Hardware or Software.• Missing source code.• Systems erroneously treated as “do-not-recover” (DNR).• Security Attack. A breach can easily & quickly propagate.



What can be Lost: External Supplier• Suppliers may not have access• Suppliers may run out of supply• May need multiple suppliers


• Suppliers’ Roles & Responsibilities in your Recovery Scenario• Do Suppliers have an Effective Recovery Plan• Are Suppliers’ Proprietary material (Code) in escrow


When can a Loss Occur:• Typically BC & DR Methodologies

– “plan for the worst & hope for the best”• Business Cycles have peaks & “lulls”• BIAs typically yield one RTO per business function &

supporting technology or for the wrong peak.• Develop several RTOs;

– for all peaks, non-peaks, other supporting technologies• Understand & plan when to escalate recovery for each

application


Where can a Loss Occur: BCPs / DRPs are typically site dependent

• Not all sites of a distributed business function or system have equal criticality or priority.

• Some sites have central characteristics, others local.• Some sites may have no recoverable technology, only

recoverable business functions• Some sites with no recoverable technology may need technical

support or reconfiguration from another site• Local Loss vs. Wide-spread or global Loss• Multiple site loss; many DR plans assume single-site outage.

SANSAN

App 1App 1 App 2App 2

App 3App 3 App 4App 4

Where Can a Loss Occur for a Distributed Business Function & Apps

SAN

App 1 App 2

App 3 App 4

Regional Site

SAN

SAN

SAN

SAN

SANSAN

Regional Site

Regional SiteRegional Site

Remote Site

Remote Site

Remote Site

Remote Site

Remote Site

Remote Site

Remote Site

Remote Site

Central Subsidiary Site

Head-office Mainframe Site

Subsidiary DR Site

App xApp x App nApp n

Mirrored Data

SAN

App i

External Site


How can a Loss Occur: Partial outages

• Loss of only some technology may not be a disaster• Partial outages may have contingency plans.

– A “Break-Fix” Incident with Escalation Policy

• How much loss needs to be incurred to declare a disaster? – How much time needs to elapse before a minor loss becomes serious

to result in a declared disaster?

• Should “partial outages” be treated as “full” disasters if the outages exceed SLA expectations?

• Partial outages may not be included in Crisis Management plan


How can a Loss Occur: Partial outages

• Disaster Recovery Plans for “Worst-Case” Technology Scenarios• Business Continuity Plans for “Worst-Case” Business Scenarios• Contingency Plans for something not quite “Worst-Case”• Security Plans for security breaches• Crisis Management Plans deals with triage, escalation, etc.

• A single BIA to deal with requirements for all these plans• “A holistic approach to a business resilience strategy can help

minimize risks, maximize opportunities and address compliance needs simultaneously.”, Beyond disaster recovery: becoming a resilient business, Richard Cocchiara, IBM Global Services, January 2007


Primary Site with several components, SLA everywhere with most critical at User

“hot” Alternate Site with mirrored data several hundred Km away


Primary Site with 1 component outage, SLA everywhere with most critical at User



Primary Site with 1 component outage, SLA everywhere with most critical at User


Bottom-Up BIA

• Now conduct the Bottom-Up Approach:– Identify events that can cause the non-tolerable losses – Risk Assessment of only these events– Analyse the Business Functions that can suffer these losses

& the potential impact of a disaster• LOBs, business processes, functions, workflows, dependencies, units of

work, volumes, load forecast, timings, criticality, priority, required technology, required electronic and hard-copy data , required non-tech tools, required assets, required infrastructure (network, hardware, software, etc), capacity planning @ recovery site, physical locations, users, support staff, support vendors, everybody's contact info, supporting internal & external services, etc.

– Some of the requirements have already been defined


Conclusion• “There is nothing glamorous about Business Continuity, it’s all about

minimizing your losses and managing to stay in business.”• Manage your Business Losses to Survive anything• what losses can be tolerated before all is lost and it’s time to file an insurance

claim.

• Purpose or Focus of the BIA: • Which LOSSES & how much of each can be

TOLERATED?

A Top Down Business Impact Analyses Method V5

Business

bia traditional bia

business functions

business losses

bia definition

bia purpose

bia backup

business processes

business tomorrow