NATIONAL HARBOR, Md. -- Be careful what you wish for. Now that security has the attention of business management...
and boards of directors, CIOs must learn how to translate an information security program into terms the business understands. The first rule of thumb? Focus on results, not details.
"Stop telling them about what is going on in security," said Gartner analyst Paul Proctor, on hand at Gartner Inc.'s Information Security Summit to offer a Rosetta stone for translation to the security profession.
Instead of telling management how many incidents the company experienced last year, security professionals should focus on how well they managed those incidents. "The issue is, how good is your program?" Proctor said.
Use key performance indicators and key risk indicators
Organizations tend to measure security risk by looking at things that could go wrong and assigning a dollar value to the damage. But that approach bypasses all the ways in which things can go wrong, Proctor said. A security professional can make a compelling business case for an information security program, he explained, by connecting the organization's key performance indicators (KPIs) to key risk indicators (KRIs).
KPIs -- e.g., customer retention index, time to market, supplier on-time delivery -- are used to measure the health of the business by providing insight into, for example, how well the supply chain is being managed or how well the sales force is doing.
How much money a business makes in a quarter is a lagging indicator of what went wrong. What businesses need, Proctor said, are leading indicators of risk. Security programs that map to KPIs will translate security requirements into language the business understands.
A slowing supply chain is a leading indicator that a company might not make its quarter. Poor patching, still a security problem after all these years, is a leading risk indicator that a supply chain could slow down and the business not make its numbers.
Five tips for linking security to corporate performance
1. Formalize a risk and security program.
2. Map KRIs to KPIs.
3. Don't use operational metrics in executive communications.
4. Link risk initiatives to corporate goals.
5. Communicate to executives what works and doesn't work.
Source: Gartner Inc.
"Show them here why what I do matters to what you care about," Proctor said.
KPIs vary for businesses. Proctor recommends that security teams create their own set of KPIs by identifying critical business processes and supporting applications. The KPIs should not be IT-centric, as that will reinforce the business mind-set that continues to bedevil security teams: namely, that security is an IT problem and therefore solved within IT.
Security, of course, will also have to create a set of key risk indicators (KRIs), backed up by the voluminous data an information security team collects.
The mapping task is to show how KRIs connect to and can change KPIs. Proctor recommends that security teams continually measure KRIs in the context of KPIs and report their findings to the business, even though the business has not asked for this analysis. In time, he predicts, the reports will become a standard feature of the organization's risk assessment.
Don't use ROI
Security professionals need to have operational metrics to help them do a better job, but Proctor said they should not be used in executive communications. "Don't waste your time," he advised. Instead, it behooves security to create "a layer of abstraction" when talking about security to the business.
That means not talking about a return on security investment, for example, because when the business hears ROI it thinks money out for money in, not peace of mind. Instead, use terms lifted straight out of the annual reports, like business value.
"Use their words because they wrote those words," he said.
Map security initiatives to corporate initiatives; lift specific wording and headings from the five-year strategic plan and graft them on to the security plan.
Paul ProctorAnalyst, Gartner Inc.
Another layer of abstraction is showing the business where security operations are today and where they need to be. Proctor recommends that security execs develop a process catalog that enumerates the dozen or so high-level processes that represent the information security program, then assess how well those processes operate. The scheme business sees should represent, in abstract fashion and maybe even bright, primary colors, the current state of those processes, the target state, the planned remediation and the time frame for improving those processes.
Communicate to executives what works and what doesn't work and offload the decision about whether to fund the gap on them.
Security executives should have the metrics for these operations in their back pockets -- but don't go to them unless asked, Proctor said.
More risk management resources for CIOs
Of course, all of the above presupposes having a formal risk program. When the call comes in on Thursday requesting the chief information security officer give the board of directors a 20-minute overview of the company's information security program and policies the following Monday, it helps to have one. The hallmarks of a formal risk and security program are accountability, transparency and measurability, Proctor said. The program should lay out who is responsible for what in security, provide visibility into core processes and a baseline for continuous improvement. The program should also include a formal governance structure, Proctor said, so it's clear how security decisions are made.
Let us know what you think about the story; email Linda Tucci, Senior News Writer.