Tech Insight: How To Build An IT Security Budget

[Nicholas Takacs is engineering manager at PenTeleData. His content is contributed through the auspices of the (ISC)2 Executive Writers Bureau.]

Part 1 of a two-part series

There is nothing more anxiety-inducing to an information security department than the preparation, presentation, and approval of its annual budget. This process can create unnecessary tension, stress, and other negative feelings between the security team and company executives, who may balk at allocating money to projects to protect against potential intrusion.

Even with the best statistical data, risk assessments, and real-world testimonials, it can be difficult for security pros to build a budget that conveys their needs in a way that top executives can relate to and understand. In Part 1 of this series, we are going to look at how to pull the numbers together. In Part 2, we'll discuss how to present them to management.

Like any other IT function, building a budget involves three core components: people, process, and technology. The first step in budget development is to select or develop a framework to guide the selection of new investments (or reinvestments). You can use another company's budget as your template -- tailoring it to your specific company needs -- or you can initiate an internal effort to build one from scratch.

A proper budget framework is much like a project management methodology. That is, it defines the steps/stages necessary to move from concept (the need for a budget) to production (a final, approved budget). The nice part about this framework is that it usually doesn't require a large approval process, and it can be kept mainly for your own departmental use.

After selecting a framework, your next step -- as with any IT project -- is requirements-gathering. The goal of this step is to determine what types of new or updated security controls -- whether processes, technologies, or educational programs -- that the company may need.

Soliciting requirements feedback from executives, midlevel management, and even rank-and-file workers can yield valuable information about operational risks that may otherwise be obscured as data moves up the management ladder. Requirements feedback may include strategic business challenges, regulatory or compliance risks, data or systems incidents, or any other external factor that drives a need for security spend. Most importantly, ask your CIO or other group executive for a budget target, which gives you the baseline target to achieve.

While some requirements feedback may not fit neatly into the budget framework, the information gained through this process may help give you the justification you need during the review and approval process. Even if you don't use all of the data in your final budget, don't discard it --keep track of it under separate cover (this is sometimes called a requirements "parking lot").

Once you have your list of requirements and concerns, the focus then turns toward the specific security needs of the organization. This should break up into three distinct categories: needs, wants, and nice-to-haves.

Needs are processes or technologies required to maintain or improve a critically deficient area in the organization's security posture, such as firewall updates, a new intrusion detection system, or certification training for security staff to maintain competencies.

Wants are processes or technologies that would provide a beneficial benefit, but are not mandated by control requirements within the organization, such as an SSL VPN upgrade from IPSec, a new security workflow system, or updated security awareness materials.

Nice-to-haves are processes and technologies that would enhance existing security controls or programs, but do not necessarily provide a major benefit. They may give a "feel good" sense of security or positive public relations for the department, such as security program trinkets or bleeding-edge technology research.

To determine how to categorize your requirements, consider how each of these items reduces organizational risk and impact, any alternatives that may exist at a lower cost, and the risk of simply not having them.

Once this categorization is complete, map each of your needs to the existing budget framework, followed by the wants, and then the nice-to-haves. Cost considerations should not be barriers during this initial mapping process, but you should develop a rough cost "order of magnitude" for each item.

Armed with a list of items, orders of magnitude, and a framework to organize it all, you should be ready to build your preliminary budget. List each of the categories, with estimated costs.

Don't forget to include the costs of personnel, implementation, and post-installation support when arriving at an estimated cost for each item. Depending on the specific organizational requirements, you may want to split the costs between capital expenditures, operational expenditures, and expenses. And because you are dealing with security issues, your budget should also address the risk of not doing a particular item.

Once you have arrived at a total cost, compare it with the baseline number you got from your group executive during requirements to refine your figures and develop an over/under target.

Congratulations! You now have a rough draft for an information security budget. If your budget total is higher than the baseline number that you received from your group executive, then begin a careful review of nice-to-haves, followed by wants, if necessary. Consider each item and lower-cost alternates, and eliminate items until you reach the target.

If your budget total is less than the figure that your group executive gave you, then consider additional items that you may have overlooked. While it might seem good to be under the baseline, it's better to hit the baseline on the initial proposal, leaving you some room to reduce your figures later in the approval process.

The preliminary budget deliverable that you give to management should include a few key sections. First, give a high-level overview describing the strategy and framework used. Then provide financial breakdowns that divide costs into capital expenditures, operating costs, expenses, etc., as required by your financial department. Finally, you may also need to include departmental breakdowns of any costs that will be charged back to specific business lines.

After you've completed these steps, your budget is now ready for the review and approval process. In Part 2 of this series, we'll look at methods for achieving executive buy-in and getting as many security dollars as possible.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.