The Business Impact Analysis (or BIA) has proven itself to be one of the most venerable methods for defining organizational risk, and one upon which many business continuity professionals have established their enterprise continuity programs. While no two end products of a BIA look the same, their resemblance through execution and applied terminology is unmistakable. Terms like “Recovery Time Objective,” “Recovery Point Objective,” “Maximum Tolerable Downtime”, and “Minimum Operating Requirements” provide measure and perspective, while they collectively blaze the critical path to restore or, as is more often the case these days, sustain the appropriate level of business operations following an adverse event. Without question, the BIA (in some form) is a crucial component that will enable business continuity success.
While the chief benefactor of the BIA is the enterprise as a whole, the product of the analysis is often limited to certain facets of the organization. Some astute risk management professionals have seen fit to exploit the harvest of the BIA, but too often its value is relegated to supporting only the traditional facets of business continuity and disaster recovery planning. For those not familiar with a well-executed BIA, it is essentially a dissection and examination of all components of an enterprise that sustain it (i.e., give it life). It is certainly not polite to liken a business to a frog in biology class. However, such an analogy has some merit for this perspective. Imagine making a symmetrical cut that bilaterally exposes the innards of the frog from under its mouth down to the groin.
I’ll pause briefly in the event that you have passed out… or if you’re taking the time to report me to PETA (I should offer the disclaimer that no animals were actually injured in the writing of this blog). So with the frog exposed in such manner, it’s rather easy to conclude why you chose risk management over veterinary medicine. Yuck! Let’s tune it back to business.
The appropriate analogy to draw from this is that the BIA exposes the systemic and symbiotic processes that give life support to the business. By breaking down the following (which represents only a sample of collected data), it becomes apparent that the BIA has a purpose that extends far beyond the foundation of a business continuity plan:
- What the organization does (e.g., key business processes)
- How the organization does it (e.g., supporting procedures, applications, infrastructure and data),
- When, and for whom, doing it really matters (e.g., time-based dependencies, critical stakeholders)
- How bad it hurts when they can’t do it, or trust in what they do is damaged (e.g., downtime impacts, privacy or breach impacts, other adverse events)
Imagine if, in the course of collecting this data, one could stretch the process (and it would not be a big stretch at that) to additionally analyze the following:
- The level of classification for supporting datasets (e.g., confidential/private, internal, public)
- The likelihood of threats to processes, systems, etc. which may propagate the occurrence of adverse events (e.g., Threat and Risk Management, Disaster Avoidance, etc.)
- Regulatory concerns with data management (e.g., data flows that illustrate pass-through in addition to intended, and possibly inappropriate, sensitive data handling).
- The impact change has on the operational or technical environments
Executing a BIA is not a light weight effort. It generally requires vast business and technical representation and participation. As one might expect with any enterprise effort, the level of quality in the end product is predicated on the level of executive support it receives. However, the data that is collected in the process is a virtual gold mine that can serve other purposes such as: Information Security Threats and Risk Analysis; Data Classification and Labeling; Data Flow and Dependency Analysis; Configuration Management and Change Impact Analysis. It should be noted that there are proven methods to expedite the BIA process, in order to quickly grasp the critical path to sustain business viability. The merits of expediting the process are almost exclusively for the benefit of establishing and maintaining a business continuity planning program, however, in my opinion. There is certainly nothing wrong with that approach, but it does tend to limit may be gained from the full traditional effort.
Having executed dozens of BIAs over 14 years as a practitioner, I would submit that the full effort has the potential to reduce the number of similar assessments conducted across the enterprise. In fact, consolidating such analyses actually provides for not only reduced collective effort, but it can also foster greater collaboration among normally disparate risk management functions. In my experience, business personnel are not always keen to make time for analyses that they perceive to be redundant, or at least eerily similar in terms of discussion and inquiry. I would say that most IT personnel are even less inclined to participate in the first place (sorry…but if it aint’ ones and zeros, to them it just ain’t sexy), but they will certainly be reluctant to participate in something they perceive to be a redundant exercise. It becomes, then, important for risk management functions, even if by committee of risk-relevant organizations such as Enterprise Risk Management, Information Security, Internal Audit, Business Risk Management, and, of course, Business Continuity Management, to streamline the data collection techniques. So to the naysayers who may claim that such a consolidated effort is tantamount to boiling the ocean, I would say that those claims do not necessarily hold water (pun intended).
And for my new-found scientist fans, the temperature for boiling the ocean is acutely based on the density solution of its salinization, which in turn requires a proportional increase in heat source and temperature that…oh to heck with it, I’ll stick with risk management.
Ron Pelletier is a partner with Pondurance, and he has been a Certified Business Continuity Professional (CBCP) since August of 2000, but a BCP practitioner since 1997. He is also is a CISSP, CISM, CISA, CEH, and CCFE.
