Understanding a 'Risk Event'

Four principal stages happen in all risk events, i.e,

1. Pre-event
2. Time Lag
3. Realisation
4. Mitigation.

Pre-event Phase

In the pre-event stage there is the expectation that the risk awareness of the people, the effectiveness of the controls, and so on will be sufficient that the risk event is managed before it materialises into a full-blown risk event, that is a loss has actually happened. The period that constitutes the “pre-event” can be quite short or in some cases prolonged, running into weeks, months and in some cases even years. The pre-event stage is when the extent of success of the risk awareness training will become evident. The better the culture the more risk events are captured at the pre-event stage. 

Time lag Phase

The time taken to realize that the risk event has happened can be crucial for a number of reasons. First, no organisation or area is so perfect in its risk management process that a risk event will never occur. What matters in terms of the effectiveness of the risk management process is the speed with which an event, if it happens, is discovered by the control processes the operations manager employs. A long time lag may be an indication of poor monitoring or may be a natural result of the risk event being obscured by something else. An important factor in minimising the likely time lag before an event being realised is the quality of the Key risk indicators (KRIs) and Key performance indicators (KPIs).

The time lag is also influenced by the robustness of the self-assessment (RCSA) techniques of an organization and supervisors. This illustrates the importance that must be attached to the self-assessment process in being a source of identifying possible risk events. The more robust the process is, the better the control over events will be, including rapid identification of an event happening.

Realisation Phase

The phase of realization can be one of panic or organized chaos...In reality of course, a cool head, clear procedures and a positive approach to the risk event is what is needed, not blame apportioning which is of no use whatsoever. The event having occurred needs mitigation but before that can be fully introduced, the profile of the event needs to be established and quickly.

Clear procedures on what to do once the risk event is discovered might look like this:

• List of supervisors and managers for initial reporting
• Compilation of an initial risk event report
• Operational Risk Officer (ORO) for Manager/Department(s) with ownership advised
• Mitigation team provide initial response(s)
• Rectifying Actions authorised by department/manager
• ORO reports to Risk Management Group
• Manager/Department provide detailed Incident Report
• Incident Database (including if appropriate Loss Database) updated
• Details on incident circulated to OROs for “lessons learned” exercise
• Risk Group/Business advised on suggested amendments
• Enhancements to risk management procedures
• Risk Group/Business sign off on Event.

Mitigation Phase

Once an event is occurring and is realised there must be action taken to mitigate the impact. Naturally, this should be instigated as quickly as possible but it is essential that the action taken is both practical and effective.

The business unit itself is usually by far the best people to deal with the result of the event. The risk group and in particular the OROs (or their equivalent) can offer advice and through the procedures outlined above will be involved in monitoring the progress towards successful closing of the event.

It is important to understand that there are lessons to be learned from all and any event, and those lessons when mapped onto other business units may highlight an enhancement to procedures and controls, which might prevent a similar event happening in that business unit.

Lessons learned

It is important therefore that the OROs not only monitor but also review and assess the data on the event and apply their judgements in the context of lessons learned. This is another illustration of where real added value for the business as a whole can be achieved.

The following is an illustration of the contents of an Event Lessons Learned Checklist:

1. Time to realisation?
2. Was the event covered in the self-assessment of the area?
3. Was the assessment correct at the time?
4. Had the event previously registered as a “near miss”?
5. Did KRIs/KPIs work?
6. If no–why?
7. If yes – why did the information not get acted on?
8. Did preventative controls fail to identify the potential event?
9. Was the time lag from inception too impact to short for preventative controls to work?
10. Were preventative controls ignored?
11. Did preventative controls only partially work and if so why?
12. Which type of process/situation in the unit is similar?
13. Is the risk event common to other processes/situations?
14. Do other business units have similar processes/situations?
15. What other observations on lessons to be learned are there?

The whole purpose of active operations risk management is not to point the finger or to apportion blame but simply:

1. To ensure that the event is understood
2. Its impact has been terminated and
3. Any lessons have been learnt.