Alfonso Barreiro shares his tips for selling security initiatives to management -- as well as a few methods you should avoid.
It's hard to deny it: information security can be a very tough sell in some organizations. Despite an increase in awareness, in these tough economic times, security initiatives and budgets are among the first to suffer cutbacks or be cancelled altogether. A common excuse is that security projects lack a clear return on investment (ROI). The truth is that most of the time, as prospect theory explains it, when confronted with a choice between spending in a security project (a sure "loss") and a potential cybersecurity incident (a larger loss that may or may not occur), management would rather take the chance that an incident will not happen. This is especially true if they don't have a clear understanding of the threats and their potential impact.
Know your audience
One way to overcome this is to be clear when describing threats, risks, and their mitigations. Avoid overly technical language and when describing risks, try to relate them to the whole of the business and in a way that your audience can grasp their impact on the business operations and reputation.
Security compliance required by regulations is also a good way to sell the need for information security to management. However, it is important that compliance should not be transformed into the ultimate goal for security. The Titanic was compliant yet we know how that story ended. It's quite possible that compliant organizations will suffer security incidents and breaches. Compliance should be the starting line, as regulations are only intended to force organizations to have some security measures in place. Your security program should address not only regulatory compliance but security risks to the entire organization.
Bundle security with other projects
A very good approach is to bundle security with business requirements. When a new business project or initiative comes along, security features should be part of the deal. The same way a new car includes seatbelts, airbags and many other safety and security features, new projects should have properly budgeted security components. Also, a good time to include security features is when modifying existing products or services. These approaches could be dependent on the standing of IT with the business, as "shadow IT" projects could slip under the radar and be implemented without appropriate security requirements. This can be mitigated somewhat with a clear security policy that's part of the overall IT policy instead of just an add-on.
Fear-mongering can backfire
There is also the fear-mongering approach. Fear is a basic emotion that drives people to think and act in ways that might be against their usual, rational, selves. It's hard to argue against its effectiveness but personally, I don't like this approach. An organization in a constant state of fear can generate far too many false positive incidents as people become paranoid. This in turn can desensitize users to real threats because the "cry wolf" mentality can take hold.
Lastly, be aware of the "windfall" response. It can happen for any number of reasons, including a failed audit, a disastrous security incident, or the successful prevention of one. The result is an unexpected surge in the security budget, either for the entire program or specific parts of it (a DLP initiative for instance). Always be on top of where your security strategy stands, its strengths and weaknesses, so when the windfall comes, you are ready to take full advantage of it.