Almost every obligation in DORA is scoped by a single classification: is this function critical or important, or not?
The Register of Information covers providers supporting critical or important functions. The first step of incident classification asks whether a critical service was affected. Resilience testing is scoped against them. The strict contract requirements in Article 30(3) apply to them. Exit strategies and the subcontracting rules are triggered by them.
Get the classification wrong, and everything downstream is wrong with it. Classify too little as critical and your register, testing programme and contracts are under-scoped. Classify everything as critical and you have made the word meaningless, and made every obligation apply everywhere. Both versions show up in inspections.
What the definition actually says
DORA defines a critical or important function as one whose disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services and activities. A function also qualifies if discontinued or defective performance would materially impair your continuing compliance with the conditions of your authorisation or your other regulatory obligations.
Note what the definition is about: functions, not systems. Payment processing is a function. The core banking platform is a system that supports it. The classification starts from what you do for clients and regulators, then maps down to the technology. Many firms do it the other way around, walk their system inventory and label systems critical, and end up unable to answer the question supervisors actually ask: which business functions does this incident, this provider, or this test touch?
The mapping duty in Article 8
Article 8 requires you to identify, classify and document your ICT-supported business functions, the roles and responsibilities behind them, the information and ICT assets supporting them, and their dependencies on ICT third-party providers. The mapping must be reviewed at least yearly and whenever something changes materially.
That last sentence is the part firms forget. A CIF register from the 2024 implementation project that nobody has touched since is not a mapping. It is a snapshot of a company that no longer exists.
The mapping runs from functions down to the ICT assets that support them, each with criticality, health and recovery capabilities. One register, one answer.
Where the BIA comes in
The definition says "materially impair". The mapping duty says "classify". Neither tells you where the line goes. That is the job of the business impact analysis.
A BIA takes each function and asks what actually happens when it stops:
- Financial impact. Lost revenue, direct costs, potential claims.
- Client and service impact. How many clients are affected, how visibly, how fast.
- Regulatory impact. Which obligations you breach, and when the duty to notify kicks in.
- Recovery. How hard the function is to restore, and what it depends on.
Then it adds the time dimension: the maximum tolerable period of disruption (MTPD), the recovery time objective (RTO) you commit to, and the recovery point objective (RPO) for data loss. A function you can lose for a week is a different animal from one where two hours triggers the major incident thresholds.
Score the impact dimensions, set the time objectives, and the classification falls out of the analysis. That is the whole point: critical or important stops being an opinion held in a workshop and becomes a conclusion you can show, with the numbers behind it.
The BIA review step: impact scored per criterion, MTPD, RTO and RPO set for the process, and a gap analysis showing whether the supporting assets can actually deliver the recovery the business needs.
💡 Start from the outside in. The fastest test for a candidate function: if it stopped for a day, would you have to call the regulator, or would your clients notice before you did? If either answer is yes, run the full BIA on it. If both answers are no, that is worth documenting too, because the functions you decided are NOT critical need evidence behind them as well.
Common mistakes worth avoiding
- Classifying systems instead of functions, and losing the thread from client impact to technology.
- Letting "important" quietly mean "important to us" rather than the regulatory definition.
- Running the BIA once and never revisiting MTPD and RTO as the business changes.
- Keeping the BIA in a spreadsheet disconnected from the asset register, the provider register and the Register of Information, so three sources give three answers about the same function.
How DORA GRC helps
In DORA GRC, the CIF register and the BIA are the same workflow. Each function is scored across the four impact dimensions, MTPD, RTO and RPO are set per function, and the criticality tier is calculated from the scores rather than picked from a dropdown. Functions link to the ICT assets and providers that support them, so the dependency map, the Register of Information and the testing scope all read from one classification. When the supervisor asks why a function is, or is not, critical, the answer is the analysis itself.
Sources: Regulation (EU) 2022/2554 (DORA), Articles 3(22), 8, 28 and 30. Commission Delegated Regulation (EU) 2024/1772 on incident classification. ESAs materials on the Register of Information and scoping of critical or important functions.