Making Security Metrics That Matter

Making security matter to the business

What are the strategic goals for your organization in 2012? Can you recite them off the top of your head? If you can’t, you’re not alone. The inability of enterprise security teams to answer those questions is one of the biggest obstacles facing our discipline today, and it’s the biggest reason current security metrics do not grab the attention of organization leaders.

Know Why You’re There: Business Productivity

The traditional role of security in the organization has been that of a cost-center to be minimized. Besides preventing breaches, security’s success has historically been defined by internally developed measures. We work to create best-practice metrics that show how mature the security program is, and we pass them around to one another as indications of our success. Unfortunately, those kinds of security metrics do not speak to the heart of the business.

IT has made the shift from support to delivering value. Security must follow.

In many organizations, both small and large, IT has successfully made the transition from its traditional role as a support service to driving business value. In manufacturing firms, IT has provided huge returns in implementing ERP (enterprise resource planning) and MRP (material requirements planning) systems. In marketing organizations, IT provides direct business value in improved marketing through analytics and improved CRM (customer relationship management) solutions. And in many software and solution companies, IT actually is the value the business offers, either through technical skills or solutions made by IT.

So far, security has not managed to make that same shift. We are still implementing security based on our own priorities and goals, rather than on what makes the larger organization successful. Whenever we talk about the success of our security program in terms of adherence to an industry standard, a best-practice or a framework, we’re defining our goals based on the requirements of a third party; a third party who does not have the specific interests of our organization in mind.

I am not suggesting we should abandon frameworks and build everything from scratch. In fact, I strongly believe that most security programs should be built to a framework. But it’s how we customize our specific implementation and how we view that framework that differentiates a business-enabling security program from a stifling one.

How Security Meets Those Objectives

A successful security program starts with the goals of the organization and flows from there. As an example, consider the differing needs of two organizations.

  1. A small software development shop with a couple dozen employees, selling consumer software to end users.
  2. A large manufacturing and retail organization that sells primarily to professionals and corporations.

Company 1 needs to create highly innovative software and get it into the hands of the consumers quickly, while trends are still hot. Company 2 needs a extensible program that can integrate with numerous vendors and partners without adding crushing overhead to the supply chain, and repeatable, provable procedures that can be demonstrated to customers and regulators. Can you imagine trying to implement the same type of security program for both of these companies? Unfortunately, that’s exactly what many security practitioners do. The key to success in both of these organizations is in understanding how the organization can be successful, and implementing security in a way that supports that success.

The objectives of the business should dictate the initiatives of the security team.

For Company 1, security must create efficient ways to rapidly enable the company to go to market, without suffering from devastating security breaches. For this security department, it may entail security initiatives like: (1) secure coding training for developers, (2) security consultation during the software architecture process, (3) automated code review as a part of the development process, and (4) vulnerability scanning and on-going penetration testing as a part of the QA cycle.

For Company 2, the organizational goals are to improve supply chain efficiencies, and reduce the overhead of achieving regulatory compliance. To provide support for these initiatives, security will (1) implement a federated sign-in solution to allow better collaboration between organizations, (2) create a tiering system for vendors, to maintain high security requirements for those vendors with access to sensitive information, but reducing the requirements on vendors without sensitive access, (3) ensure procedures and auditing exist for all processes that are required for compliance, and (4) ensure that disaster recovery plans are created and tested for all critical business functions, in compliance with applicable regulations.

Metrics That Make Sense… To The Business

After we’ve created these security initiatives that address our company’s goals, we need to measure it and show it off. Note the difference between the metrics used by Company 1 and Company 2, and how the security teams uniquely demonstrate and measure the value added to their business. First, we take the organization’s strategic goals. Under those goals, we list the security programs that we’ve implemented to support them. Next, we determine metrics that will explain how those initiatives help the business. The key here is that those metrics must be in words that make sense for the business, not for the InfoSec department.



Gone are metrics like “vulnerabilities found” and “patch level.” In their place are metrics that directly address the priorities of the business. By crafting the metrics in the language of our business leaders, we are demonstrating the value of their security investment in a way that matters to them.

Context is essential. Security measures must be written in the language of the business.

Context is key. Security exists within the context of the company that employs it. Understanding the objectives, motives and vernacular of the industry are critical. A software company may want to read about features released, time to market and improved quality. But a bank is interested in fraud cost reduction, regulatory compliance and accounts added. Knowing what makes your organization successful is essential in capturing the right metrics.

In order for security to have a seat at the table in overall business strategies, the business leaders must see that security is up to the task. They want to see that security is delivering tangible value to the overall organization. Mapping our initiatives back to strategic goals and reporting our results in the language of the business are the best ways to demonstrate that value.

Connect with


2 thoughts on “Making Security Metrics That Matter

  1. Andy,

    Thank you for taking the time to read and comment. As you said, there is a lot of room for us to improve our security alignment. Fortunately, it’s fun. I appreciate the kind words.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s