SOUTHFIELD – Few will disagree that it?s a challenging time to manage an IT budget. Pressures are coming at you from all sides. In an expanding global marketplace, companies are forced to constantly reduce costs to remain competitive. At the same time, demands for IT security are exploding because of

viruses, spyware, regulations, log management, access controls, patch management, spam?and the complexity seems to increase daily.

The security manager is faced with a difficult challenge. Funding security initiatives are easy after you?ve been burned, but creating a compelling case to mitigate risks before they are realized is a much more difficult task.

The key to communicating the value of security IT investment is preparing a compelling executive view of the value of a company?s IT systems, and articulating the cost of risk to those systems. To tackle this challenge, we can borrow some ideas from the discipline of business continuity planning.

The first task in developing a business continuity plan is to conduct a risk assessment. Since the business of providing IT security is the business of mitigating certain types of risk, the connection to the risk assessment activity should be intuitive.

The first step to conducting a risk assessment is to perform a business impact analysis (BIA). The BIA will provide a foundation for your budget work, and will be the focus for most of our discussion here. Furthermore, those of you using ISO 17799 as a framework for your security program will recognize that the BIA is a core activity. So this effort will contribute well to that initiative.

Once you have the BIA in hand, you will have the proper business and financial context to convey the importance of mitigating risk with security investment. And don?t forget that if you have a business continuity planner on staff, much of this work may already be done for you.

Components of A Business Impact Analysis

To develop a BIA, you must first understand its components. The BIA is composed of a few key elements:

Critical Process (or Application) Inventory; Critical Components Inventory; and

Business Impact Assessment of Downtime for each Critical Process

It is important that each of these elements be developed to just the right level of detail. Too much detail and not only will the job never be finished, but the information will not help you reach your goal. Minimal detail, and your business cases will not be compelling, since you will be unable to sufficiently correlate the technology investment to the business.

So let?s examine each of these elements in further detail.

Critical Process Inventory

If you are going to ask for an infrastructure-related budget, it is essential that you place your request into a context which can be understood by the folks signing the checks. This context can be dramatically different from one company to the next. The success of your efforts depends on getting this right.

If you don?t know, ask! It is the rare (and incompetent) business person who would rebuff an inquiry from the IT management team as to which IT-enabled business processes are most important to them. When they tell you, use their language and their context. This one single item will buy you more credibility than any other, yet it is most often ignored. Often, you will find that Critical Processes are articulated in the form of application names. If that is the case, great! This simply makes your job easier down the road, as it will be simpler to correlate the Critical Components to that Critical Process.

Now, understand that, except in the smallest companies, you will need to meet with several key people to accomplish this task. As you perform this exercise, remember the following steps:

One: Explain your purpose: ?The purpose of meeting with you is for me to better understand those of the business services we (IT) are supporting that are most important to you. The reason I am doing this is so I can properly prioritize our investments toward protecting the availability of those services.?

Two: Provide an upper limit to the number of services they can put on your list, as appropriate for your company. This accomplishes two goals ? 1) it will cause your key people to think about those services at a higher level and 2) it will cause them to provide you with only the services that are really the most important to the business.

Three: Ask them to prioritize the list and ask them for a few words as to why they selected that priority.

Four: As you close, again tell them why this exercise is important, and ask for their support as you seek additional information for the BIA. This is very important, as you will likely need information from them or their staff in the future.

Once you have conducted this initial inventory, it is time to pare your list down to a manageable size, consisting of only those most essential IT-enabled business processes, which have the most significant impact on the business. This is the purpose for getting the additional information in step No. 3 above.

When this task is complete, it is time to move on to the next step.

Critical Components Inventory

The Critical Components Inventory is that list of infrastructure items and IT services which are critical to the availability of each of the Critical Processes. The purpose of capturing a Critical Components Inventory is to understand the underlying Applications and Infrastructure elements which, if unavailable, cause a Critical Process to also become unavailable. This inventory creates the context for security investment which protects the Critical Components, thus helping to ensure the availability of the Critical Processes.

Again, this is an area where too much detail will bog down your efforts, while too little detail may fail to provide you with enough relationship between your desired investment and the Critical Processes. The right level of detail is one that can reasonably be understood by both the IT organization and the business users supplying the Critical Process Inventory. Often, components are described in broad terms, such as ?desktops at Michigan plant? or ?Wide area network between sites A and B? or ?Reporting Application.?

Identifying a Component of the Critical Processes isn?t necessarily what should interest you. What is important is whether this is a Critical Component. A Critical Component is defined as a component that, if unavailable, dramatically impedes or stops the proper functioning of a Critical Process. If you are identifying Components that are not critical, that is a good indicator that you may be capturing too much detail. Non-critical components should either be excluded from the inventory or captured as part of a higher level component (for example: Network rather than switch) which is Critical.

The most effective way to capture this inventory is in graphical format, which describes the business process flow and shows the supporting IT components. If there is a business analyst role in your IT organization, that person is a very useful source for this information. If you find a need to drill down to deeper levels, you can then use these diagrams to meet with your architects and administrators to enlist their help decomposing the diagram into additional detail. When using diagrams, be sure to use consistent names when describing Critical Components that are common to multiple Critical Processes.

The cumulative Critical Components supporting a Critical Process is referred to as a System. When this task is complete, you are ready to move on to the final step in the BIA.

Business Impact Assessment

In my experience, the process of developing a Business Impact Assessment is nearly as important as the result. This is your chance to get direct involvement from the bus