In this video, we walk through 5 ISC practice questions on business impact analysis. These questions are from ISC content area 1 on the AICPA CPA exam blueprints: Information Systems and Data Management.
The best way to use this video is to pause each time we get to a new question in the video, and then make your own attempt at the question before watching us go through it.
Business Impact Analysis
A business impact analysis (BIA) is how an organization figures out which of its functions it can’t afford to lose and what a disruption to each one would cost. It is a foundational step in building a business continuity plan, because the plan needs to know what to recover first and how quickly. This post covers what a BIA does, how it begins, and the main concepts it produces along the way.
What a BIA Does
A BIA focuses on the consequences of a disruption, not its causes. It doesn’t try to predict whether a flood, power outage, or cyberattack will happen, or how often. Estimating likelihood belongs to a risk assessment. Instead, the BIA assumes disruptions can happen and asks what they would do to the business.
The process generally starts by defining the scope and gathering information about how the organization operates. From there, it identifies the critical functions, assesses the impact of disrupting each one, sets recovery targets, maps dependencies, and estimates the resources needed to recover. The findings go into a report with recommended recovery strategies, and the BIA is updated as the business changes. By the end, management should be able to answer a question like this: if order processing were down for two days, what would it cost, and how quickly does it need to come back?
Defining the Scope
As mentioned, the first step is deciding what the analysis covers. That could be a single department, a specific set of processes, or the entire organization. Scope keeps the work focused and points the analysis toward the areas that matter most.
Without a defined scope, the next step of gathering information through interviews, questionnaires, and document reviews has no boundaries. A team that starts interviewing every manager in every location before deciding what’s in the analysis will end up with more information than it can use and no clear direction.
Identifying Critical Functions
Not every function is critical. A function is critical when the organization can’t go without it for long, which usually means it’s tied to revenue, regulatory compliance, customer service, or core operations. Processing customer payments and making required tax deposits on time are typical examples.
Functions are ranked by both importance and time-sensitivity. A five-year strategic plan or an internal training library has real value, but either can be put on hold for weeks without serious harm, so neither would be treated as critical. The purpose of the ranking is to set priorities. If every function were labeled critical, the BIA couldn’t tell the organization where to focus its recovery efforts.
Recovery Time and Recovery Point
Each critical function gets two recovery targets. They are both stated in time, but they measure different things.
The Recovery Time Objective (RTO) is the deadline for getting a function working again. It is measured forward from the moment a disruption begins. A 4-hour RTO means the function has to be restored within 4 hours of each outage.
The Recovery Point Objective (RPO) is the maximum amount of data the organization can afford to lose. It is measured backward from the disruption to the last good copy of the data. Whether an RPO is met depends on how often data is copied. A company with a 2-hour RPO that backs up only once a night could lose nearly a full day of data in a late-day failure, which is far more than the target allows.
Mapping Dependencies
Critical functions depend on other things to operate. Some dependencies are internal, like systems and personnel. Others are external, like suppliers, service providers, and utilities. An online retailer’s order fulfillment, for example, might depend on its warehouse system, trained staff, an outside shipping carrier, and electricity.
Mapping these dependencies is what makes a recovery plan realistic. Consider a call center that restores its phone system well within its RTO, but whose agents still can’t help customers because the account database, hosted by an outside provider, is also down. Restoring one piece didn’t restore the function, because the function relied on something the plan hadn’t accounted for.
