Russ Stewart European Head of Continuity, KPMG LLP Forum Vancouver February 25th 2008 Business Impact Analysis Russ Stewart European Head of Continuity, KPMG LLP [email protected]

EPICC Forum VancouverFebruary 25th 2008

Business Impact AnalysisRuss StewartEuropean Head of Continuity, KPMG LLP

[email protected]

1© 2007 KPMG LLP, a UK limited liability partnership, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International, a Swiss cooperative. All rights reserved. This document is confidential and its circulation and use are restricted.

KPMG and the KPMG logo are registered trademarks of KPMG International, a Swiss cooperative.

Workshop Objectives

• Clarify the need for a scalable, re-usable, accessible approach to BIA

• Demonstrate a simple, graphic approach to obtaining the information

• Demonstrate a model for storing BIA information and maintaining interdependencies

• Describe how this BIA model can support a number of uses, including BCM, ITIL, M&E planning, insurance

• Other…..?



BIA Definitions

Disaster Recovery Institute International (DRII)Disaster Recovery Institute International (DRII)

“Identify the impacts resulting from disruptions and disaster scenarios that can affect the organization and techniques that can be used to quantify and qualify such impacts. Establish

critical functions, their recovery priorities, and interdependencies so that recovery time objective(s) and

recovery point objective(s) can be set.”



BIA Definitions

Business Continuity Institute (BCI)Business Continuity Institute (BCI)

“A Business Impact Analysis (BIA) identifies the impacts resulting from disruptions and disaster scenarios that can

affect your organization and employs techniques that can be used to quantify and qualify such impacts.

The BIA will help to establish critical functions, their recovery priorities, and interdependencies, so that recovery time

objectives can be set.”

© 2007 KPMG LLP, a UK limited liability partnership, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International, a Swiss cooperative. All rights reserved. This document is confidential and its circulation and use are restricted.


Some Considerations…



Complexity – number & nature of interdependencies

Financials

TM

D/R plan(mainframe only)

STK Silos DK tape

TM

TM

TM

IBM3090-600JMVS/ESAIMS / ADABAS

Backup by FDR Upstream

HP 3000, K460HP-UX 10, 11.0, 11.2, MPE Sybase 11.9, 12

Sequent

Backup by tar - 8mm

Legato to DLT

ADSM to3490s

OmniBack

Sun EnterpriseSun ULTRASPARC Solaris 2.5.1, 2.6, 7Oracle 8.0, 81

IBM RS/6000, SP2AIX 4.2, 4.3DB2/6000

Compaq Proliant 2500Proliant 5500, NT 4.0

Cheyenne to 4mm

Batch

IBM AS/400OS/400

Inventory

ExchangeCAD/CAM

E-commerce

Lotus Notes

OLTP

CICS

File transfers AIX to HP/UX via Platinum 9.9FTP between Sun - NTDatabase extracts MVS to SP2 via

M Series 4.4

PeopleSoft



Complexity – External Dependencies

Nature of Enterprise



Complexity – Degree of Integration

Nature of Enterprise



Criticality of Processes



BCM Maturity – Where should you be?

Market Differentiator

Cost Effective Process

Sustainable Process

Recoverable Plans

Remediated Plans

React

Control

Transform

Business Enhancement

Service Improvement

Efficiency / Cost Reduction

Risk Reduction

Outcomes

Activities/Goals

• Integrate into existing processes

• Data analysis

• Enterprise view

• Roles & responsibilities definition

• Methods & standards development

• Process (vs. Function) view

• Alignment with production

• Testing

• Technology enhancement

• Linking BC/DR interdependencies

• Identification of interdependencies

• Prioritization of plans and gaps

• Improvement of documentation

• Accountability alignment

• Information enhancement



Emerging Trends

Emerging technologies and operational excellence

Documented plansENABLERS

Up to 99.999% availability of critical business services

Recovery of degraded service levels in 12 to 72 hours

BENEFITS

Traditional threats to physical assets, emerging threats to information

assets

Low-frequency, high-impact disastersRISKS

