TPRM under DORA – The 5 Most Common Mistakes in Classifying ICT Services

With the Digital Operational Resilience Act (DORA), financial institutions are required to significantly strengthen their outsourcing and Third Party Risk Management (TPRM) for ICT services and to align it more closely with functions such as Information Security and Business Continuity Management (BCM).

According to DORA, ICT services include all digital or data services provided over the internet or electronic communication networks, as well as data center services offering computing, storage, or network resources. These services must be identified, documented, and assessed for criticality.

The measure of criticality depends on the business function supported. Every ICT service supports an internal business process or sub-function. If an ICT service supports a critical business function, much stricter regulatory requirements apply.

In supervisory practice, the same patterns of mistakes are observed time and again. Here are the five most common mistakes in classifying ICT services:

1. ICT services are considered only as software

Many institutions reduce ICT services to pure software products. Yet software development, DevOps, and IT services are also ICT services.
For a financial institution, the failure of a DevSecOps team can cause the same level of disruption as the failure of the software itself.
Implication: Development services and external IT personnel must also be included in risk management.

2. Classification based only on protection needs or BIA

Institutions often rely on CIA values or Business Impact Analyses (BIA).
If an application shows low protection needs, it is wrongly excluded as an ICT service.
Example: A SaaS tool with low protection requirements is still an ICT service and must be listed in the register.
Key point: DORA defines ICT services independently of protection needs or time criticality.

3. Software licenses are excluded across the board

A common mistake: assuming that licenses = not an ICT service.

• Pure usage rights (e.g., purchase of a perpetual license without service) are indeed not an ICT service.
• However: As soon as support, maintenance, or operation is included, it qualifies as an ICT service.
  Important: The duration of a service ≠ the term of a license.

4. Critical functions are misdefined

Functions are often classified as critical or non-critical solely based on BIA results.
Another flawed approach: a function is only deemed critical if all risk indicators are at the highest level (e.g., SBA = high, BIA = high, OCIR = critical).
This leads to the misclassification of functions with low protection needs but high BIA or OCIR values — even though they can clearly qualify as critical under DORA.

5. Misattribution of supporting services

Institutions often fail to properly assess whether an ICT service actually supports a critical function:

• Some mark almost everything as “supporting” (overreporting).
• Others miss genuine dependencies (dangerous blind spots).

The key question is:
Could the critical function continue to operate without this ICT service — yes or no?

Conclusion

The classification of ICT services is the central lever for a DORA-compliant TPRM.
The biggest mistakes stem from definitions that are too narrow, inappropriate criteria, and unclear dependency mapping.
Only precise classification establishes the foundation for a complete information register and reliable risk analyses — and helps avoid painful findings in the next supervisory review.

Do you need consulting or software to make sure these mistakes don’t happen in your organization? Get in touch with us.

‍