Outsourcing Incident Responsibilities

Outsourcing incident responsibilities describe who does what when a service supported by a provider is disrupted. The firm keeps responsibility for the service, for decisions about its customers, and for any regulatory notification that follows, while the provider is responsible for the parts of the system it operates and for the information and actions only it can supply. DORA's provisions on ICT incident management and on ICT third party risk bring those responsibilities together: the firm needs a process that can detect, classify, and respond to an incident involving a provider, and provider arrangements that support that process with timely information and cooperation. If those responsibilities are first clarified during a live incident, the incident will be managed by improvisation, and the record of what happened will be reconstructed afterwards.

Notification is the first point where provider arrangements often fail. A provider may detect a problem in its platform before the firm sees any effect on its service, or the firm may see service degradation before the provider acknowledges a platform issue. Either way, the firm needs a defined route, a named contact, and an agreed level of detail, so that it learns about the problem, its scope, and its likely effect on the service without waiting for a public status update. A status page alone is rarely enough, because it describes a platform in general terms while the firm needs to know about a specific service, its users, and its data. Notification terms should therefore cover what triggers a notice, what it contains, and how updates will follow as understanding develops.

Decision making during an incident needs similar clarity. The firm decides about its service: whether to pause a function, to use a workaround, to communicate with customers, or to invoke a recovery step. The provider decides about its platform: how to restore its component, in what order, and with what risk. Those decisions interact, because a provider recovery step can affect the firm's service, and a firm workaround can affect the provider's recovery. A joint incident process, with defined roles and a shared understanding of the service, helps those decisions align. Without it, each side may act reasonably from its own perspective while producing a combined outcome that harms the service, such as restoring a component before dependent data is ready.

A retail banking illustration makes the interaction concrete. Suppose a hosted authentication service degrades, so that some customers cannot log in while others can. The provider sees a platform pattern across many clients. The firm sees a service pattern for its own customers, including which journeys fail and which customer groups are affected. Recovery needs both pictures: the provider fixing the platform cause, and the firm judging whether its service can be restored safely, whether a workaround is appropriate, and what customers should be told. If the firm waits passively for provider resolution, it surrenders decisions that belong to it. If the provider acts without firm context, it may restore a platform without restoring the firm's service experience. Joint working, rehearsed in advance, avoids both failures.

Evidence gathering during an incident is easily lost when provider and firm processes run separately. Timestamps, logs, decisions, and communications need to be captured in a form that can later be reconciled into a single account of the incident, including what the provider did, what the firm did, and why. Contract terms on log retention, access, and cooperation after an incident support that reconciliation, as does a habit of recording firm decisions contemporaneously rather than reconstructing them later. The resulting record supports incident classification, regulatory notification where required, root cause work, and the lessons process. It also protects both parties, because a dispute about what happened can otherwise turn on incomplete or incompatible records.

Lessons after an incident close the loop, and provider involvement is essential to that stage. A firm-side lesson that ignores a provider cause will not prevent recurrence, while a provider-side fix that ignores firm service design may leave the service exposed in a different way. A joint review should therefore examine the provider failure, the firm service design, the detection and notification path, the recovery sequence, and the communication with customers, and should produce owned actions with dates. Those actions need to be tracked through governance, not merely noted in a review document. An incident that produces no change to a contract, a design, a test, or a process has been recorded but not learned from, and the same dependency may fail in the same way again.