A critical or important function under DORA is any business function whose disruption would materially hurt your financial performance, break the continuity of your services, or put your authorisation and other regulatory obligations at risk. It is a consequence-based test applied to a function, not to a system or a vendor, and your firm (not the regulator) has to make the call.
Why this definition matters more than it looks
Article 3(22) of Regulation (EU) 2022/2554 (DORA) defines a "critical or important function" (CIF) as a function whose disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services and activities, or whose discontinued, defective or failed performance would materially impair continuing compliance with the conditions of its authorisation, or with other obligations under applicable financial services law.
Three things fall out of that wording and they change how you should run the exercise:
- It is a functional test, not a technology test. "Our core banking platform" is not a function, "processing client payments" or "executing card transactions" is. Assess the business capability, then trace which systems and providers support it.
- It is assessed before mitigation. The fact that you have a backup data centre or a failover provider does not make a function non-critical. Criticality is about the consequence of failure, not about how well you currently manage that risk.
- It only takes one limb. A function can qualify through financial impact alone, through continuity alone, or through authorisation compliance alone. You do not need to tick all three.
The European Supervisory Authorities (EBA, EIOPA, ESMA) have been clear, including in published Q&A guidance, that there is no official EU-wide list of critical or important functions. Each financial entity, EMI or payment institution included, has to perform its own case-by-case assessment based on the nature, scale and complexity of its activities. For an EMI that usually means payment initiation, account issuance and management, safeguarding of client funds, AML/transaction monitoring, and whichever card or SEPA rails you rely on to settle. If disrupting one of those would mean customers cannot move money, revenue stops, or you breach a safeguarding or reporting obligation, it is a CIF.
Documenting the determination so it survives scrutiny
A defensible CIF determination needs a visible method, not a gut call that lives in someone's head. In practice that means:
- A function inventory at the business-capability level (not a systems list), each one mapped to the ICT services and third parties that support it.
- A scoring framework tied directly to the three Article 3(22) limbs: expected financial loss or revenue at risk per hour of disruption, number of customers and severity of impact on continuity, and whether prolonged failure would breach a licence condition or another legal obligation.
- A record of who made the call, on what evidence, and when it was reviewed. Supervisors expect this to be a living inventory, reviewed at least annually and whenever your service footprint changes materially.
- Clear consequences once a function is flagged critical: it drives tighter contractual terms with the provider (DORA Article 30), it widens the subcontracting chain you must track, and it raises the bar for incident classification, since impact on a CIF is itself one of the criteria for classifying a major ICT incident.
The Register of Information, and how it differs from (and reuses) your vendor register
DORA Article 28(3) requires financial entities to maintain, and keep updated, a register of information covering all contractual arrangements with ICT third-party service providers, at entity, sub-consolidated and consolidated level. This is not a free-form spreadsheet. The European Commission adopted standardised templates through an Implementing Technical Standard proposed by the ESAs, and firms report against those templates in a structured, machine-readable format rather than prose.
The obligation is annual and runs through your competent authority: you submit your register to your national regulator (for example the CSSF in Luxembourg, the Central Bank of Ireland, or the AFM in the Netherlands), who performs quality checks and forwards the data to the ESAs. The ESAs use the aggregated registers to designate Critical ICT Third-Party Providers (CTPPs) for EU-level oversight. National authorities set their own submission windows each year and have been running dry-run and live reporting cycles since the regulation became applicable, so check your regulator's current guidance for the exact window rather than assuming a fixed date.
The practical trap for EMIs is treating this as a brand-new project when most of the raw material already exists. If you have already built a vendor register under Article 28's broader due-diligence obligations (we covered that groundwork in our guide to DORA Article 28 vendor registers for EMIs), the Register of Information is not a parallel exercise, it is a reformatting and enrichment of the same underlying data. A practical sequence:
- Start from your existing vendor/contract inventory rather than rebuilding it. Pull provider identity, contract dates, services provided, and criticality flags you already hold.
- Overlay the CIF determination from the step above: for each contractual arrangement, tag which business function it supports and whether that function is critical or important.
- For arrangements supporting a CIF, extend the mapping down the chain: record subcontractors genuinely relied on to deliver the service, not every vendor your provider happens to use.
- Convert the enriched inventory into the standardised template structure (entity, contractual arrangement, ICT service, provider, and function-criticality fields) and run it through the data-quality checks published alongside the templates before your submission window opens.
- Assign an owner for annual refresh. This is a recurring filing, not a one-off deliverable, and your competent authority will expect updates to reflect new contracts, terminated ones, and changed criticality assessments.
If you are still mapping your core obligations under the regulation, our DORA compliance overview walks through how the pieces fit together for EMIs and PIs. Get in touch at team@novafin.co or through that page if you want help turning your vendor data into a filing-ready register.