Timescales for Remediation and Tracking Remediation Progress

Timescales for Remediation and Tracking Remediation Progress

Clearly, if there is an immediate problem of concern, managers and stakeholders will likely agree to deliver a ‘quick fix’ as soon as possible. This may also include ‘containment’ and ‘recovery’ actions to undo any immediate adverse impacts. This is a territory that many organisations will be familiar with.

But once the damage has been repaired and a quick‐fix improvement implemented, key questions to consider afterwards are: (i) how robust are any quick‐fix measures? (ii) How quickly should a longer‐term solution be put in place?

Suppose we need to change a process, improve staff training and automate certain activities in a system. On the one hand, we would like to fix things as quickly as possible. Still, on the other hand, we mustn't fix things in such a rush that we make mistakes in the way any new processes and systems are updated.

A good practice is to create a framework within which the dilemma between (a) the speed to act and (b) the time to ensure actions are robust is considered and addressed.

Some organisations specify remediation timeframes. So, for high‐impact areas, they might specify: ‘These should usually be fixed within (say) 1–3 months if action just relates to simple process changes and (say) 4–6 months if an IT system change is required. And suppose there isn't enough resource to do this in the time specified. In that case, this should be escalated to an operations committee or risk committee to ask them to decide whether an additional resource should be allocated or whether they are going to accept risk for a longer period’. Diagram A.2 illustrates the sort of remediation framework that can be adopted.

Diagram A.2 Recommended remediation timescales

This framework is helpful because:

1. It encourages consistency across different areas about what should be done and by when;
2. It seeks to normalise the process for determining whether there will be additional resources (or not);
3. It ensures that accountability for any risk exposures sits with budget holders who have the authority to expedite actions or not or gets escalated further if they do not have the authority to act (e.g. when a cross‐functional initiative is needed).

In terms of tracking progress, a good practice is to set SMART targets at intervals.5

Thus, for a new IT system to be in place in, say, 24 weeks, it might require a plan along the following lines:

• 6 weeks: new, approved process, with critical new IT system requirements clarified;
• 8 weeks: commencement of systems upgrade;
• 16 weeks: system built and tested;
• 18 weeks: staff training starts;
• 22 weeks: staff training ends and go‐live decision made;
• 24 weeks: new IT system go live.

In this scenario, any problems with resources or priorities would become transparent within weeks and can be escalated quickly, reducing the chances of last‐minute surprises.