In IT, the idea of anything shutting down business—even for a
day—is terrifying. Downtime costs money, and there are areas of the
business that must stay running despite a disaster, natural or
man-made. Nevertheless, trying to ensure near-total uptime for
every machine and process would bankrupt most companies long before
an outage would.
The challenge for IT managers is prioritisation: determining
which areas of the business must stay operational and which can
afford to be down. We know that the company will lose money if
revenue-generating areas can't function, but how much money? We
know that without access to tools and resources, marketing and
human resources are less productive, but how much less
productive?
Knowing which areas of the business need to get up and running
first after a system goes down can mean the difference between
survival and extinction. That's where a business impact analysis
(BIA) comes in. Like a survival guide for your business, it lays
out which areas are most critical—either because they directly
generate revenue or the company depends on them for successful
day-to-day operation.
A BIA can also help drive other security functions, such as
vulnerability assessment, risk management and incident response.
Strategic planning and handling will make your BIA an effective
guide to ensure your company stays alive.
BIA Basics
Business impact analysis is used within business continuity
planning (BCP) to refer to a systematic process of measuring,
analysing and documenting how various business functions are
affected by outages—both as individual processes and for the
company as a whole.
The goal of the BIA is to allow a business to understand how its
various revenue-generating and support organisations operate and
interact. Firms can then develop a more accurate picture of which
areas of the business will be hit hardest by disruptions and how
failures in one area of the business could cause other parts to
fail.
At the end of a BIA project, organisations should understand
which processes are most critical to keeping the firm running. This
allows them to prioritise investments in preparedness, orchestrate
continuity activities and implement contingency measures for the
most critical systems to reduce the impact of a disruption.
The key to getting maximum value from a BIA is to encourage wide
distribution, high visibility and flexibility in a way that makes
the guide easy to use and maintain.
Content collection
While there are many methodologies available for performing an
impact analysis and numerous conventions for structuring the final
document, effective BIAs have more to do with content than
format.
At a minimum, the BIA should contain a comprehensive catalog of
business and support functions within the organisation; some
description of those functions, lists of critical systems and other
resources involved in maintaining them; and a spider web of
dependency/support relationships between the surveyed business
functions.
Getting this minimal data can be a serious chore. Typically,
most BIA endeavors begin by asking managers directly for specific
details about the areas of the business for which they are
responsible. Many BIA initiatives will start by sending
questionnaires to sales managers, marketing executives and business
unit directors that ask for information related to the function,
operation and dependencies of the processes they oversee. These
questionnaires are less intrusive to the business than gathering
the information via an interview, so they're used more often.
Responses from the key managers can be used to map out
dependency relationships and locate "hidden" processes, such as
low-visibility functions or those performed outside the firm by a
vendor or trusted partner. Examples are outsourced support-desk
help or vendor-provided maintenance. These functions might be
critical to business operation, but given their vendor-supplied
nature, they may not be apparent in budgets or have dedicated
personnel. These previously untracked activities can be added to a
master inventory and their managers invited to participate in the
BIA process; their input may yield even more areas to examine.
At the end of the exercise, the business is left with a
comprehensive catalog of all functions and a precise road map of
how they interact. The remaining task is to document those
relationships and ensure updates are made as processes change.
In addition to documenting how business processes interact, it's
important to collect financial information about them. Access to
finances allows you to predict potential lost revenue, productivity
costs and opportunity costs related to downtime in individual
business units. Business managers will likely have basic profit and
loss information for systems, but since you ultimately want to shed
light on total downtime costs, you'll need to gather additional
data.
To create this more detailed financial profile, enlist other
areas of the firm to help. For example, the compliance department
can provide insight into the fines or penalties that may be
incurred if a particular process suffers downtime, while the legal
department can help you understand what potential contractually
de-fined fees you might owe if you are unable to provide service to
clients for an extended period of time.
This financial picture can then be tied to the dependency
information collected so that you can see, in dollars, the impact
of one or more processes being unavailable.
Integration
An effective BIA is a living document; creating yet another
document to gather dust on a shelf obviously isn't useful.
Integrating the BIA into other areas outside BCP ensures that the
document will continue to be relevant.
In other words, once an organisation has invested the time and
resources required to gather, correlate and document its business
processes, that investment can be maximised by using the BIA in as
many other areas of the firm as possible. Additionally, using the
BIA for other activities outside BCP will keep it current. After
all, the business processes documented in the BIA are continuously
evolving—updating the document as they evolve is critical.
A good place to make broad use of the document is in the
"non-disaster planning" information security world. Vulnerability
assessment, application assessment, risk management and incident
response can all benefit from having a BIA.
For security organisations that perform automated vulnerability
assessment, the information in the BIA can increase an assessment's
effectiveness by taking into account a machine's criticality.
During assessment planning, organisations can decide whether to
include critical servers in their scans to help harden those
machines or to preclude scans of those servers to minimise
potential downtime. Alternatively, organisations may want to use a
blended approach with less intrusive scan settings against critical
servers than they would against non-critical ones.
A BIA can also assist in application assessment by allowing
assessors to use them as a means of gathering intelligence.
Specifically, the BIA can provide dependency information to help
companies understand how these applications interact, how they
relate to the business, and how data flows into and out of the
application.
Data gathered during application and vulnerability assessments
can drive changes to the BIA. Assessments may highlight application
changes, and those changes can reflect updates to the underlying
business process. Personnel evaluating applications can
periodically "freshen" the BIA by aligning it with those
changes.
Risk management is another area outside continuity planning
where the BIA can help. Often, information security teams that try
to quantify overall risk either cannot assign dollar amounts to
risk or are forced to use soft dollar values derived from rough
estimates. However, by drawing on a BIA that contains hard dollar
values, you can replace estimated costs with actual costs to
enhance the precision and credibility of risk management activities
and provide more effective communication of risks to business
partners.
Some risk management activities are also limited by the domino
effect caused by compromised systems cascading risk to dependent
systems. Having those interactions documented in a BIA can provide
insight into this phenomenon and allow risk management activities
to include these risks in the overall risk profile for a given
application.
BIA content can also help incident response. If the BIA includes
operational information about critical applications—such as
application owners' contact information and addresses/platforms of
critical servers—response personnel can take proactive steps in the
event of an incident to ensure that these critical applications
stay up. For example, if a worm is spreading through the network,
personnel can contact the managers of the highest priority systems
early on to relay protection measures—hopefully before those
critical machines become infected.
Critical factors
There are a few simple steps that can mean the difference between
the success and failure of a BIA: ensuring open communication and
buy-in, establishing a high-level tracking framework and assigning
accountability.
From the earliest planning stages until after the document is
created, it is important to have open lines of communication with
key organisational players. Obtaining appropriate buy-in from upper
management and the business community early in the lifecycle is
also a must. Managers of critical business functions have a lot on
their plate, but fully communicating the purpose and value of the
BIA can ensure their cooperation in making the data they supply
complete and accurate. After all, the BIA is ultimately a document
that helps them—it is their processes you are trying to
protect.
Keeping the lines of communication open after the data is
gathered is also important to make sure the document reflects
changes in business processes and remains relevant. Additionally,
maintaining a dialogue with internal auditors, compliance managers
and the rest of the information security organisation can guarantee
the document has a broader scope outside of contingency
planning.
A high-level framework for project management over time is an
essential part of building a proper foundation for your BIA. Even
smaller organisations will have numerous interdependent business
processes that will need to be accounted for—probably too many to
track without careful organisation. Intelligence-gathering for the
BIA will uncover many other processes, and new business functions
are likely to be put in place during the engagement.
Setting up a mechanism for tracking these processes as they are
discovered and created will ensure that nothing slips through the
cracks. The project will likely have high visibility, and using a
metrics-driven approach stream- lines status reporting and allows
rapid schedule modifications if dates slip.
Assigning accountability for BIA tasks is also an important
step. BIAs can contain quite a bit of data, but harvesting that
information is extremely time-consuming. Allocating and tracking
individual tasks ensures that the data gets collected and the
project stays on schedule.
If created and used strategically, a BIA can be one of the best
investments your firm can make—both for contingency planning and
for information security as a whole. Once the document is in place,
taking steps to keep its contents current ensures that the BIA is
useful as a survival guide for years to come.
About the author: Ed Moyle is a manager for CTG, an
information security services and consulting firm. Please send your
thoughts on this article to feedback@infosecuritymag.com.
This article originally appeared in the November 2006 edition
of
Information Security magazine.