It’s Tuesday morning, and you’re scrambling to get your weekly business review slides updated before the meeting. Manually updating metrics, tweaking graphs, and making sure your wins get noticed—it’s a last-minute dash that feels all too familiar.

‍

Metrics are incredibly important. They help measure your organization’s current security posture and highlight whether you’re getting better or worse. Unfortunately, most security metrics are an afterthought, and it shows.

‍

Security Teams Expected to Do More With Less

‍

Security teams are constantly asked to do more with less. In that environment, non-critical tasks—like developing meaningful metrics—often fall by the wayside. Here are three other reasons metrics tend to get neglected:

‍

• Focus on Reactive Rather Than Proactive Metrics: Many teams track incidents (e.g., number of breaches, alerts), which are reactive. Shifting to proactive metrics (e.g., vulnerability remediation rates) requires a different mindset.
• Lack of Consistent Data: Security data often comes from multiple, fragmented sources, leading to inconsistent or incomplete datasets that make accurate measurement difficult.
• Difficulty Translating Technical Data for Business Use: Presenting security metrics in a way that resonates with business stakeholders can be challenging, especially when they don’t understand the technical details.

‍

Now the good news. There are simple tweaks you can make to develop valuable metrics that will help improve your security posture and make a real difference in your organization.

‍

Here’s how, step by step:

‍

Step 1: Metric Driven Security

‍

Metrics should never be an afterthought. Often, people build their security program first and then scramble to find metrics that show off how great the program is. This results in vanity metrics—numbers that look good in business review decks but don’t drive real change. If you aren’t using your metrics to run your business or program, they’re just for show.

‍

We can learn from a development concept called Test-Driven Development (TDD). In TDD, you write a test case for a requirement before you even start coding. The test fails at first, but then you write just enough code to make it pass. Once it does, you move on to the next requirement. What would this look like for security metrics?

‍

Before you build a program or start a project, define the outcomes you expect. What are the requirements, and how will you know when you’ve met them? Develop metrics that measure those outcomes. They might look terrible when you first start measuring, but that’s okay. Then, build your program to improve those metrics and make them “pass.”

‍

Not only does this ensure you’re building something that genuinely contributes to your goals, but it also shows your progress as you go.

‍

Step 2: Determine What to Measure

‍

So, what should you measure? True success as a security engineer is measured by how well you support your organization’s goals. Most organizations aren’t in the business of being secure—they’re in the business of selling products, providing services, or delivering value to customers.

‍

Start by talking to your stakeholders to find out what’s important to the business you’re protecting.

‍

• What negative impact would come from a breach?
• What do customers expect from us?
• What types of customers are currently inaccessible to us because of security gaps?
• What compliance obligations do we need to meet?
• Key question: what impact do we want to drive, and how will we know when we get there?

‍

Once you understand where the business is headed, determine how your program will support those goals. Ask yourself how your security efforts will help the business:

‍

• Grow
• Attract new customers
• Retain existing customers
• Reduce transaction costs and become more efficient
• Avoid non-compliance penalties

‍

With this information, you can align your metrics with what matters most to the business. You’ll never struggle to demonstrate your contributions, and you’ll ensure your program continues to support the health of the organization you serve.

‍

Step 3: Become a Storyteller

‍

At Disney, I learned the art of storytelling. At first, I resisted the idea that storytelling had a place in business metrics. But telling a compelling story with data doesn’t mean starting with “Once upon a time.” It means being deeply familiar with your data and understanding your audience. You need to find the stories hidden in the data and bring them to light. Here’s how to do it:

‍

1. Deep Dive - Know your data inside and out. The last thing you want is to be caught off guard by a question about your metrics that you can’t answer.
2. Outliers - Identify the outliers and understand why they exist. Why are certain tickets past their SLA? Why are some systems still out of date? Why does the same person keep failing phishing tests?
3. Trends - Determine whether things are getting better or worse. What would it take to maintain or improve the trend?
4. Insights - Look for insights that drive behavior change. For example, “90% of our critical SCA vulnerabilities could be fixed by updating 10 libraries.”

‍

Once you’ve got a handle on your data, share these insights in meetings and one-on-one conversations with stakeholders. The ability to unlock insights from data is a valuable skill, and sharing those insights helps your leadership understand where the business is going.

‍

Finally {

‍

Metrics aren’t just numbers—they’re a tool to drive your business forward. By defining clear outcomes, aligning with business goals, and telling compelling stories with your data, you can make your security program a critical part of your organization’s success.

‍

}

‍