ROI Is Not A Good Justification For Security

It's no secret that the business office uses financial models to approve and disapprove purchases. Getting proposals approved on business merit is often misunderstood by many IT and security practitioners who see the need for a technology, but can't convince business folks. Return on investment, ROI, often is used to justify, in part, an IT purchase which results in the percentage return. Risk reduction is the primary goal.Any business investment will add a return, either positive or negative, to the bottom line. Obviously, you want products that will add to the bottom line. Some projects will have a negative return. If you are governed by PCI, you have to have a firewall to pass an audit. It's required. Your firewall investment will have a negative return. You must have a connection to the Internet. Your connection is a cost that will have a negative return. Those are examples of costs your company has to eat. But let's focus on projects that you expect to add to the bottom line.

The nature of the return in ROI is important. ROI often is used in the context where an investment is going to generate revenue which will add to the bottom line, such as launching a new product line or service. ROI also can justify purchases that result in savings. Justifying savings is often the easiest form of ROI because you can determine what your current spending for a function is today, and how, with a new process or product, a savings can be gained over time. Ed Moyle is right -- "Security ROI Is Not A Myth." But neither is ROI a sufficient reason to buy security products.

What is never talked about is where that savings comes from. Many examples of ROI use operational efficiency as a monetized end and the illustration is authentication management and single sign-on as a way to reduce help desk calls. The example usually goes like this: The help desk spends X number of dollars per user per year managing user accounts. Deploying a new authentication system costing Y number of dollars will result in a reduction of N number of calls, saving Z dollars per year. Thus, the hours saved can be applied to other projects. Sound familiar? Before you trot out something similar to your CFO, stop and think about the logical conclusion of operational efficiency.

Joe Hernick, a contributing InformationWeek editor and one-time IT manager for a Fortune 100 financial company, sums it up. "CFOs look at operational efficiencies as reduced head count -- either current head count can be cut, or planned and approved head count won't have to be acquired. Operational efficiency means doing more with less staff," he says. You probably don't want to reduce head count. You probably want to maintain or increase head count, but still get new projects approved.

You may be thinking that the saved staff hours can be applied equally to other projects. People aren't robots. You can't take someone who is knee-deep in user management and move them to a new project and expect them to be 100% operational. Let's say that you can show that you can save 2,000 hours per year with a new authentication system. That's almost a whole person for a year. If you put that person into a new role, they will have to take time to get training, learn the new system, and integrate in. In Hernick's experience, CFO's will usually discount transferred time claimed by operational efficiencies by 30% or more. You can save the head count as long as you can justify putting them into a new role.

I am not saying that you should continue inefficient operations if you have an opportunity to become more efficient. I am saying that ROI isn't the best way to sell security purchases. You have to address threats and risk reductions.

Of course, if you can get that shiny new authentication system approved because you can address security problems inherent with multiple authentication systems and thus reduce the risks associated with multiple authentication systems such as account proliferation, users writing down credentials, and so on, and you can integrate all your applications with it and you can get a policy change stating that any new purchases will have to be integrated with the authentication system, then you automatically achieve operational efficiency. Efficiency is a side effect, not a goal.