Continuous availability through management of information and

operational risk

Recovery from single episodes of prolonged downtime

APPROACH

Availability - ensuring financial continuity and customer satisfaction

Recoverability - minimising the financial impact

FOCUS

EMERGINGTRADITIONAL



Before you start a BIA…

Consider:

• Complexity of interdependencies

• External dependencies

• Degree of process integration

• Criticality of processes

As a result, consider:

• Appropriateness of BIA scope & objectives – where do you want your BCM to be?

Ideally we want our BIA approach to be :

• scalable

• deliver accessible outputs

• deliver re-usable outputs



Scenarios / Risks



London, February 1996

South Quay Plaza, Docklands

… Nothing can be recovered



Leeds, June 2007

KPMG Leeds Office



London July 2007

Suspect Vehicle Near KPMG Fleet Street Office



Preston, July 2007

Chemical fire near KPMG Preston office



Risk Scenarios to Consider

• Fire • Flood • Bomb• Contamination• Imminent Catastrophic Event• Natural disaster• Pandemic• Utilities failure• Other ………………………………………………..

In effect too many scenarios (many of which we have not thought of).

BIA needs to be flexible enough to address current and future scenarios.



Where BIA fits into BCM



BCM Context

Business Continuity

Risk Management

Crisis Mgt

Business Recovery

Risk & Impact Mitigation



Crisis Management

Most important decisions made with limited information

Well structured, accessible BIA information improves the impact assessment

Characteristics of crisis management …

• Life & Limb

• Reputation

• Minutes/Hours

• Survival focus

Readiness requirement:

• too late for manuals

• need to exercise regularly

“Wrestle the Gorilla”(Register & Larkin)

“Boiling the frog”



Business Recovery

Detail Recovery Plans put into action

BIA detail used to identify and prioritise actions, and to set MMRs, RTOs, RPOs

• After the initial crisis has been managed• Objective is to recover business functions• Survival Mode - some efficiency loss• Readiness / Exercised

Components

• Business Plans

• ICT

• Facilities

• HRBased on an agreed firm wide strategy…



Risk & Impact Mitigation

• Lessen Impact

• Built into the culture of the organisation

• Embed in normal processes

• The responsibility of all the organisation’s people

Reduce risk through resilience

BIA identifies likelihood of failure of services and assets and relates such to impacts, justifying proportionate resilience measures



BIA Approach



Sources of Advice

• BCI Good Practice Guidelines – Section 2 (Understanding the Organisation)

• BS 25999 – 2 Section 4.1.1

Very sound & recommended

Oriented towards WHAT should be considered

We will focus on aspects of HOW to do it and represent the findings



Understanding the Organisation



Data Flow Diagramming (DFD)

• DFDs have their roots in the UK civil service “SSADM” methodology

• Structured Systems Analysis & Design Methodology

• Used to graphically represent an organisation’s current and planned processes

• Information oriented – however can be adapted to include physical assets

……complement the more “traditional” methods (e.g. questionnaires, structured interviews)

My preference: DFDs as the main approach to information gathering and verification




Key Business Process

Key Third Parties

Data Store






Data Flow Diagrams - Levels

UK Operations

2 Supply Chain 1 Sales Processing

2.1 Stock Allocate

2.2Transport Plan

2.3Urgent Orders



Data Flow Diagrams - Levels



Level 0 : UK Operations

SupplyChain 2.

Sales Processing 1.

Pricing.3

Agency

Logistics

Sales Orders

SOPRef.data

StockFile



Level 0 : Supply Chain Processes

SupplyChain 2.

Logistics

Sales Orders

StockFile

SOPRef.data



Level 1 : Supply Chain

Logistics

Sales Orders

StockFile

StockAllocate 2.1

TransportPlan 2.2

Urgent Orders 2.3

…break down into three component processes

SOPRef.data




Logistics

Sales Orders

StockFile

SalesProcessing 1.

StockAllocate 2.1

TransportPlan 2.2

Urgent Orders 2.3

