Impact Tolerances – Beyond Time Based Metrics

In our last white paper titled “Pragmatic Resilience” we touched on the 6 core principles within the Operational Resilience Policy from the UK financial regulators. Perhaps the most challenging topic (and one where UK regulators have gone further than many other jurisdictions) is the setting of impact tolerances for important business services (IBS).

These tolerances draw a line in the sand, which if crossed will cause unacceptable levels of harm to consumers, the firm itself or the UK’s financial stability. The regulators have left firms to define what is unacceptable, albeit dropping some strong hints that they may set industry wide tolerances for payment services.

The assessment of harm should be done during the firm’s peak periods, for example the end of the tax year or retail events such as Black Friday, as unfortunately firms do not have the luxury of dictating that an incident hit on a typical mundane Monday.

When attempting to set impact tolerances, it’s likely that you will encounter several challenges:

• Materialisation of harm: does the harm materialise straight away or is it delayed? Does it have knock on effects on other stakeholder groups that are not immediately obvious? Is there a broader systemic impact?
• Identifying vulnerable customers: the regulators often expect that firms will act to minimise the harm to vulnerable customers, but many banks may not have appropriate mechanisms for identifying their vulnerable customers or segmenting their customer base in a way that allows a more sophisticated assessment of harm.
• Aggregate impact tolerances: Unfortunately, incidents and disruptions very rarely affect just one IBS and therefore setting impact tolerances for individual IBS cannot be done in a silo. For example, a cyber-attack that targeted part of a firm’s core infrastructure may disrupt many servers, endpoints and services which depend on them. The NotPetya attack of 2016 often led to the encryption of the Windows Active Directory, causing major upstream impact as Maersk and many others discovered. Firms will have to consider the aggregate number of affected customers across multiple IBS when setting and testing tolerances.
• End to end services: depending on the methodology used by firms to define their IBS, a collection of end-to-end IBS may be needed for a customer to complete a transaction. For example, for a customer to complete a payment: they need to have access to a channel (online banking, a banking app, telephone banking or a branch); the firm also needs to have access to payment scheme and conduct settlement to finalise the payment. As a result, the impact tolerances of these different services are interdependent and require an approach that does not look at impact tolerances for each IBS in isolation.
• The value of collaboration: the regulators have been clear that they do not want to dictate impact tolerances for the majority of IBS, except perhaps for key services such as payments, instead allowing firms the freedom to set these as they see fit. This may cause issues if banks have wildly different customer impact tolerances for comparative services. Of course, we can expect regulators to challenge and drive alignment over time, and there will be industry dialogue on the approaches adopted with firms reticent to be an outlier within their peer group.

As with many new concepts, the definition and application of impact tolerances will inevitably evolve over time, beyond the release of the Policy and 12-month compliance window.

Early experience suggests it is driving firms to define IBS, to focus on customer harms, and to take a systematic approach to calibrating those harms. It will take time to get this right, and I fully expect that the initial round of impact tolerance definitions will be followed by refinement and alignment.

Equally, the process of scenario testing (the subject of our next blog) will uncover some uncomfortable truths about the ability of firms to stay within those proposed tolerances, but perhaps better those truths appear through test rather than actual incident.