DORA Critical or Important Function: How to Classify It

Q: What is a "critical or important function" under DORA?

Under DORA Article 3(22), a critical or important function is any activity, service, or process whose disruption would seriously impair a financial entity's financial performance, the soundness or continuity of its regulated activities, or its ability to meet the conditions of its authorisation.

Q: Who decides whether a function is critical or important?

The financial entity itself makes the determination. DORA does not publish a fixed list of critical or important functions; each entity applies the statutory Article 3(22) test and the EBA's supporting factors to its own business model and documents how it reached its conclusion.

Q: Does DORA provide a fixed list of critical or important functions?

No. DORA does not publish a fixed list. It is a principles-based, case-by-case test, and the same function can be critical for one entity and non-critical for another depending on how central it is to that entity's licensed activities.

Q: What changes once a function is classified as critical or important?

Once a function is classified as critical or important, its ICT contract must include the stricter Article 30 clauses, it needs a documented exit strategy, any subcontracting gets extra scrutiny, it is flagged in the register of information, it can fall within resilience-testing scope, and the entity must notify its competent authority.

Q: Do small and non-interconnected firms still need to do this assessment?

Yes. Proportionality under DORA, including the relief available to small and non-interconnected investment firms, scales how deeply the ICT risk-management framework is built out, but it does not remove the duty to identify which functions are critical or important.

Q: How often should the classification be reviewed?

The classification should be reviewed whenever something changes it, not only on a fixed calendar date. A new system going live, a provider change, growing transaction volumes, or a restructuring of regulated activities are all reasons to revisit the call.

DORA does not treat every ICT-supported activity the same way. Whether a service, process, or activity counts as a critical or important function (CIF) under Article 3(22) decides which obligations apply to it: the stricter Article 30 contract clauses, a mandatory exit strategy, resilience-testing scope, and a duty to notify your competent authority. The call is the financial entity's own to make, and regulators expect it documented, not asserted.

What counts as a critical or important function

Article 3(22) defines a critical or important function as any activity, service, or process whose disruption would seriously impair a financial entity's financial performance, the soundness or continuity of its regulated activities, or its ability to comply with the conditions of its authorisation. That is a principles-based test, not a checklist: DORA does not publish a fixed list of qualifying activities, because the same function, say, payment processing or core banking, can be critical for one firm and a minor convenience for another, depending on how central it is to that entity's licensed business.

The European Banking Authority's Q&A on the point sets out how supervisors expect entities to reason through it: a case-by-case assessment weighing whether the function is essential to delivering the entity's core, licensed services, its potential impact on clients, market functioning, or financial stability if it failed, and how readily it could be substituted by another provider or brought back in-house. None of those factors is decisive alone; the assessment weighs them together against the entity's own business model.

The RTS that shapes the policy behind it

Article 28(10) required the European Supervisory Authorities to specify, in regulatory technical standards, the detailed content financial entities must put in their policy on ICT services supporting critical or important functions. The result, Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024, has applied, along with the rest of DORA, since 17 January 2025. It requires the policy to cover the due-diligence criteria used before contracting, how the entity assesses concentration risk across its ICT arrangements, and how it monitors performance and risk once a contract is signed, not only the CIF determination itself. A register of information entry that supports a critical or important function is a different, more scrutinised record than one that does not, and the policy this RTS describes is what a supervisor expects to see behind that flag.

Why the classification cascades through the rest of DORA

Getting the CIF call right matters because almost nothing else in the third-party risk pillar treats critical and non-critical arrangements alike:

Contract terms. Article 30 sets a baseline of mandatory clauses for every ICT contract, but arrangements supporting a CIF face a stricter tier: audit and access rights, service-level targets, termination rights, and cooperation during incidents, all with more teeth. Our Article 30 contractual provisions checklist walks through the full list.
Exit strategy. An exit strategy covering transition to an alternative provider or back in-house is required specifically where the arrangement supports a CIF.
Subcontracting scrutiny. Where a CIF-supporting service can be subcontracted at all, Commission Delegated Regulation (EU) 2025/532 requires a formal risk assessment of the sub-provider before it happens, not after.
Notification to your competent authority. Article 28(3) requires financial entities to inform their competent authority in good time about a planned contractual arrangement supporting a CIF, and again if an existing function later becomes critical or important.
Resilience-testing scope. ICT systems supporting critical or important functions are the ones threat-led penetration testing and the wider testing programme are built around.
Register of information. The register of information must flag which arrangements support a CIF, since those entries draw closer supervisory attention than the rest of the register.

