top of page
  • Phil Venables

12 Step Guide on Escalating Risk and Security Issues 

Escalating issues is part of the foundation of any good risk and security program. Unfortunately, human nature is such that most people are reluctant to do this and so sometimes critical issues aren’t raised early enough, high enough, fast enough or with sufficient fidelity to permit timely action. This reluctance stems from various factors including:

  • Operating in a “shoot the messenger” culture where management’s first reaction to what might be bad news is to assign blame as opposed to running toward the problem to fix it.

  • Concern over inaccuracy, the first report is always wrong and so timeliness of reporting can conflict with a psychological need for accuracy. 

  • Wanting to avoid damaging relationships with people who might perceive being negatively impacted by the escalation.

  • Reluctance to own the work and actions to fix the issue.

  • Unwillingness to deal with the opportunity cost, like your (or someone's) favorite project being postponed to deal with the issue.

  • Fear of reputation impact with auditors, regulators and possibly customers who may have adverse reactions when confronted with a “restatement” of prior disclosures that such issues were already resolved.

There are probably other factors, but it all comes down to two fundamental cultural themes: a lack of psychological safety in the organization and a lack of a systematized risk management process. If corrected for, the former promotes blame free transparency and the latter is a system that drives transparency whether people want it or not. Both are ideal, one can be sufficient.  Like most cultural transformations you don’t go from bad to good in a single step, rather you execute a number of activities and practices that build you toward the goal over time. Here’s a starter list of such practices:

1. Manage to Escalation Thresholds

Establish and regularly communicate mandated escalation thresholds of what type of matter gets escalated when and to where. This way, when an issue comes up that you need to escalate it is “the process” that makes you escalate and so it de-personalizes the whole situation. This is a significant contributor to psychological safety for all involved. Now, I know, you can't prescribe every situation so it’s also useful to stipulate that anyone can and must escalate matters that aren’t explicitly covered in the process. You will, of course, need to constantly tune this. 

2. Create and Use Ceremonies

Part of the escalation tension is escalating an issue to a person in authority as opposed to using some established operating process or meeting. The existence of such venues permits there to be a “ceremony” or regular moment where escalated issues are reviewed in a matter of fact way with the right group of people. Such venues could be risk committee meetings but could also be weekly operational reviews, product reviews, daily stand-ups ; in fact any venue you can route matters to in a timely way that has the right group of leaders and the right context. Some matters might need such urgent escalation other approaches need to be used as well.

3. Forewarning Escalation

Always give the affected people (colleagues, teams, managers, executives) a heads-up that something is building toward an escalation if you can. Even if it’s just a day or so notice it will give people chance to address the issue or prepare their own communication channels to not be blind-sided. They’ll appreciate the chance to take care of things in their own way. 

4. Building and Testing the Escalation Pipes

Much of what goes wrong (or is perceived to have the potential to go wrong) in escalation centers around two logistical aspects: 

  • The conflict between timeliness of communication and accuracy (“fog of war”). The sooner people get over that the easier the escalation will be. 

  • The order and spread of escalation. Often there is a race to make everyone in authority sufficiently aware in parallel (so peer leaders don’t feel left out of the information flow, even temporarily) and also to respect the hierarchical ordering of who needs to know what first so they can communicate in their own way to their leadership. 

Of course, all of this is impossible to optimize. So, side-step the whole process and build an escalation pipeline especially for urgent unexpected matters like first incident notification or other pressing matters like regulatory issues, customer complaints or similar. You need to define mailing or other communication lists (of senior people, or multiple lists for different levels) and a standard format for such communications. The standard format of communications should contain a header like “This information is what we know now. It might be wrong. We will be issuing more communications as we gather more data.” Then stick with the process. 

5. Practices to Build a Culture of Risk Openness

Script relevant leaders at regular meetings or other venues to incessantly ask the following questions:

  • “Are there any issues any of you are concerned about that we should discuss now?” and,

  • “Are there any issues that could well bubble up to such a level of concern that it’s worth a quick posting on now?” 

This introduces some psychological safety in the act of sharing - providing the leader posing the question has been pre-trained to coax the process and to not punish raising, what in hindsight, might be seen as trivial matters. The other effect of this is to create the incentive to share - such that if it turns out something wasn’t escalated in this context there can be the right inquisition as to why you didn’t share when you had the opportunity to. 

6. Reward the Messenger

This is easier said than done and requires management action to not only not shoot messengers but to amplify back to the organization the rewards and kudos to people escalating issues of concern. 

7. Escalate Issues Not Perceived Negligence

You should never be escalating “on” someone. Rather you are always escalating a matter of concern. Let’s say a particular area has a critical risk issue they are severely late on mitigating and you have low confidence they will address. You need, of course, to have the direct conversation with the leader of the organization responsible. The next course of action is to discuss with that leader that you have to escalate the issue (because of its severity, or ideally because of the process you have defined) and you would like to do this jointly in the context of the root cause of the lack of action. This root cause is usually conflicting priorities, focus on other critical work, dependencies on other areas that are intractable and so on. At first you might not think these are true but invariably they are when you do enough of the 5Y’s. So, seek the win-win, I’ve found if you help frame issues as a means for them to get more resources to improve their products and services and at the same time resolve a risk issue then they will partner in the escalation. 

8. Educate Yourself

Some of the things you might want to escalate may well be less significant compared to other matters those leaders might already be dealing with. Unless something is truly severe and immensely urgent it’s always worth taking a day or so to put yourself in their shoes and see what’s going on across their organization. 

9. Circumvent Escalation

A lot of escalation is due to surprise i.e. something everyone thought was fine is now suddenly not. Most of this is because project plans or other tracking dashboards when examined have a status flag approaching a deadline that has gone Green, Green, Green, Green, RED!!!!!!   The best way to deal with this is to put in finer grained interim milestones, like a canary in the coal mine of the work, to provide an early warning things are going poorly. This gives a chance for things to be addressed before escalation is needed. 

10. Look for Escalation Failures in Incident Reviews / Post-Mortems

In many cases when doing an incident review there will have been some awareness of an issue that needed dealing with that was a causal factor in the incident. So, question, could that issue have been escalated better?

11. Look for Escalation Opportunities in Pre-Mortems

Similarly, in project pre-mortems script in the right moments to look for known issues that have not been escalated or made appropriately visible. 

12. Whistle-blower Programs

Finally, the last safety valve of escalation is to implement a whistle-blower program whereby anyone in the organization is empowered to escalate anything in a protected way. I have seen a number of organizations in many industries find that implementing a whistle-blower program improves overall risk issue transparency and escalation simply because the goal of management becomes centered on avoiding issues having to go to the whistle-blower program. 

Finally, many of you will have already observed that most of these steps are natural processes inside so called High Reliability Organizations and an even more broadly useful approach to solving your escalation issues and many other things would be to embark on a journey of adopting some or all of the characteristics of such high reliability organizations.

Bottom line: put in place processes to force the right form of escalation that is less susceptible to individual judgement, but when judgement is needed if you find yourself thinking too hard about whether to escalate something then the answer is always yes. 

3,928 views0 comments

Recent Posts

See All

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

The 80 / 20 Principle 

Ever since I first became familiar with the 80/20 principle, and other circumstances marked by Pareto distributions, I began to see examples of it everywhere. Naturally, I’m particularly biased to obs


Commenting has been turned off.
bottom of page