Third-Party Incident Notification

Third-party incident notification under DORA concerns what happens when an incident at a provider affects a financial entity's service. The provider may detect the incident first, but the consequences fall on the entity's customers and operations, and the entity's own incident duties remain its own. The arrangement therefore needs clear roles, agreed contact routes, timely and usable information from the provider, and joint working until the service is restored. A notification that arrives late, in vague terms, or through the wrong channel can delay the entity's response more than the underlying technical failure itself.

A payment gateway illustration answers the question plainly. Customers experience a payments failure, not a gateway failure, and they look to the financial entity for an explanation and a remedy. The entity cannot transfer its responsibility for the service by pointing to its provider, even though the provider caused the interruption. That is why contract terms and incident plans treat provider incidents as entity incidents from the outset, with the provider's role defined as support and cooperation. The distinction matters for accountability: the provider explains its failure, while the entity explains the impact on its service and what it is doing about it.

The entity needs information it can act on, not a general assurance that an issue is being worked on. Useful information includes which service and data are affected, the nature of the disruption in terms the entity can translate for customers and internal teams, what the provider is doing, and when further updates will arrive. Early information will inevitably be incomplete, and that is acceptable if incompleteness is stated openly and updates follow a predictable rhythm. Information that pretends to certainty while the provider is still investigating is worse than an honest interim update, because it can lead the entity to make decisions on a false picture.

Roles and contact routes matter because incidents rarely occur during convenient hours or through normal account management channels. The entity needs named operational contacts at the provider, an escalation route when those contacts cannot resolve the issue, and clarity about who can authorise workarounds or data recovery. Those routes should be tested outside an incident, since a contact list that has not been checked may contain people who have left, numbers that no longer work, or a single point of contact who is unavailable. Joint exercises, even in discussion form, are a practical way to test whether the routes work before they are needed for real.

Restoration is not the end of the incident process. The entity and the provider should review what happened, what the provider's response revealed about monitoring and escalation, and whether contract terms, reporting or oversight need to change. Lessons may concern the provider, the entity's own response, or the interface between them, such as a notification delay or a gap in the service map. Recording those lessons and assigning follow-up actions prevents the same incident from recurring in the same form. An incident that produces no change to any plan, contract or register has been survived, but it has not yet been learned from.

Provider notification has limits that the entity should plan around. A provider serving many customers may prioritise its own recovery over tailored updates to each customer, and its first assessment may change as investigation proceeds. The entity therefore needs its own detection and monitoring, so that it is not wholly dependent on the provider to learn that its service is affected. Customer-facing communication, internal escalation and any regulatory notification remain the entity's responsibility, informed by provider information but not delegated to the provider. Planning for those limits in advance is what keeps a provider incident from becoming an entity communication failure as well.