Every year, I need to do a report to Executive Management on the state of the ISMS as part of the ISO 27001 requirement for Management Review (Clause 9.3).
The first year I did it, I thought I did a decent job of the first draft. It had lots of metrics and raised a lot of issues. It looked "polished."
But then my boss reviewed my draft with me...and as we went through each piece of information in the report, he kept pointing to something on the page and asked "So what?"
For most of them, I was a bit stumped and mumbled an incoherent answer. Usually something like "Eerrmmm….because ISO 27001 requires it."
That question has stayed with me ever since. I now ask it on a daily basis as an Information Security Governance Manager, because it doesn't only apply to writing reports. It applies to everything we do and every decision we take.
The InfoSec industry has a busyness problem.
We love metrics. We love dashboards. We love a risk register with 200 items on it because it feels like rigour. There's a comfort in all of it. It looks like work. It feels like control.
But a lot of it is just noise dressed up as governance.
The reality is that we have limited resources. Only so much budget, so much time, so much personnel. We cannot afford to waste any of it on things that do not matter. And beyond the wasted effort, there's something else at stake: the trust our stakeholders have in us as trusted advisors. That trust erodes quietly, one irrelevant report at a time.
So how does asking "so what" fix that?
Think about your metrics. How many do you track? Do they all have a purpose, and what value or insight do they actually deliver to the people who receive them?
When you define a metric, you should be able to answer: "So what... why is this metric important, and what insight is it giving management?" If you can't answer that question for a metric, stop tracking it. You're not losing rigour. You're gaining focus.
Think about your risk register. How many of those risks are truly relevant to your organisation? Do they all need to be mitigated?
For each risk, you should be able to answer: "So what... why is this risk important enough to spend time, money and energy on?" If you can't answer that honestly, is it really a risk worth losing sleep over?
Think about your vulnerability management report. How many of those vulnerabilities can actually be exploited in your environment, against your assets, by a realistic threat actor?
For each one, you should be able to answer: "So what... is this vulnerability actually relevant to our organisation, and could it realistically be exploited?" If you can't, is it really something that needs to jump the queue?
And think about the last report you spent hours preparing for management. Do they actually read it? What do they do with the information inside it?
Before you write it, you should be able to answer: "So what... what is management supposed to get out of this, and what decisions should they take based on it?" If you can't answer that before you start writing, the report will have little impact.
The question isn't cynical. It's clarifying.
It forces you to connect what you're doing to why it matters, which is the only way to make good decisions when you're working with limited time, limited budget, and a team that's already stretched.
So here's the question worth taking into work with you tomorrow: look at the last thing you produced, the last report, the last metric, the last risk you remediated. Ask yourself honestly: so what? Who needed that? What changed because of it?
If the answer comes easily, great. You're spending your time in the right place.
If it doesn't, that's worth sitting with.