In this episode of ByteWise, the team welcomes back Mark Carroll, founder of the Enterprise Risk Management master's program at Boston University, to tackle the controversial Business Impact Analysis (BIA). They explore why BIAs are non-negotiable for regulated industries, how to demonstrate their value in other sectors, and what separates a "check-the-box" BIA from a truly effective one. Mark shares real-world examples and practical strategies for navigating disagreements, managing stakeholder expectations, and aligning business needs with IT capabilities to build a resilient organization.

Guest

Mark Carroll: Founder of the Enterprise Risk Management master's program at Boston University. With a rich background in IT, risk management, and business continuity, Mark brings decades of practical experience to the discussion.

Episode Highlights

Mark begins by defining the Business Impact Analysis (BIA) as a process of understanding business functions, assessing the impact of their loss, and analyzing what is required to restore them. He quickly distinguishes between organizations where a BIA is a choice versus a requirement. For regulated industries like banking or those with ISO requirements, the BIA is non-negotiable "table stakes" for legal operation. For others, it becomes a value-based decision, where the organization must be convinced of its worth as the cornerstone for any effective recovery activity.

The conversation then moves to what separates a good BIA from a poor one. Mark warns against the superficial "Survey Monkey" approach where everyone simply declares their systems critical. A truly effective BIA requires a deep dive to challenge assumptions and differentiate between what is merely important and what is truly mission-critical for survival. This analysis must reconcile discrepancies, such as a department requesting a four-hour recovery time while simultaneously holding a week's worth of inventory.

A significant portion of the discussion is dedicated to the human element of the BIA process. Navigating disagreements and gaining buy-in is crucial. Mark shares a practical strategy: begin the BIA with receptive departments to build momentum and create advocates for the process, leaving more resistant stakeholders for last. He illustrates the challenges with an anecdote about a finance department demanding unnecessary resources, highlighting how a fact-based approach and senior-level escalation are sometimes required to overcome myopic views.

Finally, the team explores the common disconnect between the recovery time objectives (RTOs) desired by the business and the actual recovery capabilities of the IT department and third-party vendors. A BIA forces this critical conversation, pushing for alignment through solutions like increasing inventory, dedicating more IT resources to specific functions, or developing manual workarounds. The reality of vendor contracts often dictates the true RTO, forcing the business to either pay more for faster service or accept the contractual risk.

The key takeaway from the discussion is that a well-executed BIA is essential for making the tough but necessary distinction between what's important and what's critical. As Mark aptly puts it, when a crisis hits, his job isn't to perform his day-to-day risk functions; it's to "carry water" for the people executing the recovery of truly critical operations.