top of page
  • Julien Haye

Case Study: Incident and Breach Framework Integration

Updated: Jun 16

7 processes to manage incidents or regulatory breaches to choose from. Which one(s) do you pick?


Financial institutions cannot have risk management without also having compliance. The organic development of these functions has led to material duplicative efforts aimed at managing risks whilst ensuring compliance with laws, rules, and regulations.


These 7 frameworks were all somewhat doing the same thing, but not completely. Almost all reported on incidents in a different way to various business groups and executives. It was impossible to change or converge any of them because they were “all immutable”. At the same time, the business-users complained of the lack of perceived value and workload.


In short, the situation was a mess.


The Benefit Case


The benefits accrued by integrating and simplifying this complex ecosystem are significant.


This includes stronger risk management capabilities enabling increased transparency on actual risks and effectiveness of the control environment. Then, firms will benefit from improved cost-efficient risk and compliance management, whilst making the life of business users, and risk and assurance functions, much easier. It also strengthens your regulatory position by creating a centralised source of “official” incident data. Finally, clients benefit from a structured and transparent error management process.


Figure 1 – Incident integration business case

To come back on a key benefit, a centralised incident management process makes it much easier to get a comprehensive picture of what is going across your organisation and potential weak points. For instance, the number of incidents reported was multiplied by 4 in a 2yr period, as a direct result of the centralisation – events were not scattered in multiple databases anymore – and enhanced our ability to track down under-reporting areas.


A similar pivot can be made on assessment framework - read my article here.


The Opportunity Assessment Framework (OAF)


Over the year, I have been using a simple framework to assess transformation opportunities. Whether you work in risk management, treasury or front-office, this method performs for any type of activities. So, I am sharing it with you now. Hopefully, such approach should be straight forward to implement for your firm and remove the “emotion” out of the discussion.


The OAF enables a simple identification and assessment of capability(ies) or process(es) that would deliver the most value if enhanced, transformed, or perhaps simplified. It is not possible to change everything at once, but the output of this assessment when used as an input into a wider cost / benefit analysis supports functional prioritisation.


In this article, I have applied the OAF to incident and regulatory breach management processes.


Figure 2. The Opportunity Assessment Framework

The OAF output must be put into context with the activity(ies) under review and, if possible, articulated in terms of cost savings and efficiency gains.


For instance, this technique works wonders when combined with process excellence methodology. A focus on what type of capabilities or activities are system driven vs. “human driven”, and how to streamline them.


Stated differently, once the duplications or gaps are identified, the objective is to organise and sequence the required capabilities as to optimise business user’s workload and making sure the “running the risk process” does not overtake the “managing the incident”.


Step 1 - Incident and breach framework Inventory


To start with, create an inventory of the processes, databases, frameworks, etc. existing in your organisation. I summarised in the figure below the type a of incident and breach frameworks I encountered over the years.


Figure 3. Incident & Breach frameworks

It is highly likely, and I faced this situation multiple times, that you will find duplicates in each of the above categories. For example, the business could implement multiple incident processes depending on your organisation structure.


Step 2 – Functional Integration


Once the inventory is established, it is necessary to understand what each framework does and to break them down into their component parts and associated capabilities. I summarise the findings into a simplified end-to-end process view below.


Figure 3. Simplified end-to-end incident process

To get a better understanding of what this means, it is advisable to run a set of scenarii – e.g. regulatory breach; “simple” technology outage; complex technology outage leading to regulatory breach and client losses, etc.


Clearly the number of permutations can be very large. The objective is to understand what business users will have to do depending on the situation they are facing. I illustrated below an example based on a complex technology outage leading to a regulatory breach and client impact.


The overarching consideration is that each framework deals with some aspects of the incident but never fully and not in sequence, which is a source of confusion and potential poor decision making.


Figure 4. Incident and breach scenario

In this example, a business user would have to face 3 incident processes. The tech incident process is primarily focused on service restoration and does not consider client impact. Then, or in parallel, the compliance breach process deals with any regulatory breach and notification. Finally, the risk event process covers the full impact of the incident including client compensation, the root cause analysis and any remediation required beyond what the technology team fixes.


This becomes quite problematic when the outage impacts several systems, and each system must be restarted in a sequence that might fit the technology group, but increases the level of client impact. This is a critical aspect when it comes to operational resilience.


This disaggregated landscape triggers additional complications:

  • Inconsistent escalation: the technology incident process in this example is likely to be invoked first; it will have its own set of target audience leading that some impacted party being made aware something is happening whilst other might not be made aware.

  • Inconsistent decision making: as a result of the above, not all impacted parties are going to be in the room when operational decisions are being made, potentially exacerbating the issue at hand.

  • Another major regulatory headache is the lack of single and official source of incident and loss data. This becomes an issue to support regulatory capital and stress / scenario testing as well as what data to provide regulators with when asked, as none of the datasets or reports might be complete, of good enough quality, etc.

You could also face poor data quality, notification flooding, etc.


Step 3 – Implementation


I do not like spreadsheets to run BAU processes. Once the prototyping is finalised, I aim to transition the new process into “strategic” solution. I am also a big fan of using agile working for prototyping directly into a strategic solution, whenever possible.


With that in mind, converging all these processes into a common system is easier than it sounds and you should be able to get there within 12-18mths – perhaps faster if you can convert an existing risk solution.


The biggest challenge, beyond winning hearts and minds on the need for simplification, is to decide what to do with historical data. You might also hear of an obscure regulatory requirement preventing you from such integration. If faced with such objection, ask to get the actual regulation and article to check what it says (assuming such requirement exists …)

 

Who wouldn’t want stronger risk management capabilities, increased transparency on actual risks and effectiveness of the control environment and lower costs?


Taking the bold and potentially disruptive step to simplify your risk and compliance environment can yield significant benefits. This starts with establishing a common vision organised around a set of business, regulatory and client outcomes to remove any emotions from the various impacted teams.


The outcomes are expected to be aligned to the above benefit case: better risk and compliance management, a much better understanding of the pain points in terms of sources if issues across the firm, and ultimately a scalable and efficient solution.


Please reach out if you would like to explore this opportunity for your firm



74 views0 comments

Recent Posts

See All
bottom of page