…Sales processing represented as external to these processes

SOPRef.data




Logistics

Sales Orders

StockFile

SalesProcessing 1.

StockAllocate 2.1

TransportPlan 2.2

Urgent Orders 2.3

SOPRef.data

…data flows added



SupplyChain 2.

Sales Processing 1.

Pricing.3

Agency

Logistics

Sales Orders

SOPRef.data

StockFile

Return to Level 0Return to Level 0




DFD Output:

• Identification of processes that require recovery

• Identification of key third parties (internal & external) that you would need to contact in recovery

• Identification of the ‘things’ (i.e. Services) you depend on – systems, people, assets




Example of Services:

• Email

• Internet Access

• Telephone

• A key Excel Report on the Network Folder

• Administrative Paper Files

• Office building

• Payroll team

etc…



Exercise 1Identify Processes & Services



Exercise 1a – Identify Processes & Services

• Find an interesting person in the group

• List their responsibilities in terms of 5 -9 processes

Does not have to be right first time – iterative review approach



Exercise 1b – Identify Processes & Services

• Represent (draw!) an ellipse for each process on one flipchart

• For each process:

− Number it

− Add Data Stores / Services used in process

− Add third parties used in process

− Draw on data flows

Does not have to be right first time – iterative review approach



SupplyChain 2.

Sales Processing 1.

Pricing.3

Agency

Logistics

Sales Orders

SOPRef.data

StockFile

Return to Level 0Return to Level 0



Obtaining the Facts



DFD input to BIA

Understand your

business

Identify Key Processes

MMR / RPO / RTO / Wait

Contingencies & Fallback

BIA Input

Who to contact

Alternative third parties

Identify key services for the business processes

Identify key third parties



Analysis of Services

The DFD will give a list of Services…




Then add impact ratings…



Impacts

• Key criteria are impacts on: life, limb, reputation, revenue

• Base on loss of service for 48 hours (for example)

• Quantify if feasible, otherwise: High, Medium, Low




Minimum Resource Requirement (MRR)…



Minimum Resource Requirement (MRR)

• In “survival” mode – what is minimum level of that service required

• For period of 10 weeks (for example)

• Not applicable to all services




Wait Time…



Wait Time

• A bit more than Recovery Time Objective (RTO)….

• How long would you wait before invoking contingency or fallback?

• Bearing in mind that invocation is disruptive (and return to normal)

• Key consideration is confidence in service being restored soon




Recovery Time Objective (RTO)…



Recovery Time Objective (RTO)

• Time from invocation of recovery to minimum service restored




Recovery Point Objective (RPO)…



Recovery Point Objective (RPO)

• In effect “how much data can you stand to lose”?

• To what point in time you restore your data to?

• Impacts on back-up regime, e.g.

− Weekly

− Daily

− Real-time mirroring






Exercise 2Analysis of Services



Exercise 2 – Analysis of Services

• In your groups, for each Service previously identified:− Impact : of service failure on process (H/M/L or quantified)

− MRR : minimum resource requirement in survival mode

− Wait Time : how long “do nothing”

− RTO : recovery time objective (for minimum resource restored)

− RPO : recovery point objective (how much data can you lose)



BIA MODEL



BIA Overall Data Model

Process A Process C

Service 1 Service 2 Service 3 Service 4

Componentv

Componentw

Componentx

Componenty

Componentz

Process B



Processes – Quick Recap

Process A Process CProcess B

• View organisation as a collection of processes

• Fits in with the way organisations view themselves

• Fits in with business recovery planning – process orientation

• Processes should be defined at a fairly high level, e.g.:− Sales

− Distribution planning

− Compliance checking

• Organisational chart is a useful guide.




Process A Process C


Componentv

Componentw

Componentx

Componenty

Componentz

Process B



Services – Quick Recap


A business process depends on a number of services, typically:− Information systems (including paper based)− People− Physical assets (eg plant, buildings)




Process A Process C


Componentv

Componentw

Componentx

Componenty

Componentz

Process B



Components

Componentv

Componentw

