Babel Fish

Risk Register: The Only Way to Talk to the Board

Ever wondered how really effective cybersecurity professionals not only get direct access to the CEO / Board of Directors (BoD), but actually manage to get a budget out of them? Better even than that, they get the entire C-Suite to evangelise the organisation’s security program on their behalf!

It’s quite easy actually, they speak the same language as the CEO / BoD. This is not the language of security, it’s the language of business goals. Or to put it crassly, it’s the language of money.

For example, if you are a CSO / CISO and have reported to your Board how many malware attacks your controls blocked, or how well your firewall is working I’m surprised you still have a job. The vast majority of Board members care nothing for the detail, and frankly, nor should they. As much as I have preached about how the CEO /BoD should care about security, what I’m really saying is that they should at least appear to care.

The only ones who actually care about cybersecurity [for its own sake] are those with a vested interest. Practitioners, consultants, and especially product vendors, all say they are passionate about security. They may well be, but as an analogy, are you ever passionate about your car insurance? No, of course not, quite the opposite, you just know you have to have it.

Security is no different to insurance in this respect, it’s not like sales or marketing where there is an obvious correlation between the effort and result. With security, the effects are invariably seen only when things have gone horribly wrong. Even then, the Board don’t care about security itself, they care about how the failure of security affected the bottom line. Coincidently, this is often when they start asking all the wrong questions and throw money at the symptoms not the root cause. Like hiring a CISO for example.

Even as one of those with a direct vested interest in security, I am absolutely fine with this. I know my place, which is to provide a direct link from the individual IT assets to the business’s goals. If I can’t show how a risk to the assets at my level can affect an entire business at theirs, how can I possible expect them to understand what I’m talking about? And to be clear, it’s my job to perform this translation, not theirs.

The Babel Fish that performs this modern day miracle? The Risk Register.

I’d say about 75% of organisations I’ve helped over the years have no risk register at all, 20% have only a business risk register, and the remaining 5% have separate business and IT registers. Not one has a single register that maps the IT risks to the business goals. Not one. Worse is the fact that all of these risk registers were very poorly conceived and resulting in nothing but poor decision-making.

The single risk register I’m talking about is the one where anyone can view their part of it and determine exactly how their actions can affect the whole. Does this mythical creature even exist!?

So how DO you map assets to business goals?

Like everything else in security, it’s actually simple. Bloody difficult, but simple.

Step 1: Do Asset Management Properly – I can already exclude every organisation I worked with, and I’ve only heard rumours of this being done well. Basically, if you don’t know what you’ve got, you can’t manage it, let alone perform any step that follows;

Step 2: Map Your Assets to Your Business Processes – I am often amazed that asset dependencies are not fully mapped. How do you perform change control properly if you have no idea how you’re impacting the business process that the changing assets support? How can you prioritise assets? Dependencies, inter-dependencies and data flows must be fully defined;

Step 3: Perform a Business Impact Analysis on Every Business Processes – If you can’t even take a stab at valuing each of your business processes, how can you prioritise them? Whether you can directly quantify them (e.g. revenue) or only qualify them (e.g. HR) you have to know what they are worth to you;

Step 4: Map Your Business Processes to Your Business Goals – This can be tricky as you’re going from the 100% technical to the 100% business. But if you have no idea whether or not your goals are achievable with your current assets, they aren’t very good goals, are they?

In theory and for example, you now know that if a certain database is lost; a) the business process that will fail, b) the potential losses, and c) the goals that may now become unachievable. Not every goal obviously (e.g. M&A), but definitely the ones that got you this far.

So, when you next talk to the BoD, you can show them the possible impact of not spending money on database redundancy where it hurts the most

Their pockets.

[If you liked this article, please share! Want more like it, subscribe!]