A practical classification checklist

Inventory the activity, not the contract. Start from what the function actually does for the business (payments processing, trade execution, core banking, client onboarding), not from a vendor name. One provider can support several functions, only some of which are critical.
Apply the statutory test first. Would disruption seriously impair financial performance, the soundness or continuity of regulated activities, or compliance with authorisation conditions? If the answer is a clear no, document why and move on.
Weigh the EBA's supporting factors where the answer is not obvious. Is the function essential to a licensed, core service? What is the realistic impact on clients or market functioning if it fails? How substitutable is the provider, and on what timeline?
Write down the reasoning, not just the conclusion. Supervisors expect to see the criteria applied and the evidence weighed, not a bare "critical: yes/no" tag. A one-paragraph rationale per function is usually enough.
Flag it in the register of information. Use our TPP register generator to keep the CIF flag, the underlying reasoning, and the linked contract in one place.
Set a review trigger, not just a review date. A function's status can change when trading volumes, client numbers, or the entity's operating model shift, not only on a fixed annual cycle.

Common mistakes we see

Treating the vendor as the unit of analysis. A cloud provider that hosts both a critical trading system and a non-essential marketing site supports one CIF-relevant arrangement and one that is not; lumping both under the same classification either over- or under-scopes obligations.
Assuming small-firm relief means skipping the assessment. Small and non-interconnected investment firms get a simplified ICT risk-management framework, not an exemption from identifying which of their functions are critical or important; the simplification applies to how deeply the framework is built out, not to whether the CIF test gets done.
Leaving the assessment static after go-live. A function that started as a minor pilot can become critical once it carries real client volume; the documented rationale should be revisited when that happens, not only when a supervisor asks.
Under-documenting borderline calls. The functions worth writing the most about are the close ones, not the obvious "yes, this is our core banking platform" cases.

Keeping the assessment current

DORA expects the CIF list to move with the business, not sit in a folder from the first assessment round. Reassess when a new system goes live, when an existing arrangement's scope expands, when a provider is replaced, or when the entity restructures its regulated activities. A DORA Readiness Score assessment is a useful way to confirm your ICT third-party risk documentation, including your CIF methodology, is where it needs to be before a supervisor asks to see it.

Frequently asked questions

What is a "critical or important function" under DORA?

Under Article 3(22), it is any activity, service, or process whose disruption would seriously impair a financial entity's financial performance, the soundness or continuity of its regulated activities, or its ability to meet the conditions of its authorisation.

Who decides whether a function is critical or important?

The financial entity itself. DORA does not publish a fixed list; each entity applies the statutory test and the EBA's supporting factors to its own business model and must document how it reached its conclusion.

Does DORA provide a fixed list of critical or important functions?

No. It is a principles-based, case-by-case test. The same function can be critical for one entity and non-critical for another depending on how central it is to that entity's licensed activities.

What changes once a function is classified as critical or important?

Its ICT contract must include the stricter Article 30 clauses, it needs a documented exit strategy, any subcontracting gets extra scrutiny, it is flagged in the register of information, it can fall within resilience-testing scope, and the entity must notify its competent authority.

Do small and non-interconnected firms still need to do this assessment?

Yes. Proportionality under DORA scales how deeply the ICT risk-management framework is built out; it does not remove the duty to identify which functions are critical or important.

How often should the classification be reviewed?

Whenever something changes it, not only on a fixed calendar date: a new system going live, a provider change, growing transaction volumes, or a restructuring of regulated activities are all reasons to revisit the call.

Sources

Regulation (EU) 2022/2554 (DORA), Articles 3(22), 28, and 30, EUR-Lex.
European Commission, Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024, EUR-Lex.
European Banking Authority, DORA006: Q&A on ICT services supporting critical or important functions.

Last updated: 28 September 2026.