Glutton for ROI Punishment

My previous posts No ROI? No Problem and Security ROI Revisited have been smash hits. The emphasis here is on "smash." At the risk for being branded a glutton for ROI punishment, I present one final scenario to convey my thoughts on this topic. I believe there may be some room for common ground. I am only concerned with the Truth as well as we humans can perceive it. With that, once more unto the breach.

It's 1992. Happy Corp. is a collaborative advertisement writing company. A team of writers develop advertisement scripts for TV. Writers exchange ideas and such via hard copy before finalizing their product. Using these methods the company creates an average of 100 advertisement scripts per month, selling them for $1,000 each or a total of $100,000 per month.

Happy's IT group proposes Project A. Project A will cost $10,000 to deploy and $1,000 per month to sustain. Project A will provide Happy with email accounts for all writers. As a result of implementing Project A, Happy now creates an average of 120 scripts per month. The extra income from these scripts results in recouping the deployment cost of Project A rapidly, and the additional 20 scripts per month is almost all profit (minus the new $1,000 per month charge for email).

Now it's 1993, and Happy Corp. faces a menace -- spam. Reviewing and deleting spam emails lowers Happy's productivity by wasting writer time. Instead of creating 120 scripts per month, Happy's writers can only produce 110 scripts per month.

Happy's security group proposes Project B. Project B will cost $10,000 to deploy and $1,000 per month to sustain. (Project B does not replace Project A.) Project B will filter Happy's email to eliminate spam. As a result of implementing Project B, Happy returns to creating an average of 120 scripts per month. Profits have increased but they do not return to the level enjoyed by the pre-spam days, due to the sustainment cost of Project B.

I would say Project A provides a true return on investment. I would say Project B avoids loss, specifically the productivity lost by wasting time deleting spam.

I could see how others could make an argument that Project B is a productivity booster, since it does return productivity to the levels seen in the pre-spam days. That is the common ground I hope to achieve with this explanation. I do not consider that a true productivity gain because the productivity is created by the email system Project A, but I can accept others see this differently.

I think this example addresses the single biggest problem I have seen in so-called "security ROI" proposals: the failure to tie the proposed security project to a revenue-generating business venture. In short, security for "security's sake" cannot be justified.

In my scenario I am specifically stating that the company is losing revenue of 10 scripts per month because of security concerns, i.e., spam. By spending money on spam filtering, that loss can be avoided. Assuming the overall cost of Project B is less than or equivalent to the revenue of those lost 10 scripts per month, implementing Project B makes financial sense.

What do you think?

Comments

Anonymous said…
Richard, you sure are a glutton...


I agree with you 100%. There is no ROI on Security.


I've read all of your related posts and all of the links in the comments, and the links in those blogs, and the comments from the Economics Professors.


But still the point remains the same. There is no ROI on Security.
However, I will say that perhaps the problem here is not a disagreement over if there is a return, but rather what a "return" is.

Is a return a return to productivity (as in your example tonight)? Then yes, I agree that there is a return.


Is a return a savings in costs associated with doing business? Then yes, I agree that there is a return.


Is a return a profit or some other exchange of monetary value in for what you put into security? No, no, no! Can’t happen.


Is a return some sort of other value perceived by management? Well, maybe.


I think I see a lot of consultants responding to these posts. Perhaps (and I could be wrong) they have not spent a lot of time in the corporate world. In the corporate world, the IT department is usually a cost center . Sometimes, they are considered a profit center, but they are making a profit from internal customers. Therefore, they are not generating wealth that did not already exist.


That being said, the security department is always, always, always a cost center. They enable business, they consult with the business units and perhaps recoup a little bit. They may “sell services” to business units. But again, like the IT department, they are taking money from one business unit and putting it into another. There is no net gain. If I am in business unit “A”, and I generate $10,000, but I have to pay the $2,000 for the security solutions, I generate $8,000. The $2,000 is an expense. But at the same time, the IT staff doesn’t generate $2,000!


There is no magic security solution that I can implement that will directly affect profits. I increase productivity. I enable business to generate profits. But without the people whose productivity I increase, without the widgets that I enable the business to sell, there are no profits. Therefore, I cannot generate wealth for the company.
Anonymous said…
I'm with ya all the way, Richard. The only way you can have security ROI is if you define "return" to mean "avoidance of loss" -- which I think a lot of people do. This gives real economists the heebie-jeebies, but gives security folks the comforting delusion that they're not just a cost center.
Unknown said…
The difference between a return and an avoidance seems to be the existence of an external threat or issue that reduces productivity? Email will increase efficiency but isn't avoiding anything; it's a great example of an IT project with a return. And any means to improve that efficiency is just a return.

But once you get someone or something external reducing your efficiency, that can be construed as security, or avoidance.

An interesting example!
Anonymous said…
Note to self: Pete's post>
Anonymous said…
There's probably a good corollary if we look to our physical security counterparts. I can't remember ever hearing physical security guys striving to justify projects with ROI. They say "we need to do project X to protect our people and our assets," and then articulate the risks and how their project will mitigate them. Maybe they don't fall into the ROI fallacy like we do since it's much easier to attach value to a human life than a piece of information...most senior managers wouldn't balk at a relatively expensive project if they knew it would save even one life or keep a building from being blown up. But an infosec project to keep 10,000 customer records from being lost? Well, we'd better see some ROI on that!!
Anonymous said…
"I think this example addresses the single biggest problem I have seen in so-called 'security ROI' proposals: the failure to tie the proposed security project to a revenue-generating business venture. In short, security for 'security's sake' cannot be justified."

Richard,

Excellent point; though we disagree about certain semantics, I completely agree with you on this. Security is a means, not an end. If security won’t increase profitability (in the long term), it’s not justified.

shrdlu,

I think the debate about whether security produces returns is something that educated people can disagree on. Certainly, it’s not true that all economists think the idea is silly. Specifically, Gordon stated plainly that he believes it’s correct to speak of security yielding returns (that’s not to say ROI – as opposed to IRR or NPV – is a good formula to use).

-Ryan Heffernan
Anonymous said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics