From Excel to Excellence: Revitalizing IT Risk Strategies for a Future-Ready Landscape

Still, IT risk management is often based on traditional management approaches that assume linearity and predictability such as checklist processes, KPIs, and periodic review cycles. Additional implementation problems like excessive documentation demands, limited stakeholder involvement, and a lack of adaptability further contribute to their shortcomings. As a result, IT risk management often struggles with the dynamics of modern software environments. To successfully navigate complexity and continuous change, IT risk management processes will benefit from a more adaptive and collaborative approach that embraces flexibility, continuous adaptation, and engaging diverse teams and stakeholders, while avoiding the pitfall of creating a new rigid framework full of constraints.

Luckily, we don’t have to reinvent everything from scratch; over the years strategy [1] and architecture [2] faced the same challenges in dealing with complexity. Risk management can benefit from adopting similar, more context-aware, approaches based on the ideas of systems thinking, complexity theory, and sensemaking:

Systems thinking involves considering the entire system and its interdependencies, recognizing that changes in one part can have ripple effects throughout the system [3]
Complexity theory acknowledges that organizations are dynamic, adaptive, and subject to emergent behaviours that may not be evident [4]
Sensemaking techniques support the process of making sense of complex and ambiguous situations, involving tools and structures for effective information gathering and interpretation [5]

However, these approaches need to be translated to the risk management context. In this article we will provide some examples on how to do that.

Define Risk Guardrails

Most organizations have operating models based on static rules and principles. If you look at the reality we live in, organizations are sociotechnical systems where individuals interpret, shape, and bend these rules through their (biased) decisions.

On one hand, this flexibility helps organizations to seize opportunities, take chances, and continuously adapt to change to achieve their goals. However, since every action has risks, every decision should manage the balance of risk and reward. Without this balance, decisions can potentially expose the organization to unacceptable risks.

Complexity theory states that to deal with the unpredictable nature of complexity it is crucial to move from a rule-based system (output) to one based on vision and direction (outcome) [6]. This clarity enables better decision-making and allows teams to make choices autonomously and without confusion.

In IT risk management, this means we need to rethink how we communicate risk appetite (or risk tolerance statement [7]). The challenge is finding a balanced statement that clearly defines the boundaries on how much risk an organization is willing to take to achieve its goals, without dictating how to achieve that. A good risk appetite statement should be usable as a moral compass by everyone in the organization. So instead of using an excel sheet full of numbers and calculations, it should be a document that can be interpreted and provide guidance. A good approach to achieve that is the TASTE [8] approach (readers with a background in LEAN might recognize similarities to the House of Quality [9]). This approach clearly defines the vision (‘True north’), but also defines aspirations, strategies, tactics, and evidence.

The first 3 levels we should be able to construct from the information typically presented at an organisation:

True North – clearly defines what should be prevented; this should be a simple statement that describes the largest threats to be prevented; think of a form like the Agile Manifesto [10] or a level 1 overview in the architectural C4 model approach [11].
Aspirations – the results we hope to achieve; these go 1 level deeper and describe how to achieve those objectives; this level would resemble the 12 agile principles [12] or a level 2 in the C4 model approach [11].
Strategies – existing guiding policies that enable us; this is the level we typically create policies on; the challenge here would be to create a clear mapping to the higher levels and create an easily navigable decision tree

The ‘tactics’ level needs some a need some additional translation in an IT Risk Management context:

Tactics – actions we can take; this should be a collection of actions that provide actual guidance and inspire teams in designing solutions. Again, we can learn from architecture by adopting the ideas behind Architectural Decision Records (ADR) [13]. An ADR database acts as a historical knowledge bank that provides context on how to apply existing strategies and tactics. (It might even be worth investigating if risk decisions can be part of an ADR, as a risk decision is some form of architectural decision.) When taking this approach, it is important to add a ‘time of recording’ and define the ‘trigger to revisit this decision’ to prevent ending up with slow, bureaucratic, and unmaintainable spaghetti policies.

The evidence level is, again, a level we should be able to deconstruct from what we have. However, by combining and implementing it in the TASTE model, it immediately provides examples for validation and testing of the chosen tactics.

Evidence – the outcomes that measure progress;

By creating a risk appetite in the form of the TASTE framework you can give direction to teams, provide them guidance on how to test their solutions, while at the same time create a historical database of successful and unsuccessful approaches.

Figure 1 an example of the TASTE template 8 edited — Figure 1: an example of the TASTE template [8]

Learn to love Complexity

To manage the amount of information, humans have the natural tendency to abstract details. While this is not a problem when the contexts are still retrievable, without these essential nuances it becomes hard to translate high level concepts back to specific contexts.

The problem with contexts is they are often riddled with jargon. This jargon can create communication challenges and silos, hindering stakeholders from different departments in forming a mutual understanding (which is why we abstract in the first place). Even seemingly simple concepts as issue, impact, customer, or dependency can have different meanings in different contexts. When there is unclarity in language and context, misunderstandings will arise, so it is vital to get rid of these communication gaps.

Often the risk analysis process already applies abstraction that normalizes the context. An example would be summarizing the results of a risk analysis session into a Business Impact Analysis (BIA) document that only contains high level statements. While the the BIA serves a purpose, it should be a summarizing statement of a more complete overview that holds all the context. When that context is discarded and only the conclusion is kept, it inevitably shifts the focus from addressing the real problems to compliance complacency, ticking boxes, and meeting management expectations. So, while high reporting requires abstraction, the risk analysis should also be kept in a nuanced and context-aware form with the necessary jargon.

Again, we can adopt good practices from IT architecture. The Bounded Contexts concept from Domain-Driven Design (DDD) [14] is a useful approach to help with this challenge. Within a Bounded Context, teams use the jargon of the domain. However, when communicating with other teams this ubiquitous language is actively minimized and clarified.

For example, the term ‘contact’ might have different meanings depending on the business domain. This is not a problem when the term is used within the same business domain, but it needs to be clarified when aligning with other business domains [figure 2].

Figure 2 an example of bounded contexts in an organization 13 — Figure 2: an example of ’bounded contexts’ in an organization [13]

By using bounded contexts in risk management, risks can be specified in the language that is used in a domain, while providing a translation to make the risk clear to other domains. This approach provides a framework that allows to go back and forth between abstraction and context without being overwhelmed with details.

Documenting bounded contexts is not enough though. They often have dependencies that are important from a risk perspective. Luckily DDD also provides a solution from that in the form of a context map. A context map visualizes which contexts have a dependency, but also the type of dependency [15]. It is important to realize that a context map is fundamentally different from an architectural overview, as it also contains business processes and the nature of the relationships. Because of this, a context map “leads to deeper insights in the way we build our software integrations because it uncovers hidden dependencies” [16].

Once we have our dependency map, we can identify the places where risks might occur and make them part of the model [17]. For example, while creating the context map for a bank we discover two domains that use identical terms for different entities. We can flag that on a map as a hotspot for risks.

Figure 3 a context map containing several bounded contexts and identified risks 17 — Figure 3: a context map containing several bounded contexts and identified risks [17]

This way we can always keep track of how changes in the model impact identified risks or needs additional analysis to identify new risks within the bounded context.

Beyond the Impact-Likelihood Matrix

Another form of abstraction we see is the traditional 3×3 (or the more advanced 5×5) ‘impact times likelihood matrix’. While this is a highly effective communication tool towards (upper) management, like the BIA, it also oversimplifies complex scenarios. While ‘impact’ might be easy to quantify, the likelihood part is hard to quantify in complex systems.

We could solve this by running endless monte carlo simulations to calculate more accurate numbers, but they are extremely time-consuming and provide the best results when all variables are identified [18,19,20]. Given the uncertainties in complex environments, this does not look like the best approach.

Instead of chance or likelihood, a better approach is to look at dependencies and ‘effort to change’. Over the last few years, Dave Snowden developed Estuarine Mapping as “a counter to traditional approaches to strategy that are fixed in nature and reflects the key principles of change in a complex environment” [21]. In an estuarine map the likelihood is divided into 2 axes: ‘the energy of change’ and ‘time to become effective’. This allows us to identify the best strategy for a threat, regardless of likelihood or frequency.

Some examples on how mapping constraints in a risk context would work:

Area 1: changes in laws and regulations can pose a high impact risk to the organization, but typically require a lot of time and energy to change. This risk will be placed in the upper right corner;
Area 2: code changes or vulnerabilities in external libraries are easily introduced and are typically implemented automatically. As risks can easily and quickly be introduced via this way, it should be placed in the lower left corner;
Area 3: supply chain issues can easily disrupt an organization (i.e. the time factor is low), but typically require large energies to change (think pandemics or wars), so these are placed in the upper left part.

Figure 4 an example of an estuarine map visualising effects in the organizational landscape 21 — Figure 4: an example of an estuarine map visualising effects in the organizational landscape [21]

Each risk then gets additional context such as the effect (i.e. ‘maximum impact’) and actors (e.g. bounded contexts that are impacted). Based on their position in the map, mitigating actions can be defined; things in area 1 can safely be monitored, risks in area 2 left corner should be mitigated, and for things in area 3 a disaster recovery plan might suffice. The advantage of this approach is that it provides context such as time, energy, and triggers and assume risks are not isolated but part of a broader, interconnected landscape that changes over time. It does not focus on individual components but can also track their relationships and cumulative effects over time.

Similar to the BIA and bounded contexts, transitioning from just the conventional chance score to a contextual map, will enable more effective risk management. This way, estuarine maps can reduce conflict around decision-making and enable organizations to adapt quickly to changing circumstances when needed. An additional advantage of this approach is that you can expand it to provide a holistic view of the complete environment that not only contains risks, but also opportunities and rewards.

From Catalogs to Refinements

When we embrace the complexity of the world we live in, embrace business context, and implement visual representations on multiple levels of granularity, the only thing left is keeping things up to date.

Similar to technical refinements or retrospectives, this can be achieved by implementing a flexible approach based on frequent check-ins (e.g., weekly or monthly) to review risks. During these check-ins, teams can adjust the strategy in response to technological changes, emerging threats, or shifts in organizational priorities.

Sensemaking techniques like liberating structures [22] are designed to encourage open communication, break down barriers between teams, and foster an environment where everyone feels empowered to contribute valuable insights. For example, TRIZ is a powerful exercise that challenges the team to think about how to break the existing system, deconstruct it into critical steps, and identify which are already present and should be mitigated. Other examples of liberating structures that focus on creating a culture where risk awareness becomes second nature are Wicked Questions, Wise Crowds, and Panarchy.

Using these techniques in regular open-minded discussions will lower the barrier to talk about potential and observed risks and encourage to report and address them swiftly. In this loose, agile approach, IT risk management is no longer a separate process but becomes an embedded part of the development journey, working hand-in-hand with the business teams.

Conclusion

In conclusion, the next step in the evolution of IT risk management requires techniques that encourage flexibility, collaboration, a culture of continuous adaptation, and a granular understanding of risks.

Minimizing miscommunication is crucial and can be achieved by defining clear guidance and providing a common language for decision-making. Navigating complexity requires a nuanced approach, integrating systems thinking and complexity theory. Bridging communication gaps, avoiding oversimplification, and using visual tools will allow a more nuanced understanding of risks. Automation and regular check-ins contribute to a culture where risk awareness is second nature, integrating IT risk management into the development journey.

This way IT risk management has a better chance at facing the challenges of the modern world and do what it is supposed to do: safeguard valuable assets, achieve organizational objectives, and ensure long-term success.

Disclaimer ENG

The authors alone are responsible for the views expressed in this article. The views mentioned do not necessarily represent the views, decisions or policies of the ISACA NL Chapter. The views expressed herein can in no way be taken to reflect the official opinion of the board of ISACA NL Chapter. All reasonable precautions have been taken by the authors to verify the information contained in this publication. However, the published material is being distributed without warranty of any kind, either expressed or implied. The responsibility for the interpretation and use of the material lies with the reader. In no event shall the authors or the board of ISACA NL Chapter be liable for damages arising from its us.