top of page
  • Phil Venables

Cybersecurity and the Board : A Fresh Perspective?

How to represent cybersecurity (or technology / information risks more generally) to the Board is an ongoing subject of discussion in most industries for both public and private companies - as well as being quite a significant source of activity for large consulting firms. Similarly, how Boards and Board Directors should oversee this risk is a major topic of discussion in their circles. I’ve seen both sides of this in multiple organizations, multiple sectors, and at different scales across public and private companies.  

There is a reasonable amount of guidance out there, for example, the National Association of Corporate Directors and a lot of the consulting firms have solid material on this topic. But, the problem with some of this guidance is that it can focus excessively on how to talk about specific cybersecurity issues or metrics and how to educate the Board about the topic itself. I think there is insufficient focus on the mechanics of governance, the leadership dynamics and the management approach to make this oversight work as well as it could. 


So, let's explore some simple tips. I don’t claim this is exhaustive, besides, the most important consideration is working to develop an approach that is effective for your organization - for completeness and alignment with your mission and culture.

  1. Focus on Risk. Make sure you can answer this combination question: “What are the most significant risks to our most critical assets and business services, what controls mitigate those risks and who is continuously assessing whether those controls are in place and effective? What residual risks remain and who at what level of the organization deemed those acceptable with what compensating factors or risk transference? What executive management group regularly monitors the measured outcome of this process?” Notice that these questions don't contain the word cybersecurity. This is how you manage many types of risk and is something most Boards and Board Directors will be familiar with. It is, of course, deceptively simple to state but fiendishly difficult to answer well. It requires a significant amount of work to develop risk taxonomies, asset and service inventories, risk and continuous control monitoring and an evolving apparatus of risk governance.

  2. Think Beyond Cyber. Cybersecurity is just one of many technology and information risks and shouldn’t be discussed in isolation, especially given most of the best mitigations for cybersecurity risk are great technology platforms and controls such as software and service lifecycle management, identity/access management, data governance, zero trust architectures and highly resilient and monitored production services. 

  3. Take a Business Perspective. Contextualize all cybersecurity / technology risks in a business context with some view of potential customer impact. This is a good place to think Risk = Hazard + Outrage and factor in reputation risk and brand impact as well as the potential for direct losses or other impairment. 

  4. Business Initiatives - Embed Cyber in other's Content. There are many other discussions at Boards ranging from business initiatives, other risk and control reviews, strategic discussions, financial reviews, attestations, and so on. Work with your peer executives across business lines and control functions to make sure that relevant content on cybersecurity / technology risk appears in their Board content. Work to educate those leaders and prepare them for questions that come from that based on your experience of talking to the Board. This creates what you really desire, the shared responsibility to mitigate these risks across the enterprise. It can be transformational if the Board is asking everyone they encounter about how cybersecurity is managed in the context of that activity / business process as opposed to just asking the CISO.

  5. Measure Capabilities. Develop the means to show the Board what capabilities the organization has to manage cybersecurity / technology risk - not just the current status of the risks being managed. Our space is highly dynamic, so the major measure of an organization’s ability to manage risk is how well they are positioned to see what is coming and to respond to it well. The types of capabilities to measure, and show an improvement plan for, can include: - The products and services the CISO function provides to the organization as a whole, taking a product management view of this is immensely useful including the user journeys of those that interact with the CISO function - The extent of embedded cybersecurity / technology risk expertise in engineering teams, business units and peer control functions (like risk, audit, compliance, safety, quality)  - The degree of embedding cybersecurity / technology risk gates into processes across the operations of the organization (like acquisition, divestment, product development, people performance, rewards, recruiting, strategic planning and budgeting) - The continuous education and professional development of employees and third parties not just in how they are brought to security training content but how security training content is brought to their own roles and processes - The ability to respond to incidents and events as measured through drills and exercises all the way to measured response to synthetic events or simulated attacks - The extent of independent validation of your systems and controls including intense root cause analysis to continually improve - The quality of customer support, from the usability of the security products and services that are delivered through to the transparency of control assurance attestation reports - The human diversity of the overall security organization (centralized and embedded), not just because this is the right thing to do but more importantly because diversity across every dimension assures a diversity of thinking that is essential to risk management - The level of conformance to agreed upon security frameworks (e.g. NIST) and the degree of progress through their maturity levels. This is not to be beholden to these frameworks, as they don't intrinsically assure good security, but the ability to conform efficiently does provide a strong signal of organization maturity that is otherwise necessary for broader security management goals. These can also provide the Board with at least some means of comparability with other organizations whose Boards they sit on.

  6. Demonstrate Business Value. Not just in losses avoided, evidenced (hopefully) from showing incidents at other organizations could not happen to yours - but also showing adjacent commercial benefits such as improved customer experience, reduced insurance premiums, lower loss covering capital retained, increased IT productivity, enablement of new digital services and so on. When talking about incidents avoided because of controls, remember to display some emotional intelligence and thank the Board and your Executive Leadership for their wisdom in supporting your work and initiatives that led you to that effective control posture! 

  7. Present Jointly and Collaboratively. Unless you are in an independent audit or independent risk management capacity where you might be obliged to present independently, then strive to present jointly with your IT colleagues such as the CTO, CIO, Chief Digital Officer, Chief Data Officer or others. Presenting a unified front not only solidifies relationships in the preparation but also increases subsequent collaboration. Presenting jointly doesn’t necessarily mean presenting a singular opinion. It is totally acceptable (perhaps desirable) to illustrate differences in perspective between functions, it’s likely the CISO function might be more conservative. These should never be framed as personal disagreements but rather it is a good opportunity for these to presented as a difference in risk appetite or risk tolerance for which the Board can provide some useful input according to some well developed options. However, this should not be a frequent occurrence - the Board isn’t there to do management’s job. 

  8. Ensure an Independent View is Available. Ensure the Board gets an effective independent view from Audit, Independent Risk Management, Compliance or Counsel. You should strive to avoid the position where you have the accountability of delivery (of controls, mitigation, services, risk issue management and prioritization) and of representing an actual independent view to the Board. Of course, you should be candid, but you can’t hold your truths to be self-evident. Realize that your Audit, Risk or Compliance teams are not there to challenge you as an irritant but are in fact a safety net to make sure you are not becoming beholden to your, perhaps occasionally incorrect, view of risk. Prize their perspective even if you don't agree with it.

  9. Deliver Board Education. Make sure your Board is educated to a reasonable extent, not just for the designated members of the Board who have a background and expertise relevant to this risk. This doesn’t have to happen at the Board meeting itself. Some of the best education is one on one, at Board lunches or dinners and especially at the orientation of new Board members. 

  10. Quantify Risk. This gets most focus in a lot of articles about cybersecurity risk management at the Board level. So, it’s perhaps odd I put this at No. 10 on this list (not that this is necessarily a priority ordering). But, I do think it is a problem that this topic can crowd out the other important approaches we are discussing. To be clear, though, all the items on this list could and should be represented quantitatively. One of the challenges we face is the lack of a comprehensive agreed upon set of measures that can be applied across organizations. It’s like accounting without GAAP (Generally Agreed upon Accounting Principles). There have a been a few attempts at developing this for cybersecurity but I’m not aware of any really taking hold. In some respects the nearest we seem to get to, at least for US public corporations is the COSO and CoBIT frameworks courtesy of their use by External Auditors and internal control teams for the purposes of Sarbanes-Oxley 404 certification. There is also some fine work going on among certain regulatory communities to establish a common framework for metrics but much is still to be done. So in the interim, what are some useful risk measurement approaches that can describe your cybersecurity and technology risk: - Distinguish between measuring inputs vs. outcomes - in other words, unless it is demonstrably to do with capability improvement it doesn’t matter what your headcount or budget is, what matters is the outcome (or not) you get. I am amused by the constant budget benchmarking activities in certain sectors or the obsession of what percentage of IT spend goes to security. In many cases a more automated, SLDC/DevOps embedded and product aligned security team that comes with solutions and patterns will create better outcomes at lower expense anyway - Don’t overly obsess on complex approaches that aggregate too much data into mathematical models or indices unless you have a strong model validation process that can assure the model is representative of risk, is directionally accurate and that the input data meets sound practices of data governance. Some of what it takes to do data governance (for financial risk quantification) is here. Very few organizations have the capability to do this - and presenting the appearance of accuracy to the Board when the underlying data or model are flawed can not only put the organization at risk but can lead to many corporate governance issues - Therefore, don’t feel too bad about picking metrics that are a proxy for or otherwise represent solid cyber hygiene, for example: basic identity and access metrics, software lifecycle control integration, end-of-life status, patching, critical vulnerability resolution times, velocity of issues across your risk register, incident response times, number of repeated findings per team per risk under red team or other forms of tests and so on - Focus on building a library of scenarios, some of which could be quite severe, and build a narrative around how such scenarios would be prevented, detected, responded to, or recovered from. Use these scenarios as a means to overlay specific metrics and then drive improvements in controls to get those metrics closer to a defined target. A scenario based approach is also an opportunity to do some more plausible “value at risk” form of financial impact analysis using a variety of methodologies. Remember, financially oriented metrics tend to only be meaningful in the context of scenarios. Good scenario selection (vs. your potential risk universe), scenario building and validation are important, but are difficult without the right skilled personnel - so get help - Finally, work with the Board to set limits or thresholds for what levels specific measures/metrics should be held to. This should be for future targets as well as minimum current limits to sustain a level of risk mitigation. Establish a process in continuous control monitoring and risk operations to monitor for adherence to Board limits/thresholds and require Board notification upon breach of these limits. This is a standard practice for many organizations, especially for financial risk limits or safety/quality measures, and there are likely numerous organization processes that you can join or copy.

  11. Conduct Incident Reviews. This can align with scenario development, but one of the best means of engagement for Boards is to use internal incidents, close-calls or incidents that have occurred at other organizations to run through a learning exercise vs. your organization’s controls and use that to stimulate any need for improvement. It’s also worth looking at what incidents might have recently occurred at the other organizations your Board members might be part of - to inform you on what to expect their concerns are e.g. if they also sit on a Board of a company that just had a major ransomware event then you can be certain you will get questioned on that topic. 

  12. Prepare for Incidents. It is also useful to make sure your Board understands your incident and crisis response protocols for major types of incidents. This can also tie well with the scenario based review process. Be careful, though, many organizations (large vs. small) have different constructs for Board engagement during incident response.  

  13. Work across Committees. Boards often have multiple committees like Audit, Risk, Nomination, and Compensation. Many also have Technology / Digital Committees. Where and how you channel your work is highly dependent on the committee set up, the degree to which the main Board populate the committees and how much time you also spend at the main Board. There is no one right way of doing this, so do whatever is effective for your organization. However, you should make sure your approach is set from a deliberate and thoughtful discussion with at least the Board and Committee Chairs. 

Bottom line: working with your Board to manage cybersecurity risk is more than just getting the right presentation materials and the right metrics. Rather, it is about bringing a broader enterprise-wide risk management and business view in which cybersecurity risk can be contextualized - and into which your risk quantification can resonate and give the Board some ability to better establish risk tolerances.  _________________________________________________

Links to other relevant posts:

5,795 views0 comments

Recent Posts

See All

A Letter from the Future

A few weeks ago The White House published our PCAST report on cyber-physical resilience. Thank you for all the positive reactions to this. There is already much work going on behind the scenes in publ

InfoSec Hard Problems

We still have plenty of open problems in information and cybersecurity (InfoSec). Many of these problems are what could easily be classed as “hard” problems by any measure. Despite progress, more rese

DevOps and Security

Each year, DevOps Research and Assessment (DORA) within Google Cloud publishes the excellent State of DevOps report. The 2023 report published in Q4 was as good as ever and in particular documented so

bottom of page