Blog post

Presenting Security Metrics to the Board

By Pete Shoard | May 18, 2020 | 0 Comments

One of the key challenges organisations face when looking to commission security projects is the prospect of having to justify the large spend to the board. Its difficult to present complex security problems in business language that will resonate with business leaders. The question of “What metrics are useful to senior leaders” and “How are other organisations reporting about security to the board” come up pretty frequently.

There are some key questions that we should concentrate on to ensure success and continued growth in our security budgets:

  • What matters to the business?
  • How are things improving?
  • Where is the value?

Create a matrix between identified business risks and security outputs.

Most organisations have some form of risk register, this is written in a language senior leaders understand. Alignment to identified and agreed issues that could have an effect on the continued operations of the business is an important way to communicate the impact of security operations. This should fundamentally be the first step in any security report to the board and typically focus on the major topics of concern, for instance; “protecting brand” or “maintaining availability of key trading systems”.

It is essential that as security professionals we understand that security is an enabler for business (not just something we have to have), it consumes some of the financial capital of the organisation, therefore it must provide justification (in business terms) for that expense.

Trend data is more valuable than point data

In my How Should We Measure Our SOC? post a couple of months back i said “PYRAMID METRICS ARE SO 90’S” and this holds fast, especially when we are looking to communicate with the board. The questions that often arise from non-security leaders are “5 incidents this week, is that good?” and “1.2Bn events, is that alot?”. These are perfectly valid questions, and if they are data points that mean nothing to who we are presenting them to, then why do we bother?

We need to start thinking about metrics such as:

  • Are we doing this faster than last time? and is it more efficient?
  • How do the number and category of incidents this month, compare with last month, and last year?
  • What are we doing that rarely yields results, where can we re-direct resource or technology?
  • Can we keep up? Do we have enough people, are we looking at the most important things?

Presenting flat, factual numerical figures is ok, most security technology produces this data for you. but step back and think, what does this mean to my senior leadership team? Are what we are doing making the business less risky, is my leadership forcing us to become more efficient and increase coverage with minimal increase in cost?

don’t beat yourself up, just because you didn’t find anything this week

After all, these are the questions business leaders want to ask of our security teams, of course this is alongside “Does that security thing i saw on the news last night, effect us?”

Include financial, risk and effort data in your reporting.

Its important that we also think about the impact of security issues and use this to contextualise what it is we are presenting. Don’t be tempted to simply talk about the security events that occurred without any context on the actual and potential impact to the organisation. Using data around the cost of downtime of key systems, the lost man-hours from staff and effort expended by security staff will all provide realism to a security incident. for example: show that the effort expended by security staff to limit and remediate a security incident is an order of magnitude lower than the impact on downtime and lost man hours

Be prepared to answer questions about what didn’t happen as well as what did.

Finally, don’t beat yourself up, just because you didn’t find anything this week. Prepare your reporting in a way that details coverage of issues, not just volume of work. Spending time talking about the issues that were monitored for and not seen is also valuable, not to use the stats to simply say “look how much work we did” but “we are confident that there were no issues of X type on these systems”. Simple reassurance can provide value to senior leaders that love to worry and stress about the ‘could be’.

In summary, its important for us as security operations professionals to collect data about whats happening, whats performing and whats not, but simply regurgitating this up the chain is not valuable. Think about the story you can tell with the data you have collected.

Leave a Comment