If Not a BIA Survey, What? (Part 1)

Some time ago eBRP posted a blog article I chose to call “The BIA Survey: an Effort in Futility

I’ve been asked why I haven’t published a follow-up article (as the original implied).  It’s less lack of inertia and more a wish to avoid controversy.  Not everyone agreed with my original premise; fewer still may agree with my solution.

The Business Impact Analysis (BIA) Survey has evolved over time into an often massive undertaking.  Organizations devote 6 months or more to determining the Survey questions, distribution, collection, collation, analysis – and the inevitable follow-ups to resolve discrepancies, anomalies and misconceptions.  Upon completion, not only are the results suspect (see my original article) but during the process, organizational changes often make some results invalid.

At the dawn of Business Continuity Management (evolved from IT Disaster Recovery Planning for mainframe recovery), BIAs focused on Impacts.  That’s why it’s called a BIA!

BIAs originally focused on 4 major Impacts:  Customer, Regulatory, Image and Finance.  Time (and generally accepted practices) have ballooned Surveys to include upstream & downstream dependencies, resources-over-time, operational impacts, critical time periods, key personnel and more.  By straying so far from the original intent to attempt to gather everything that might be useful, we’ve lost focus – and often end up with nothing verifiably useful.

What’s the alternative? 

First, you’ve got to establish quantifiable goals.  Keep it simple.  My own trials and errors – and observation of successful BCM organizations – have led me to believe there’s only one truly valuable goal of a BIA:  ranking the organization’s Business Processes in order of their criticality.  Everything else is fluff – or dependency mapping (more about that later).

Getting Started:

Where you start is as important as where your BIA ends.  Start at the top; what do your C-level executives believe are the organization’s most critical Products and Services?  You can conduct all the surveys you want, but if your results vary significantly from what the C-Suite believes, you’ll have little support.  You might be right – but you won’t be believed.

Armed with those beliefs, look for the Business Processes that directly support the delivery of those critical Products & Services.  Those are the organization’s biggest risks.  Approach those Business Processes with a clear understanding of what a BIA should be:

Business:  Stick to analyzing your business’ critical Products and Services and you won’t go off the rails.

Impacts:  Keep your focus narrowed to quantifiable impacts (Customer, Regulatory and Image/Brand).  You may think you can quantify Financial impact, but it is difficult – and the cause of most BIA Survey failures (a topic for a future article).

Analysis:  By limiting your analysis to those Impacts, you should gather enough data to enable you to create what a BIA was really intended to do:  rank your Business Processes in order of criticality.  A Business Process that doesn’t impact delivery of Products and Services shouldn’t end up with a high impact ranking (no matter how important they think they are).

With a solid starting point, a narrow objective and quantifiable goals, your BIA process will be both shorter and more reliable.  In Part 2, will look at how to collect data – and what to do about the other dependencies most failed BIA Surveys attempt to collect.

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

A Toolkit to Build Enterprise Resiliency

A Toolkit to Build Enterprise Resil...

A well-rounded Enterprise Resiliency Toolkit (𝗧𝗼𝗼𝗹𝗸𝗶𝘁) would provide key tools…
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…