Board reporting is a significant element of our jobs, and it’s got to be delivered in a meaningful way.
Board reporting validates your program and rationalizes your spend. If you don’t have the board’s ear, it will be tougher to get the resources you need. Your board reporting should help the board understand and be able to rationalize risk.
How frequently should you report? C-level technology executives have to be willing to fight for the cadence that makes sense for their industries.
If your business has monthly board meetings and the risk level is a significant portion of the company’s revenue or valuation, then it definitely makes sense to get in there and push for updates at every board meeting, even if it’s just a quick summary. You need to have that presence there, not only to maintain peace of mind for individual board members, but to ensure that you’re continuously communicating the risks to them.
What things should you report? I like to get feedback and buy-in from the board on the metrics that matter. In an early meeting with the board, establish consensus on what metrics you’re going to provide and what they mean. Then present your metrics with an accompanying analysis so they’re not just numbers.
Analysis will encourage board members to ask questions that can help them frame what should be done next. Include historical context that gives a benchmark for a particular metric, as well as your view of the present situation.
The point is to ensure the board is aware of steps management is taking to deal with whatever issue is at hand, and to reassure it that information is being tracked so any anomalies will be caught and dealt with quickly. Reporting should provide that level of confidence to the board.
And remember: no techno speak. The analysis should be written in plain English because you’re talking to people who aren’t technologists. If you must use technical nomenclature, then include a glossary in your report so terms are well defined. Visuals, too, are important.
What content should be covered? First of all, events at the edge. The metric we usually provide is the attack trend – how many times did someone try to attack within a given period, and did anything get through. You’ll also want to report where the attacks are coming from – is it domestic, or foreign, for instance — so the board is aware of where risks lie.
Your vulnerability management program should provide statistics the board should be aware of, such as the pace of remediated vulnerabilities in the infrastructure, how many vulnerabilities you dealt with, and how many are critical or outstanding.
There should also be stats around routine phishing exercises to test your employees. Employees who fail those exercises and don’t show up to training should appear in the board report to make members aware that there are people inside the organization who pose an undue risk but do not take that risk seriously because they don’t show up to training. In our organization, that conduct can be a fireable offense.
Another thing to report on is your business continuity program, and any tests that were performed. Did the testing meet RTOs, providing some level of confidence that the business would be able to continue to operate during adverse conditions?
It’s also important to provide data around the function of the department itself. How many security-related incidents did you have versus events? How severe were they? All organizations should have an incident management program to help everyone understand how those risks are handled. That reporting is proof of life for the security organization, the one area where you can give the board a lens on how risk is managed, and how much risk the organization incurs in any given month. That tends to be a very eye-opening thing for boards.
The last thing I would make sure to cover pertains to any risks that have been assessed from a technology standpoint. It’s extremely important to be able to assess third-party risk, even if it doesn’t live in your security organization. It’s an important facet of making the board aware that you are continuously assessing and accounting for technology-based vendors that might have access to your data and infrastructure, or with which you might share infrastructure.
The board is responsible for the company operating in a manner that protects and ensures profitability for shareholders, or in the case of private organizations, that ensures there are no governing control failures. So while it’s good to report metrics and KPIS and that sort of thing to management, it’s also essential to get the board involved.