Componentx

Componenty

Componentz

A service depends on one or more components:

For example, email:− Application software

− Hardware (servers)

− Data (reference & transactional)

− Network / communications



Components

Componentv

Componentw

Componentx

Componenty

Componentz

A service depends on one or more components:

For example, office building:− Cooling

− Power Distribution

− Water Systems

− Building Fabric



Components

Componentv

Componentw

Componentx

Componenty

Componentz

Failure in any one of the components will have the potential to render service(s) unavailable




Process A Process C


Componentv

Componentw

Componentx

Componenty

Componentz

Process B



Interdependencies

Process A Process CProcess B


Componentv

Componentw

Componentx

Componenty

Componentz



An Example of Component Failure…

Process A Process C


Componentv

Componentw

Componentx

Componenty

Componentz

Process B




Process A Process C


Componentv

Data Server

Componentx

Componenty

Componentz

Process B




Process A Process C

DRP System

eSOPSystem

Service 3 Service 4

Componentv

Data Server

Componentx

Componenty

Componentz

Process B




Distribution Payroll

DRP System

eSOPSystem

Service 3 Service 4

Componentv

Data Server

Componentx

Componenty

Componentz

Online Sales



Risks


DRP System

eSOPSystem

Data Server

Online Sales

Likelihood of failure, a key element of risk, exists at this level.

Results in compromise or cessation of service.



Impacts


DRP System

eSOPSystem

Data Server

Online Sales

The impact of a service failure will tend to affect a number of processes, each to a different extent



Impacts

Distribution PayrollOnline Sales

• Impact : High - late delivery of on-line orders• Waiting time : 1 hour• Contingency : none• Fallback : manual planning of emailed and ‘phoned orders

eSOPSystem



Impacts


• Impact : High - reduced sales • Waiting time : 30 mins• Contingency : instruction to customers to email orders• Fallback : instruction to customers to ‘phone orders through

eSOPSystem



Impacts


• Impact : Low - delayed and inaccurate commission payments to salespeople• Waiting time : 2 weeks• Contingency : none• Fallback : manual processing based on last month

eSOPSystem



Impacts


eSOPSystem

Process: Distribution Online Sales Payroll

Impact: High High Low

Wait Time: 1 Hour 30mins 2 Weeks

In Summary…



How to Hold the Information



BIA Data Model

BUSINESS PROCESSDescription

Process Owner

COMPONENTDescriptionLikelihoodResilience

CONTINGENCYDescriptionInvoke Time

BUSINESSPROCESS /SERVICE

ImpactWait Time

RTORPO

Fallback Contingency

SCENARIODescription

COMPONENT/SCENARIO

COMPONENT/SERVICE

FALLBACKDescription

Recovery Time

SERVICEDescription



BIA Data Model


Process Owner

• Description: simple one liner, eg “Payroll Processing”• Process Owner: typically from the organisation chart



BIA Data Model


Process Owner

SERVICEDescription

• Service Description: simple one liner, eg “SAP System”



BIA Data Model


Process Owner


ImpactWait Time

RTORPO


SERVICEDescription

• Business Process/Service• Link entity• eg Payroll / SAP



BIA Data Model


Process Owner


ImpactWait Time

RTORPO


SERVICEDescription

• Impact: H / M / L useful labels• Wait Time: how long before contingency or fallback• RTO: Time from invocation of recovery to minimum service restored• RPO: In effect “how much data can you stand to lose”?• Fallback: alternative service, survival mode• Contingency: other means of providing a similar service




BIA Data Model


Process Owner


ImpactWait Time

RTORPO


SERVICEDescription

• Impact: H / M / L useful labels• Wait Time: how long before contingency or fallback• RTO: Time from invocation of recovery to minimum service restored• RPO: In effect “how much data can you stand to lose”?• Fallback: alternative service, survival mode• Contingency: other means of providing a similar service


….essentially what info we collected doing DFDs



BIA Data Model


Process Owner



ImpactWait Time

RTORPO


SERVICEDescription

