Revising a Tolerance After an Incident

Revising a tolerance after an incident means asking, with evidence in hand, whether the limit that was set before the incident still describes intolerable harm correctly. An incident tests a tolerance in a way that rehearsals can only approximate, because real users, real timing, and real knock on effects are involved. If the incident shows that harm became intolerable before the limit was reached, the limit was set too generously. If the incident shows that the limit was crossed without intolerable harm, the limit may have been set too cautiously, or the harm assessment may have missed something. Either finding should lead to a considered revision, owned and recorded, rather than to a defensive account of what happened.

The illustration here is a trading platform service disrupted during a period of market volatility. Customers could not place or amend orders for a period, and some customers faced consequences that outlasted the outage itself, because market conditions moved while they were unable to act. The incident therefore raises a specific question for revision: did the tolerance capture the harm of being unable to act at a moment when action mattered most, or did it treat all periods as equivalent? Revision begins with that question, not with a general wish to improve resilience.

Revision should be driven by evidence about harm, not only by evidence about systems. System logs show how long the service was unavailable and which components failed. Customer contacts, complaints, and cases of knock on consequences show what users actually experienced. Counterparty information shows whether obligations were delayed or distorted. Reconciliation records show whether data remained trustworthy after return. Together, those sources allow the firm to compare what the tolerance predicted with what the incident produced, and to identify where the prediction failed.

Not every incident should lead to a looser tolerance, and not every breach should lead to a tighter one. A tolerance should not be loosened simply because the firm wishes to avoid recording a breach, or because recovery came close to the limit. Loosening after a breach, without evidence that harm was in fact tolerable, repeats the central pitfall of this cluster in a new form: the limit is moved to fit the outcome, and the signal that harm was intolerable is erased. Governance should therefore require a clear harm based reason for any loosening, recorded alongside the incident evidence.

Revision should be governed as a judgement, with an owner, a rationale, and a record. The owner is the firm that sets the tolerance, overseen by its board, and the board should be able to see what changed, why it changed, and what evidence supported the change. The rationale should explain the harm assessment in plain terms, not merely state that the tolerance was updated following an incident. The record should sit with the service, alongside the previous tolerance and the incident evidence, so that later readers can trace how the judgement evolved and can challenge it if new evidence emerges.

After revision, the tolerance must be tested again. A revised limit that has never been rehearsed is a hypothesis, not yet a judgement supported by evidence. Testing should use a scenario that challenges the revised limit, particularly the aspect that the incident showed to be weak, such as timing sensitivity, a specific user group, or data accuracy after return. The test record should be filed with the service, and any further weakness it reveals should lead to further action, whether that action is a further revision or a change to recovery arrangements.

A reader can test a revision by asking what incident evidence supported it, whether the revision distinguishes a tolerance failure from a recovery failure, and whether the new limit has been tested. Further questions concern governance: who approved the change, what rationale was recorded, and were connected services checked? If those questions cannot be answered, the revision is incomplete, however promptly it was made after the incident.