Business survival: How to perform a security business impact analysis

A business impact analysis can be a manual that helps your company weather disasters. Here are some pointers on how to put one together.

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.

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 [email protected]

This article originally appeared in the November 2006 edition of Information Security magazine.

Read more on IT risk management