Why the Criticality of a Business Function is Not a "Yes/No Question"

A Plea for Risk-Oriented Assessment in the Spirit of DORA

Since the first draft of the DORA (Digital Operational Resilience Act), many financial institutions have been facing the same question:

"Which of my business functions are critical?"

What sounds simple initially has developed in practice into a patchwork of completely different methods. Every institution uses its own approaches, criteria, and assessment logic. Uncertainty is high - and the question remains: "Which method is correct?"

The short answer is: none is inherently right or wrong. The long answer: The topic must be approached systematically. And that is exactly what we will look at.
‍
1. Why DORA Breaks the Classic Yes/No Logic

DORA does not merely require institutions to manage digital risks. It also demands that relevant risks be systematically identified and subsequently assessed appropriately. Based on this, institutions should set risk-oriented priorities. The focus is therefore not on ticking off a list of critical functions. It is about understanding which processes carry substantial risks.

This automatically leads to the following conclusion: Criticality is a binary feature, but the path to it is by no means binary.

2. The Core: Critical Functions = Functions with Critical Risks

In many interpretations, the first question asked was: "Which processes feel critical?" Let us reverse the logic: "Which risks of which processes are critical?"

A process becomes critical, therefore, not because it sounds inherently important, but because:

• a large financial loss occurs in case of an outage,
• essential regulatory requirements could be violated,
• the business operation would be seriously impaired.

Even though DORA names three categories, others can be added or these can be broken down into sub-categories.

3. A Scale, Not a Switch

A central misunderstanding in practice is the use of yes/no criteria. Yet, risks have manifestations, severity grades, and probabilities of occurrence. A usable assessment model must therefore ask: "How high would the damage be if...?"

Examples:

• If the process is unavailable for several hours
• If data is compromised
• If regulatory deadlines are not met
• If customers cannot be served

This inevitably leads to a scaling like e.g. numerically (1–5, 1–10, etc.).

Only such a scale creates the basis for true comparability, ensures consistent assessments, enables clear prioritization, and makes the results traceable.

4. The Threshold: Where Does "Critical" Begin?

DORA requires institutions to concentrate on material risks. But what is material differs from company to company. Why? Because risk appetite is individual. For one institution, a damage amount of one million Euros is already significantly outside its own risk tolerance, while another still considers this limit to be quite bearable. Some institutions are also heavily dependent on digital services, while others have robust manual alternatives that can better cushion outages. There is no uniform, objective threshold for criticality. But every company needs its own, internally consistent definition. Precisely this threshold ultimately forms the boundary between: "important, but not critical" and "critical in the sense of DORA."

 5. What Does This Mean in Practice?

The path to identifying critical functions thus consists of three steps:

Step 1: Analyse risks per process: Do not just describe activities, but assess the real risk burden.

Step 2: Scale the extent of the damage: No yes/no, but scaled assessment.

Step 3: Define a clear threshold: The point at which a risk is no longer acceptable to the institution.

Only then does a process become a critical business function (in the sense of DORA)

6. Why Harmonised Methods Are Necessary – But May Still Vary

Many institutions assume there must be a single correct method. However, DORA deliberately leaves room for manoeuvre to accommodate different business models, varying risk tolerances, and different assessment scalings. What is absolutely necessary, however, is a traceable methodology, uniform application within the institution, documented logic, and a consistent risk assessment. Standardised internally, but not necessarily identical to the neighbour.‍

Conclusion: Criticality is Relative – and Never Binary

The question "Is a business function critical: yes or no?" falls far too short. Criticality is the result of a risk-based derivation that requires scalable risk assessments, realistic damage estimates, the definition of risk appetites, and the setting of clear thresholds for factual, measurable, and DORA-compliant identification. Only through this does the identification of critical business functions become factual, measurable, and DORA-compliant.

‍