It is very important to properly define the right Information Security Metrics for an organization to estimate the security structure and to communicate it efficiently to the Board level executives.There is a growing interest from the Board and the CEO to understand the information security posture of the company. Many of the CISOs I know have been asked by the Board or the CEO to present. I also notice a huge disconnect between the security professionals in terms of what they think the Board want and the reality. From my experience of being a security professional as well as being a Board member (I need to manage my investors), I am attempting to structure my experience.
( Read more: Free Resources For Kickstarting Your IT-GRC Program )
Key Considerations while presenting to the Board
- Less is more. Board doesn't want the technical details.
We might want to fill up the presentation with a lot of information security metrics and data but the board wants the most critical ones which they can understand and relate to. E.g. They might not be interested in knowing about patching status or the number of incidents that you handled.
- Board speaks a different language
Understanding the language of the board is very important. Use technical jargon as sparingly as possible. Change your language and examples to something that the non security audience can easily relate to. One way to handle this is to link your information security metrics to the most important business critical systems
For Example: Instead of providing only information security metrics link the story to what matters to the board. If collection of revenue is central to your sustainability then the "Billing system" gets attention.
- Board is worried about how good the security is....minus the technicalities
That's a hard problem to answer. Security cannot be measured on absolute terms. However you got to explain it in simple way. Define your information security metrics to demonstrate your organization's security. You also need to assure how ready you are in terms of handling any critical incident
- Be cautious: Verify your assumptions
A lot of times we assume that the board might be interested in certain things, this may not be true for critical information security metrics. Most of the time people guess it wrong. It is a good idea to assume but definitely verify and take feedback
( Read more: 10 questions to ask before you start your Bug Bounty program… )
List of To-Do before the Board Meeting
- Understand what the Board wants helps you define required information security metrics
- Understand the level of understanding of each individual in the board
- Align your security strategy & information security metrics to the Business Goals
- Use Real Life examples and stories which is contextually similar to your business
- Represent numbers or other complex stuff graphically which gives an idea of trend
- Be prepared with the synopsis of the key security projects running and the most vital ones needing approval
- Be prepared with security strategy in simple numbers eg. If scenario 1 happens, Loss=$5million
- References to stats and competing organizations is helpful
Recommended Board Level Information Security Metrics / Dashboard (Less is more)
- State of Security in comparison with competition
The management is generally uses competitive matrix in business planning exercise. Providing them a clear picture of how your security is in comparison to the peers would be the language which the board/CEO is more comfortable with.
- Open business critical risks
Letting the management know which are the critical risks which could directly impact the business is extremely critical not just for them but also for you. A word of caution: This should not be the long list of technical details but high level understanding of only those things which are business critical.
- No. of critical incidents reported to media/regulatory agency
Please do not deluge the CEO/Board with all the incidents that you have detected. This could create a first time impact but for the long run what matters is the incident that had to be reported to the regulatory agency or the media. This number should ideally be zero.
( Read More: Using 80/20 Rule In Application Security Management )
- Loss/Downtime due security incidents
How much did the business lose due to security incidents? Was there any downtime? These are the business metrics that the Board/CEO really cares about.
- Compliance status
If compliance is critical for your business then it is important to report the status. Are there any critical risks or exposures due to non compliance? If so to what extent?
- Budget
It is important to provide a high level idea of the money you spent, what did you deliver and how much more money you need and why? It should be simple in non technical language.
- Key security initiative performance status
There could be some key security initiatives that you might want the management to know. It should not be all the projects you are running but the biggest and the most important ones that the business cares about. You should report the status like - if you are on time and budget? any key risks ?etc.
More: Are you a CISO Platform Member? Apply here (it's free)
Comments
Hello Upendra,
Thanks a lot for your valuable insights. Look forward to more of your insights at cisoplatform.
Few of the following could find a respectable place in the above said Metrics
How many security incident with critical severity reported in last quarter?
How many incident exceed the predefined response time (MTTR)?
No of successful exploit in last quarter.
What are the measure security control gaps?
No of person trained on security incident/response process.