As security professionals kick-off 2025, one common challenge emerges: setting security goals that will have an impact. While the ultimate aim of every security team is to “make things secure” measuring success can feel like an uphill battle. Direct measurement of “secure” isn’t always easy and instead teams rely on proxy metrics like the number of vulnerabilities patched or log coverage. Not all metrics are equal and the wrong ones can do more harm than good. What gets measured, gets improved. Metrics that slow down development can create unnecessary bottlenecks and undermine buy-in. On the other hands, the right metrics can position security to be a competitive advantage.
In this post I will outline two dimensions I think about when working with teams to set security metrics and how that impacts our choice of goals. By understanding how metrics fit with the business security leaders can set goals that enable businesses to move faster while staying secure.
Does the goal drive business success?#
Often security teams are seen to slow work down because they’re the “church of no.” Big, heavy compliance programs take a lot of time and effort to implement. Patching vulnerabilities is time spent away from developing new code. While these are necessary activities, it’s hard to get buy-in because they slow things down. On the other hand, if a security team implements builder tools and does it in a way that delights developers this speeds up business. Running a solid cloud platform with flexible blueprints that decrease development time results in developers coming to security with more ideas.
Who is doing the work?#
It’s also important to consider who is responsible for doing the work. Building out threat detection capabilities is something the security team can do themselves. This means that security has total control over this. On the other hand fixing code vulnerabilities is out of security’s hands. It requires the engineering teams to develop, test and deploy code changes to complete. Setting goals and measures for other teams requires working across teams to achieve buy in. Security can enable teams to achieve these goals but the work itself is reliant on those other teams doing it.
When looking at who does the work it’s important that responsibilities are clear cut. Producing threat models is one such metric that I’ve seen without clear ownership. Often the security team will expect engineering teams to build them. They know the system after all! On the other hand engineers expect security teams to build them out. It’s a security thing after all! Having a clear idea of who is responsible avoids a situation where no-one is because everyone is.
Putting it together#
If we combine both these ideas - whether a measure helps or hinders and who is responsible - leaves us with four quadrants we can place goals into:
Security metrics for engineering#
Anything in quadrant A (external and hinders) won’t happen. If we expect our engineering teams to work on things that hinder their progress they will just avoid the work. We’ve all heard developers say “we’ll add security later” or know of unsuccessful patching processes that were reliant on other teams doing the work. After all, this is understandable, engineering teams are there to deliver working systems for the business. If we ask them to take away time from new features they will avoid working on it. Anything that falls into this quadrant we want to move into one of the other quadrants. For example, how can security take on patch management themselves? Rather than relying on teams to manually patch vulnerabilities how can we deploy tooling that will automatically apply patches.
We can also move metrics between segments by focussing on how it’s framed. Over the last year I have helped a couple of customers get started with building out a security champions program. The nebulous goal of a security champions program is almost always “improve security” but exactly how can be framed in a number of ways. Some teams frame it “every release must now have a threat model” placing it firmly in quadrant A. Creating threat models was seen as a task for security and slowed releases down.
Successful programs had top-level, often CEO, buy-in that security was a non-negotiable. The security champions focus now was to help the business release faster by enabling engineering teams to build their own threat models. This helped the business move faster because it was done earlier in the development process and it empowered development teams to not have to rely on security by building the model themselves. For these customers this placed the “threat models completed” metric firmly in quadrant B.
Quadrant B (external and helps) is a magic spot for metrics to live. Finding (or framing) goals in this quadrant means that they just happen. It’s not a fight with engineering teams to get things done and doesn’t rely on security being a bottleneck. If a goal is clearly aligned to helping the business then it’s not a fight to get people on board or to get it done.
Security metrics for security#
Both quadrant C and D set tasks for the security team. These are metrics that are internally focussed and are work that just needs to be done. Metrics in quadrant C (internal and hinders) are hard - after minimising these, teams are left with tasks that are necessary but don’t get a lot of love. Compliance programs often fall into this block. Compliance often lacks a direct link to business velocity but is required in some industries or to meet the needs of some customers. Justifying time spent here can be challenging. Anything in quadrant C needs to just be done. These tasks should still be watched closely and optimised to minimise the impact. Ultimately though they’re going to be things that need to be constantly justified to the business and if there isn’t a clear business case, cut.
Lastly this leaves us with quadrant D (internal and helps.) These are things that security owns and helps the business move faster. Do these right and the business will love you. Security taking on responsibility for build tools is the example I used before. Where I’ve seen build tools built by the security team that aid developer productivity, the security team is seen as central to the success of engineering. These are tasks that security teams want to take on, do well and then highlight key success stories.
Take action#
Metrics that are measured are where effort is focussed within an organisation. Setting the right metrics not only sets up a security team up for success but also positions how they are perceived by the business. By ensuring that you’re focussed on metrics that help the business as much as possible and avoiding security being a bottleneck helps transform a security team. As you set your metrics and goals for 2025, think how you can avoid being a “church of no” and instead choose metrics can help security be a competitive advantage for an organisation.
Cover photo by Yuan Chen on Unsplash.