Critical or important function: the determination that triples your obligations

The definition, and what it is actually measuring

Article 3, point (22) of Regulation (EU) 2022/2554 defines a critical or important function as follows.

a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law

Read it twice, because the grammar carries the meaning. Every clause of that sentence is about a financial entity. Nothing in it refers to the supplier, the product, the contract value or the technology. The subject of the test is the customer’s function, and the question is what happens to the customer if that function stops working.

There are two independent limbs. The first is an impairment limb: material impairment of the entity’s financial performance, or of the soundness or continuity of its services and activities. The second is an authorisation limb: material impairment of the entity’s continuing compliance with the conditions of its authorisation or with its other obligations under financial services law. Either one is enough. The second limb is the one suppliers underestimate, because a service can be commercially small and still sit inside a licensed activity.

Recital 70 extends the phrase sideways. The definition “encompasses the ‘critical functions’ as defined in Article 2(1), point (35), of Directive 2014/59/EU”, the bank recovery and resolution directive. Functions the entity has identified as critical for resolution purposes are therefore critical for DORA purposes as well, which means a supplier can be pulled into the classification through a resolution plan it has never seen.

Who makes the determination

The financial entity, before it contracts. Article 28(4) is explicit: before entering into a contractual arrangement on the use of ICT services, financial entities shall “assess whether the contractual arrangement covers the use of ICT services supporting a critical or important function”. That assessment sits inside the entity’s ICT risk management framework, under the responsibility of its management body, and it is one of five pre-contract steps that also cover supervisory conditions, concentration risk, due diligence and conflicts of interest.

Nothing in the Regulation gives the supplier a role. You can supply facts, you can point out that your service handles reporting rather than execution, and you can ask which limb of the definition the entity thinks you meet. You cannot classify your own service, and a term in the contract purporting to do so does not bind the supervisor.

Why it changes the contract by a factor you can feel

A paragraph 2 contract asks you to describe the service, state your locations, protect the data, return it on exit, publish service levels, help during incidents at a pre-agreed price, cooperate with authorities, agree termination terms, and set out the conditions on which your staff join the customer’s training. Almost all of that is documentation you should have anyway.

A paragraph 3 contract adds obligations with a delivery cost attached. Quantitative performance targets need telemetry and a measurement method. Material-change notification needs an internal trigger process. Contingency plans have to be tested, not written. Participation in a threat-led penetration test consumes engineering time across an exercise whose active phase alone runs at least twelve weeks. Unrestricted audit rights mean on-site visits by the customer, its appointee and its supervisor, at a frequency the customer pre-determines. And the exit strategy obliges you to keep serving a customer that has already left, for as long as its migration takes.

Signals that the answer will be yes

No supervisor publishes a checklist, and the definition is deliberately outcome-based. In practice a handful of signals are reliable, and most of them are visible to the supplier before the customer says anything.

• Your service sits inside a licensed activity. Payments initiation, order routing, custody records, claims handling, regulatory reporting. The second limb of Article 3(22) is about continuing compliance with the conditions of authorisation, and anything in the licensed path engages it.
• An outage stops customer-facing service. Core banking, authentication, the mobile channel, the payment rail. This is the first limb, straightforwardly.
• There is no ready substitute. Substitutability is one of the criteria the ESAs used when designating critical providers under Article 31(2), and supervisors apply the same instinct to contracts one level down. A bespoke integration with a two-year replacement path is not substitutable in any meaningful sense.
• The customer has asked for an exit plan. Article 28(8) requires exit strategies for ICT services supporting critical or important functions. If the questionnaire asks how the customer would leave you and how the transition would be tested, the classification has already been made.
• The draft contains audit or TLPT clauses. Both live only in Article 30(3). Their presence in the draft is your customer telling you the answer before it says so.
• You appear in resolution planning conversations. Recital 70 pulls the Directive 2014/59/EU definition of critical functions into DORA, and resolution-relevant services follow it in.

The counter-signals are weaker than suppliers hope. A low contract value does not help, because the test is impairment at the customer, not spend. Nor does the fact that the service is internal-facing: an HR or reporting system can impair continuing compliance with an authorisation obligation just as effectively as a customer-facing one.

The classification is not fixed at signature

Article 28(3) requires the financial entity to inform its competent authority in a timely manner about any planned contractual arrangement covering critical or important functions “as well as when a function has become critical or important”. The classification is therefore a live value that can move in one direction during the life of your contract, typically because the customer has migrated more of its business onto your service than it originally planned.

That has a practical consequence for drafting. A contract that says nothing about reclassification leaves you exposed to a unilateral upgrade in obligations without a corresponding change in price. Ask for a change-control mechanism: if the customer reclassifies the service, the paragraph 3 clauses come into effect on a stated date, and the commercial terms are reopened at the same time. Most customers accept this, because the alternative for them is a supplier that resists the reclassification they are obliged to make.

The same logic runs the other way. If the customer retires the function or moves it elsewhere, the paragraph 3 obligations should fall away rather than persisting because nobody updated the schedule.

How to argue it, without pretending you decide

Arguing the classification is legitimate, and supplying accurate facts is helpful to a customer that has to defend the assessment to its supervisor. Arguing it badly, by asserting that your service is not important, is worse than saying nothing.

1. Ask which limb of Article 3(22) the entity considers engaged: financial performance and service continuity, or continuing compliance with its authorisation. The answer tells you what the customer thinks you do.
2. Describe the function boundary accurately. If your product supports a critical function through one module and non-critical reporting through the rest, say so and offer to split the arrangement. A narrower critical scope is easier to serve than a blanket one.
3. Supply substitutability facts rather than opinions: standard data formats, export tooling, documented interfaces, an existing customer who has migrated away and how long it took.
4. If the answer is yes, stop arguing and start pricing. A supplier that accepts the classification and quotes the transition period, the audit programme and the testing support as line items reads as competent. One that litigates the definition reads as a risk.

If the answer is no, ask for it in writing, and then check the draft against it. Six specific clauses have no basis in Article 30 on a non-critical contract, and it is entirely fair to say which article you are relying on when you strike them. The addendum guide sets out the full fifteen-element list and the order to negotiate them in.

What follows a yes

Three workstreams start at once, and none of them is a legal task.

• Testing. Article 30(3)(d) puts TLPT participation in the contract, and Delegated Regulation (EU) 2025/1190 sets an active red team phase of at least twelve weeks. What that involves is a guide of its own.
• Assurance. Article 30(3)(e) grants unrestricted access, inspection and audit, and Delegated Regulation (EU) 2024/1773, Article 8(3), stops your customer relying on your certificate alone. The audit and evidence guide covers what to prepare.
• Continuity and exit. Article 30(3)(c) requires implemented and tested business contingency plans; Article 30(3)(f) requires a transition period you keep serving through; Delegated Regulation (EU) 2024/1773, Article 10, requires your customer’s exit plan itself to be tested. Rehearse the migration before someone asks you to evidence it.

All three are cheaper to build once, deliberately, than to improvise separately for every financial customer you acquire. That is the real argument for treating the first critical-function classification as a programme rather than as a contract review.