Don’t accept risk with a pocket veto

We who live risk management know there are four responses when confronted with a credible risk to our organizations. We can treat the risk to reduce it. We can avoid the risk by altering our organization’s behavior. We can transfer the risk with insurance or outsourcing, though the transfer is rarely complete. Lastly, we can accept risk and hope for the best.

Let’s get this out of the way first: no security professional wants to accept risk. If we had our way, the organization would mitigate or avoid all risks. But that’s almost never the case in the real world. Risks often must be accepted. This can be due to unpatchable security vulnerabilities or expensive remediation requirements.

In a risk analysis, there are usually obvious targets for risk management, such as high probability, high impact risks. Yet there is also usually a long tail of low probability or low impact risks that need to be dealt with. Usually too many to deal with. These become the risks that get accepted until you have the time or resources to manage them (usually never).

Obviously, we hope that these accepted risks never come to fruition, and even more so, we hope our estimates of low impact are correct. But not everyone’s luck holds – accepted risks do happen and the consequences can be dramatic. First off, when we talk about cybersecurity risk, what we really should say is: risk to the business. Because that is where the money is going to be lost when things go wrong. We’re talking about legal and regulatory fines, public excoriation, loss of future sales, not to mention a fair bit of forced resignations.

To do business, especially connected to the Internet, is to embrace risk and to accept that the cards aren’t always going to go your way. Any security leader is going to have to deal with accepted risk and cross their fingers. However, it’s one thing to clearly and consciously choose to accept a risk and another to accept it informally or accidently.

Many risks are accepted like a presidential pocket veto. A pocket veto happens when the president doesn’t formally accept or reject a law but puts it in his or her pocket and ignores it until it’s too late. It’s a passive-aggressive way of turning down something. Over the decades, I’ve seen many organizational leaders do pocket veto risk acceptance. The security team recommends a course of action and puts forth a budget and a plan to deal with it. The organization pocket vetoes by not doing the risk mitigation (or funding it) while also not going on record to accept the risk (and the blame).

At that point, the organization has moved into a reactive position and given up control of the risk. Hopefully it won’t come to pass, but if it ever does, there is no plan—and worse, there may have been no expectation of the potential damage. The risk sits silent and invisible in someone’s pocket.

One of the tenets of security is that there should be no silent failures. Accepted risks should be visible and clearly decided upon. Risk acceptance should not be something that happens by default because no one did anything. Someone in authority must explicitly accept the risk, and then communicate that decision.

This raises the question: who has the authority to accept the risk? It should be a role with some skin in the game. If there are no consequences if the risk is realized, then what would stop that person from accepting all kinds of risk to save time and money? So, usually risk acceptance happens at the C-level, usually tied to the organization or business unit affected by the risk. If e-commerce sales are going to suffer because of a denial-of-service attack, then that business unit needs to be part of the risk acceptance decision.

Also, risk acceptance should never appear ad hoc, arbitrary, lazy, cheap, or worse, overconfident (“It’ll never happen”). If the risk becomes real, the eyes of your customers and regulators will be poring over that risk acceptance decision. Speaking of regulators, organizations can’t accept risk that violates contractual or legal requirements. They must always deal with them or face severe consequences. Overall, risk acceptance must be like everything else in the risk management process: systematic, objective, and based on pre-established criteria. Risk acceptance should fit into a formal system of record that squares with the organization’s formal risk assessment methodology. The key is being able to state: These risks were accepted by this person on this date because it failed to meet these criteria as acceptably significant priorities.

One piece can be added to that statement: and we will revisit this risk acceptance on this date. You never want to become too comfortable accepting risks. Taking on lots of small pockets of risk over time could lead to a big burden of problems. Even worse, accepting a lot of small but related or dependent risks can be the same as accepting a big risk. For example, accepting the risk of denial of service to the DNS systems is the same as accepting the risk of potential downtime of everything Internet-facing.

Ultimately, you want to do what your customers and employees expect you to be doing. They do not want you ignoring or hiding risks with pocket vetoes. Even if something doesn’t go your way, you want to be able to show the world that you did what was reasonable and justify why you made the decisions you made. Anything less casts you as either negligent or deceitful, which is never the story you want told about your organization. Even if you were the victim of an attack.