Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


06:42 AM

Tech Insight: How To Build An IT Security Budget

For most security professionals, building a budget is unfamiliar territory. Here are a few tips to help you navigate

[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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
2/4/2013 | 4:15:54 PM
re: Tech Insight: How To Build An IT Security Budget
Where is the risk assessment? The most important part of this entire process is determining the risks to the organizations sensitive data and critical systems. You address this cornerstone step as "Soliciting requirements feedback from executives..."[survey/interview] and "consider how each of these items reduces organizational risk and impact...and the risk of simply not having them" [intuition-based, desktop risk assessment].-

This surface approach to security risk assessment is a major mis-step at the beginning of an important process and will lead to faulty conclusions. You have a good process after this step but with a light (inaccurate) security risk assessment this process devolves into a GIGO process.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "Well I dont run on MacOS, so I need to take extra precautions"
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-06-02
Integer overflow may occur if atom size is less than atom offset as there is improper validation of atom size in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables in APQ8009, APQ8053, APQ8096...
PUBLISHED: 2020-06-02
Firmware will hit assert in WLAN firmware If encrypted data length in FILS IE of reassoc response is more than 528 bytes in Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voi...
PUBLISHED: 2020-06-02
A race condition can occur when using the fastrpc memory mapping API. in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables in APQ8009, APQ8053, MSM8909W, MSM8917, MSM8953, QCS605, QM215, SA415M, SDM429, SDM429W, SDM439, S...
PUBLISHED: 2020-06-02
Possibility of double free of the drawobj that is added to the drawqueue array of the context during IOCTL commands as there is no refcount taken for this object in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, ...
PUBLISHED: 2020-06-02
Valid deauth/disassoc frames is dropped in case if RMF is enabled and some rouge peer keep on sending rogue deauth/disassoc frames due to improper enum values used to check the frame subtype in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT...