Operational Resilience and DORA: Mapping Vendor SLAs to Important Business Services

Operational resilience has moved from a good-practice discipline to a supervisory expectation. Under the FCA and PRA regimes and, for in-scope firms, DORA, resilience is measured against Important Business Services and impact tolerances, not against application uptime. The vendor estate has to be mapped and governed accordingly.

1. 01

   Start from Important Business Services, not from systems

   Resilience testing that begins with an application list ends with an application list. Start instead from the Important Business Services the firm has declared, then trace each service through the technology, people and third parties that deliver it. The map, not the inventory, is what regulators and boards can act on.

2. 02

   Set impact tolerances the business can actually defend

   An impact tolerance is a statement of the maximum tolerable disruption to an Important Business Service, expressed in terms customers and regulators recognise. It has to be owned by the business, not inherited from a vendor SLA. Vendor SLAs then have to be assessed against the tolerance, not the other way round.

3. 03

   Reconcile vendor SLAs, DR commitments and your own RTOs

   Contracted availability, recovery time objective and recovery point objective from each material third party should be laid alongside the internal RTO and RPO for every Important Business Service they support. Gaps are not a procurement issue, they are a resilience issue, and they belong on the risk committee agenda with a named owner.

4. 04

   Rehearse severe but plausible scenarios end to end

   DORA and the FCA both expect scenario testing that goes beyond a single failed component. Rehearse the loss of a critical vendor, a regional cloud outage or a ransomware event against a full Important Business Service, including customer communications, regulator notification and manual workarounds. The gaps that show up in a rehearsal are the ones that would show up in a real incident.

5. 05

   Make incident response a single, testable framework

   One incident classification, one command structure, one communication protocol, whether the incident starts in a core system, a payment rail or a fourth-party dependency. Rehearse it, measure it and publish the learning. A framework that only lives in a policy document will not survive the first real event.