Do BIA results belong in your Business Continuity Plan?

This question is as old as Business Continuity Best Practices.  But there is a logical answer that many organizations (and most BCM Auditors) fail to recognize.

That simple answer: No.

But this would be a very short blog if some explanation didn’t accompany that short answer.  So let’s see if I can make the logic clear½

The chief purpose of a BIA is to gain an understanding of what’s important to the enterprise.  An enterprise-wide BIA enables an organization to rank its Business Processes and IT Applications in order of criticality to the delivery of the organization’s Products and Services.  That ranking enables the organization to prioritize which Processes and Applications – if impacted by a disruption – should be restored first (or which Recovery Plans should be activated first).

How that stratification of criticalities is derived will vary from BIA to BIA.  What is the best method of conducting a BIA is a subject for a different discussion.  Whatever method is used, if it is applied consistently across the enterprise, the results should prove useful.

Secondarily, the BIA can facilitate the organization’s Information Technology group’s understanding of Business Processes’ dependencies on specific IT Applications.  This informs the IT Disaster Recovery Plan sequencing, if applied properly.

Depending on how the BIA is conducted, the results can yield valuable information about dependencies of Business Processes and IT Applications (both upstream and down).  Unfortunately, many BIA’s attempt but fail to capture dependency information accurately.  Often this is a result of a flawed BIA Survey (see our earlier blog).  But valid dependency information has exceptional value.

To recap, the BIA yields three valuable results:

  1. Prioritization and Sequencing (what’s most important to the delivery of Products and Services, and in what Sequence should they be restored, if impacted)
  2. Business Process requirements for IT Application recovery (which Applications are most important to the highest priority Business Processes, and what are their RTO desires?)
  3. Mapping of Business Process (or IT Application) dependencies

You might protest that my list is incomplete: that I’ve forgotten the Impacts on individual Business Processes.  But I haven’t.  Those individual impacts are crucial to gaining an understanding of enterprise-wide Prioritization; but alone, none of them provide any real value to the planning process.

(Bear with me for just a few more points½)

Of those three valuable results, which ones belong in your Business Continuity Plan?  None.

1)      The Priority (and Sequence) of individual Business Processes (and the Plan developed to recover each of them) is important, but not the entire prioritized list.  A ‘Tier 1’ (highest priority) Business Process should have a Plan – and that Plan should note it’s priority – but the list of other rankings adds no useful information to the Plan

2)      Business IT Application requirements are a fundamental building block for creating a business-centric IT Disaster Recovery Plan.  The BIA results that reflect those rankings inform the ‘order of battle’ for IT recovery, but the list doesn’t serve a purpose once the DR Plan is developed.

3)      Dependency knowledge is crucial to developing a Business Continuity Plan.  Unless you base your planning on predetermined scenarios (more about that in another blog), each Plan should address the strategic requirements to respond to the loss of a critical upstream dependency.  Once those have been addressed, there’s no need to include the list in the Plan.

What about all those downstream dependencies the BIA uncovered?  Those are extremely valuable for Incident Managers – enabling them to understand the cascade of impacts across the organization.  But as a Plan owner (or Recovery Team) there’s nothing you can do about those downstream dependents.  If they’re critical, they should have their own Plans to deal with the disruption of your Business Process.

Does a copy of the BIA results belong in a Business Continuity Plan?  The answer should be obvious: No.  The information derived through a BIA process is crucial to developing viable Plans.  BIA results provide critical decision support for Incident Managers.  But its inclusion in a BCP adds no discernible value.  It just takes up space.

If you are a big fan of thick ring-binders, go ahead, add the BIA results to your Plan (just put it at the end, where it won’t interfere with executing the Plan).  If your auditors demand that the BIA results appear in your Plan, by all means comply.  If those same auditors demand that the BIA results appear at front of your Plan – ask them to read this article!

SHARE:
Jim Mitchell

Jim Mitchell

A frequent speaker at Business Continuity conferences, many of Jim Mitchell’s blogs can be found elsewhere on eBRP’s website and has published articles in DRJ, Continuity Insights and Continuity Central. Jim has more than 20 years of experience in Business Continuity; if you don’t agree with his opinions – he won’t be surprised.

Related Posts

Enterprise Resiliency: Navigating Through Disruptions

Enterprise Resiliency: Navigating T...

In today’s threat landscape, the ability of an organization to…
Orchestrating BC/DR Testing: Virtual – Emergency Operations Centers

Orchestrating BC/DR Testing: Virtua...

  Enhancing Planning and Logistics Management  Coordinating BC/DR tests involves…
Insights into creating a successful Disaster Recovery Test – Part 2: Preparation

Insights into creating a successful...

Insights into creating a successful Disaster Recovery exercise – Part 1: Objectives

Insights into creating a successful...

Aligning Cyber Incident Response Planning with Your BC/DR Program

Aligning Cyber Incident Response Pl...

Cyber disruptions – and their impact on both reputations and…
What Can You Do when your BCM software Relationship Falls Apart

What Can You Do when your BCM softw...

“This isn’t working.”  “I’ve changed.”  “I don’t see a future…
Aligning BC/DR to CSIRP Challenges

Aligning BC/DR to CSIRP Challenges

The immediate reaction to a cyber-security incident is the FUD…
Technology Modeling – the eBRP Way

Technology Modeling - the eBRP Way

Definition: Technology modeling is a point-in-time snapshot of an Enterprise’s…
eBIA – The eBRP Way

eBIA - The eBRP Way

Definition: A Business Impact Analysis (BIA) is the cornerstone of…
Threats, Impacts, BCPs

Threats, Impacts, BCPs

Within Business Continuity circles there is ongoing debate about the…