• Contingency • Description: simple one liner, eg “Failover SAP to backup site”• Invoke Time : time taken to render contingency operational



BIA Data Model


Process Owner



ImpactWait Time

RTORPO


FALLBACKDescription

Recovery Time

SERVICEDescription

• Fallback• Description: eg “Manual processing using last month’s data”• Invoke Time : time taken to render fallback operational



BIA Data Model


Process Owner




ImpactWait Time

RTORPO


FALLBACKDescription

Recovery Time

SERVICEDescription

• Component • Description: eg “Data server UK/WAT/0998”• Likelihood of failure : H/M/L (can quantify if feasible)• Resilience : comment of resilience measures, eg “RAID”



BIA Data Model


Process Owner




ImpactWait Time

RTORPO


COMPONENT/SERVICE

FALLBACKDescription

Recovery Time

SERVICEDescription

• Component / Service• Link entity : eg Data Server / SAP



BIA Data Model


Process Owner




ImpactWait Time

RTORPO


SCENARIODescriptionLikelihood

COMPONENT/SERVICE

FALLBACKDescription

Recovery Time

SERVICEDescription

• Scenario• Description: eg “Flooding of Datacentre”• Likelihood : H/M/L



BIA Data Model


Process Owner




ImpactWait Time

RTORPO


SCENARIODescription

COMPONENT/SCENARIO

COMPONENT/SERVICE

FALLBACKDescription

Recovery Time

SERVICEDescription

• Component / Scenario• Link entity : eg Data server / Datacentre Flooding



BIA Data Model


Process Owner




ImpactWait Time

RTORPO


SCENARIODescription

COMPONENT/SCENARIO

COMPONENT/SERVICE

FALLBACKDescription

Recovery Time

SERVICEDescription



BIA Model – Example (1)

2h1d1d

RTO

App softw.

App serverData serverNetwork

Risk Comp.

Virus L

d/c fireFloodPower

LLL

1h4h2d

Phone/faxPhone/faxPhone/fax

4h4h4h

FailoverFailoverFailover

4 hours2 days2 days

HML

Sales OrdersDist. PlanningProcurement

LEmail

ScenarioRPOFallbackTime to invoke

ContingencyWait TimeImpactBusiness Process

FailService



BIA Model – Example (2)

2h1d1d2d2d2d2d

RTO

Power CoolingWaterFabric

Risk Comp.

FireFloodWeather

MLLL

1h4h2d

Phone/faxPhone/faxPhone/faxRemoteRemoteRemoteRemote

4h4h4h2d2d2d4h

FailoverFailoverFailoverRelocateRelocateRelocateRelocate

4 hours2 days2 days2 days2 days2 days4 hours

HMLHHHH

Sales OrdersDist. PlanningProcurementMarketingHRFinanceIT services

MSupportServicesOfficeBuilding & D/centre

ScenarioRPOFallbackTime to invoke

ContingencyWait TimeImpactBusiness Process

FailService



BCM Mitigation



Risk / Impact Mitigations

• BIA Model example usage to support :− M&E resilience : maintenance schedules / SLA

− M&E resilience : capital projects

− M&E resilience : state monitoring / BMS

− IT : resilience & failover strategies

− IT : configuration management

− IT : information security

− Building fabric : maintenance schedules / SLA

− Physical security : capital spend / manning / regime

− Health & Safety : regime



Workshop Objectives

• Clarify the need for a scalable, re-usable, accessible approach to BIA

• Demonstrate a simple, graphic approach to obtaining the information

• Demonstrate a model for storing BIA information and maintaining interdependencies

• Describe how this BIA model can support a number of uses, including BCM, ITIL, M&E planning……

• Other…..?



Questions?



Presenter’s contact details

Russ Stewart

European Head of Continuity, KPMG LLP

[email protected]

www.kpmg.co.uk

Russ Stewart European Head of Continuity, KPMG LLP Forum Vancouver February 25th 2008 Business Impact Analysis Russ Stewart European Head of Continuity, KPMG LLP [email protected]

Documents