One of the open questions under Regulation 2022/2554 on digital operational resilience for the financial sector (DORA) has been how it applies to financial entities that, alongside regulated financial services, also carry on non-regulated activities.
The tension is obvious: on the one hand, DORA is clearly aimed at the financial activities of in-scope entities; on the other hand, Article 2(1) of DORA defines the scope in entity terms – by listing types of institutions – rather than by reference to specific regulated services.
A more cautious reading so far has been that once an entity is in scope, all of its activities and ICT systems, protocols and tools are in scope as well, including non-financial lines of business.
The point is taken up in EIOPA’s recent Q&A 136-3193. The question put to EIOPA was essentially whether, where an entity carries on both “DORA-regulated activities” and other non-regulated activities, DORA also applies to those non-regulated activities.
In its answer, EIOPA confirms first that DORA indeed defines its scope by reference to entities, not individual activities or services. As a default rule, the entity as a whole is subject to DORA. In practice, this means that, where ICT systems, services or processes are shared between the regulated and non-regulated activities, DORA obligations extend to both.
Crucially, however, EIOPA then adds a limitation: where ICT environments are fully segregated and contagion risks are effectively prevented, the non-regulated activities supported by such environments fall outside the scope of DORA.
This is important. It cuts against a strictly literal, purely entity-wide reading and shows that, in certain cases, a financial entity that is in scope of DORA does not need to ensure DORA compliance for every part of its ICT environment, provided that environment is truly segregated and does not create contagion risk for the financial activities.
EIOPA relies here on the concept of an “ICT environment”, a term which does not appear in DORA itself (and, although it is used in Delegated Regulation 2024/1774, it remains undefined there as well). There are, however, good arguments to interpret this notion as encompassing not only internal ICT assets, systems and processes, but also the external layer of ICT services.
If this view is accepted, it also has consequences for Chapter V of DORA (managing ICT third-party risk). Where a third-party service provider delivers ICT services to a financial entity exclusively in relation to non-regulated activities – and, under the conditions identified by EIOPA (effective segregation and no contagion risk), those services do not support the provision of any DORA-regulated activities – there is a good argument that DORA obligations should not be triggered for that relationship. In such a case, the financial entity would not need to include information on this contractual arrangement in the DORA register of information, nor ensure the inclusion of the specific contractual clauses described in Chapter V of DORA in relation to that arrangement.
This is, admittedly, an interpretative step beyond the literal wording of DORA and the Q&A itself. However, it is consistent with EIOPA’s logic: the scope remains entity-based as a rule, but functional and architectural differentiation can be recognised where the conditions of full segregation and absence of contagion risk are met.
For financial entities, Q&A 136-3193 is therefore a broadly positive development. It confirms that DORA is not an all-or-nothing, “once in scope then everything is in scope” regime – provided that ICT architecture and vendor landscapes are designed, documented and operated in a way that makes such segregation and risk separation defensible.
