5 min read

Reporting Cybersecurity to the Board

Reporting Cybersecurity to the Board

Reporting cybersecurity to executives and the Board of Directors. Feared by many cybersecurity pros, but necessary to life as we know it.

 
Not many people who I talk to actually like presenting to the Board. It’s scary, they can have you fired. It is difficult to even know what to report because we as an industry haven’t really nailed that down yet. 
 
It is also difficult to communicate a very complex topic to a group of smart financial people who often can only devote about an hour per quarter to cybersecurity. These are smart, experienced people. But rarely are their experience and expertise in cybersecurity. It is most often business and finance.
 
We need to communicate cybersecurity to the board in a way that makes sense to business people, and gives them the tools they need to successfully oversee the organization’s cybersecurity function.
 
Board Reporting Requirements
When trying to determine what information the Board needs, we have to keep in mind the bottom line here is the Board is responsible for overseeing the entire cybersecurity program. The whole enchilada.
 
What we see in a lot of cases is the Board flipping through documentation and approving things they don’t have time to fully understand. This is a dangerous proposition for a financial institution. 
 
To give you an idea of what the Board is responsible for in the financial world of banks and credit unions, here are some requirements straight out of the FFIEC’s Cybersecurity Assessment Tool:
 
"Management provides a written report on the overall status of the information security program to the board.”
 
"The board approves management’s prioritization and resource allocation decisions based on the results of the cyber assessments.”
 
"The board ensures management takes appropriate actions to address changing cyber risks or significant cybersecurity issues.”
 
The Board is responsible for everything according to banking regulations, so they need informative and helpful reports.
 
Board Reporting Goals
First and foremost the members of the board need to be informed. They need to be fully aware of the cybersecurity program. But not necessarily the technical minutia unless they ask specifically for the nitty gritty details.
 
Ultimately it’s about giving them the details they need to make informed decisions. And I’m not talking about the number of spam emails blocked per month. That is easy to track and report, but doesn’t really help the Board make decisions about the security program. 
 
We need to provide the kinds of information that allow them to understand what is going on well enough to make sound security decisions for the organization, and successfully oversee the cybersecurity function.
 
The last part of our reporting goals is geared toward action. The action of making decisions. It is typically the Board who has to approve significant purchases and projects. So when we as security people go to them for approvals (aka making a decision about a course of action), we need to guide them along the decision path. 
 
As the people proposing a solution for approval, we will have already gone down the path and probably arrived at a conclusion. It is in our best interest to lay out the information in such a way that is easy to follow. But be careful not to steer the decision toward your preference.
 
With most Boards it is okay to state your recommended solution. As you folks know already, many Boards will ask for a recommendation. What I am recommending here is to certainly state your recommendation, but present the information as objectively as possible, in an unbiased way.
 
We always have to keep in mind these are busy people with a lot of data to digest during Board meetings. It is our responsibility to keep them informed.
 
Lead with Status Updates and Approvals
Aside from a title page and table of contents, right up front, executives need to know what has changed and what is expected of them when they finish reading the report. This will prime their thinking to pay attention to indicators that support, or don’t support, the actions they need to approve.
 
There are two main components to this section:
 
What has been completed: this is an outline of what has significantly changed with the security program since the last report. Don’t get hung up on the statistics for now. We’ll cover those and where they come from shortly.
 
The second component to this section is: what needs Board approval - based on the risk measures, compliance status, recent audits, etc etc. what are you requesting the Board approve, that will move the security program forward.
 
Security Program Overview
As we move beyond action items and approvals needed, the very tactical pieces of the report and Board meeting, we’re getting into providing updates on the various parts of the security program.
 
You can organize the program in several different ways. At Rivial, we focus on the security program elements outlined later in this article.
 
After the initial items, actions completed and approval requests, the report should cover important metrics that demonstrate to the Board the overall status of the security program.
 
Start with the highest level metrics, around the program itself and then dive into specifics of each element. This approach looks at the overall program and it’s maturity. 
 Blueprint Graph
We track multiple items in each area that makes up the maturity our security program in the chart above.
 
For example: 
  • For Program management: Look at metrics around security policies and issue tracking and report on that maturity rating
  • For Risk Management: The maturity of the risk assessment process and the results compared to the risk appetite statement
  • For Compliance Management: Look at the frequency of control testing
  • For Security Testing: Show the rate at which vulnerabilities are fixed and how those affect the risk assessment
  • For User Training: Training adjustments based on phishing failure rate
  • For Vendor Assessments: How comprehensive are the vendor security reviews
  • For incident Response: How often incident response plans are updated and tested 
 
These are just a few examples of the different security items we look at to produce the graph above and report on the high-level maturity of the security program. Next, we will dive into each area of the program and how to report on those in a little more detail for the board. 
 
Next, include Important measurements from each major element of your cybersecurity program, such as:
 
Risk Metrics
Key risk indicators and key performance indicators, residual information system risk–in Financial terms–compared to loss tolerance
 Risk Graphs
Compliance Metrics
How close you are to being at your desired compliance status with industry and regulatory requirements.
 Compliance Graph 2
Training Metrics
KnowBe4, use it, and include the results from the dashboard in your report to the Board of Directors.
 
The key result in reporting this to the Board is highlighting the importance of user awareness, and doing something about it if necessary. 
 
Testing Metrics
The testing you have performed on your network, systems, and applications, is a critical part of the security program. 
 
In your report, it may be useful to provide a reminder about the organization’s policy, such as the organization being committed to fixing all high findings. 
 Vulnerability Graph
Response Metrics
There are three main pieces of reporting Incident Response metrics, aside from the results of actual incidents of course. 
 
Is an updated plan in place and do people know about it? Has testing been done so we know the incident response plan works? How many times have we had to use the plan?
 
Vendor Cybersecurity Metrics
 
With all of the news about third-party service provider risk and regulatory focus on vendor management, we certainly can’t forget about the security of our vendors.
 
At the very least, as somebody who is reporting to the Board on cybersecurity, you need to review your key vendor’s security documentation. 
 
The results of the process can be turned into a simple chart and presented to the Board. If the organization is using high risk vendors, the Board needs to know that, so they can make a decision.
 
Conclusion
Happy reporting. Clients love our reports. 
 
Rivial Platform makes it easier. 
 

About Rivial

Rivial’s mission is to create long-lasting partnerships that extend beyond standard expectations. Working with financial institutions of all sizes, we build and improve cybersecurity programs that fuel innovation and growth by using our expertise, innovative methodologies, and advanced software.

Incident Response Playbook: Business Email Compromise (BEC)

Incident Response Playbook: Business Email Compromise (BEC)

Flying under the radar for years, BEC attacks have been slowly climbing the ranks as one of the most popular tactics amongst cybercriminals to...

Read More
NIST CSF 2.0: Breakdown and Key Updates for Financial Institutions

NIST CSF 2.0: Breakdown and Key Updates for Financial Institutions

Originally launched in 2014 and updated in 2018. NIST CSF 2.0 (released in February 2024) builds on ten years of cybersecurity progress. It expands...

Read More
Unlocking Budget With Quantitative Risk Assessments

Unlocking Budget With Quantitative Risk Assessments

Year after year, the responsibilities of security leaders seem to grow. They must develop and implement security policies, train their organization...

Read More