If Not BIA Survey, What? (Part 2)

Part 1 of this article suggested that today’s BIA Survey is overused, over-stuffed, over-valued and usually overwhelming.  Instead, the article advocated a solid starting point, narrowed objectives and easily quantifiable goals.

The survey itself is a process fraught with problems.  An earlier blog dealt with many of those problems (subjectivity, poor wording, wrong respondents, etc.).  Because Surveys are problematic, they must always be followed up with clarifying interviews.

Why not skip the Survey and simply start with the interviews?  What if you have 300 business processes to interview?  If you took that article’s advice, you would have whittled those down to the 20 most important business processes – a much more palatable number.  You may need the other 280 eventually; but start with the processes having the greatest impact on your organization’s critical products and services.

Ask Subjective Questions

  • Don’t ask if the Customer will be impacted – ask how (and who)
  • Don’t ask if Regulations will be violated – ask which one(s) – and why.
  • Don’t ask if the organization’s brand/image will be tarnished – ask why and how

Set measurements

  • Will the Customer be frustrated?  Switch to a competitor? Suffer irreparable harm?
  • Will there be a financial penalty?  A reprimand? An audit ‘write-up’?
  • Will there be complaints?  Will there be Social Media fuss?  Will it make the Wall Street Journal?

Define Dependencies

BIA Surveys try often try to collect dependencies.  Do that in your interview – but do it methodically.  Ask only about upstream dependencies (who, or what, is the process dependent upon?).  if you collect downstream dependencies, acknowledge that they are often incorrect.  Leave them out of your initial analyses.

  • Ask them to choose from predetermined lists of upstream dependents.  Free-form answers will yield data – but not useable information.  (You can always add to your list as you progress, if you’ve forgotten anything).
  • Limit the number of dependencies to tangibles (locations, vendors, IT applications, other business processes).

Get Clarification

Don’t settle for data – ask for facts.  If you don’t understand the answer, ask for an explanation.  You can only compare business process impact with information you understand.  You want facts – and those facts should be clearly understood.

Don’t Waste Time on Financial Impacts

Most business process ‘owners’ don’t know how much their process could lose – of even if they’d lose income during a disruption.  How much they lose is largely irrelevant.  Lost income is a lovely metric – but it’s very hard to verify.  Collect Financial Impact data if you must – but don’t rely on it.  Really large numbers may be useful in your analyses – but only if they can be verified by another source (like the CFO).

Don’t rely on a Survey

You may consider yourself a BIA Survey expert.  But you aren’t.  Unless you plan to hire someone with experience in polling, what you are likely to get is inaccurate and misleading results.  If you have a mandate to complete BIA’s for every business process every year, you may have no other choice.  Make the Surveys as simple as possible.  But always focus your real efforts on the top business processes that impact your organization’s critical products and services.  Interview those process ‘owners’ and make sure what you gather is facts – clear, supportable and relevant.  Then you’ll be able to justify your time – and your results.

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…