Boards and Risk

Lawyers love writing about talking to the Board about privacy and cyber, and I could add yet another article to that mix—but I won’t.?Instead I’m going to write about how to talk to your Board about risk, not just about root causes.

Starting from our corporate governance principles, we can illustrate how a corporation operates.?The corporation creates business operations to operate itself consistent with its direction and strategy.?Those operations are made up of sub-component business processes and other activities.?That could be a payroll system, an accounts receivable system, a business process that facilities the manufacture of advanced semiconductors, or the software development process.?

Which illustrates the point—companies operate through business processes, and the disruption or interruption of them is what creates risk for companies, and to be clear here when I am talking about disruption and interruption, I am including alteration of the process as well (including potentially theft of data).?The point here is that those risks are the same independent of the root cause.?

What do I mean by a root cause—the root cause is the reason that a business process has been interrupted or disrupted.?An example makes this clear.?If a company has a business process that is dependent upon a data center, there is of course risk that the data center gets shut down due to ransomware, but there are other risks as well.?What if the data center goes down due to a flood or other natural disaster??Isn’t that the same risk, even though the root cause is different??The answer is clearly yes.

Without question, how different root causes are governed differs, and there will be different controls (though some will be the same--off-site backups) put in place to deal with ransomware versus flood risk, which helps us illustrate this using our prior definition of governance.?

As previously noted, Boards are fiduciaries who are generally not involved in the day-to-day operations of the company, while the SLT and management operate the company, and looking at this graphic in that light begins to help us define the problem with some of the thinking about how to talk to Boards about privacy and cyber.?It is not that I think that the most senior leaders in a company should be unaware of the control posture on critical issues, but I think that at times there is almost an exclusive focus on the root causes—“talking to the Board about privacy”--and the control portion of the governance process for a particular root cause.

We see this in any number of areas, not the least of which is defining escalation criteria for Boards.?Is “ransomware” an issue that should be escalated—maybe—but doesn’t it really depend less on the root cause of a problem, and more on the risk—namely the interruption of the business process??Said differently—wouldn’t you escalate the issue of the loss of a critical data center to your Board if it went down due to a flood, not just ransomware??And shouldn’t we be at least considering how we deal with other root causes that aren’t privacy and cyber to try and align how the company manages risk across different domains?

Changing our thinking here also begins to address the technical gap that can exist at times between the Subject Matter Experts who operate the company, and the Board (assuming there aren’t privacy or cyber SMEs on the Board).?While the technical portions of privacy and cyber are very important--they are controls on the root cause—as illustrated above, they are part of the solution, but not the only part of the solution.?

Privacy and cyber are critical issues not because they are a particular type of root cause, but instead because of the criticality of connectivity and data to our current line of communication.?In other words, a disruption to the road or the fuel may need to be escalated no matter the root cause, but not because of it.?So instead of exclusively focusing on talking to the Board about privacy and cyber, we need to consider talking to the Board about data and connectivity, the risks that result from the interruption of critical business processes that are dependent upon them, and then putting the root causes that cause the interruption in the right context.??