The Cornerstone of DORA

What Is a Critical or Important Function (CIF) Under DORA?

Definition (Article 3(22)), identification criteria, step-by-step methodology, real-world examples — and how to automate CIF management with Resiplan. Every DORA obligation cascades from correctly identifying your CIFs.

Article 3(22) Regulation (EU) 2022/2554 12 min read Updated 2026
Official Definition · DORA Art. 3(22)

Legal Definition of a CIF

A "critical or important function" means a function, the disruption of which would:

Materially impair the financial performance of a financial entity, or
• Impair the soundness or continuity of its services and activities, or
• Whose discontinued, defective or failed performance 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. — Regulation (EU) 2022/2554 (DORA), Article 3, point 22

Why the CIF Concept Is the Cornerstone of DORA

DORA does not impose the same obligations on every function. Most requirements — and their intensity — cascade from whether a function is classified as "critical or important". Get CIF identification wrong, and every downstream obligation is wrong too.

Register of Information

Every ICT service supporting a CIF must be flagged in the RoI (ITS 2024/2956) with enhanced attributes.

RTS 2024/1773 →

Contractual Clauses

Stricter mandatory clauses apply to ICT providers supporting CIFs (audit, subcontracting, exit).

Third-Party Risk →

TLPT Scope

Threat-Led Penetration Tests must cover ICT systems supporting CIFs (DORA Art. 26).

TLPT Guide →

Incident Classification

Impact on CIFs is one of the 6 criteria triggering major incident reporting.

RTS 2024/1772 →

Subcontracting Rules

Max 2 cascading subcontracting levels allowed for ICT services supporting CIFs (RTS 2025/532).

RTS 2025/532 →

ICT Risk Framework

CIF inventory is an input to risk assessment, BCP/DRP, and resilience testing (DORA Art. 5-16).

RTS 2024/1774 →

How to Identify a CIF: The Two Dimensions

A function becomes a CIF when it meets the materiality threshold across a combination of quantitative and qualitative criteria. No single metric decides — it's a weighted assessment.

Quantitative Criteria

  • Revenue share — >5% of gross income typical threshold
  • Client base — number/percentage of active clients impacted
  • Transaction volume — value and count per day/month
  • Market share — concentration in a specific market segment
  • Asset under management — for investment services
  • Capital requirement — functions directly affecting Pillar 1 capital

Qualitative Criteria

  • Regulatory authorisation — required to maintain licence
  • Customer protection — direct impact on client funds/data
  • Reputation — media/market visibility of disruption
  • Substitutability — difficulty to replace internally/externally
  • Systemic impact — contagion risk to wider market
  • Interdependencies — upstream/downstream criticality chains

6-Step Methodology to Identify Your CIFs

A structured approach reviewed by EBA, EIOPA and ESMA in their joint Q&A on DORA.

Map all business functions

Build an exhaustive inventory of every function your financial entity performs — core services (payments, custody, underwriting), customer-facing processes, internal support (treasury, compliance, HR). Use your operating model or value chain as a starting point.

Resiplan ships with a pre-built function taxonomy by sector (banking, insurance, payments)

Apply quantitative scoring

For each function, collect measurable inputs: revenue contribution, client count, transaction volume, AUM. Define institution-specific thresholds (typical: 5% revenue, 10% clients, high-value transaction flows).

Resiplan auto-imports financial data and runs scoring against your thresholds

Apply qualitative assessment

Complement with non-numeric dimensions: regulatory impact (does this support your licence?), reputational exposure, substitutability, systemic implications. Workshop with business heads, legal, risk, compliance.

Resiplan workflow: multi-stakeholder scoring with evidence attachments

Combine and decide

Aggregate quantitative + qualitative scores. Apply your materiality threshold. Document every decision — especially borderline cases where you opted not to classify as CIF (supervisors will ask).

Resiplan produces an auditable CIF register with decision rationale

Link ICT services to CIFs

For every CIF, list the ICT services (internal + third-party) that support it. This data feeds the Register of Information (ITS 2024/2956) and drives which contracts need the stricter DORA clauses.

Resiplan auto-generates the RoI from CIF → ICT service mappings

Board approval and annual review

The management body (board) must formally approve the CIF list. Review at least annually, and whenever a material change occurs (new service, M&A, outsourcing). Keep the approval traceable for supervisors.

Resiplan sends review reminders and tracks board sign-off electronically

Real Examples: CIF vs Non-CIF

Illustrative examples across sectors — your actual classification depends on your specific business model and materiality thresholds.

Function Sector Typical Classification Why
Core banking / transaction processing Banking CIF Direct client impact, regulatory authorisation, systemic relevance
Payment initiation (SEPA, instant) Payments CIF High volume, customer-facing, regulated service
Claims management Insurance CIF Core to insurance obligations, direct client impact, Solvency II relevance
Custody / safekeeping of assets Investment firms CIF Client asset protection is a regulated activity
Regulatory reporting (COREP, FINREP) All CIF Failure = breach of authorisation conditions
AML / KYC screening All CIF Legal obligation, reputational and regulatory risk
HR payroll All Not CIF No direct impact on regulatory compliance or financial services
Marketing automation All Not CIF Disruption does not materially impair services
Internal corporate email All Not CIF Support function, substitutable, no regulatory dependency
Document management (contracts) All Depends Borderline — CIF if tied to regulatory archiving obligations
Our SaaS · CIF Automation

How Resiplan Automates Your CIF Management

Resiplan is the specialised SaaS for DORA, business continuity and GRC. Our CIF module turns a 4-hour workshop into a 15-minute guided workflow — with continuous tracking, board-ready reports, and automatic propagation to the Register of Information.

01

Pre-built taxonomy

Start with a sector-specific function catalogue (banking, insurance, payments, investment, crypto).

02

Scoring engine

Enter your thresholds once. Resiplan scores every function on the 12+ DORA criteria automatically.

03

Multi-stakeholder workflow

Route borderline cases to business owners, legal, risk. Collect evidence inline. Full audit trail.

04

ICT-to-CIF mapping

Link every ICT service and provider to the CIFs it supports. Drag & drop interface.

05

Auto-generated RoI

The ITS 2024/2956 Register of Information is generated from CIF mappings. Ready to submit.

06

Review & board sign-off

Annual review reminders, change-triggered alerts, electronic board approval with evidence.

Frequently Asked Questions

Do we need to document every non-CIF function too?
Yes, you must document your full function inventory and the assessment that led you to classify each function as CIF or not. Supervisors will ask for the rationale, especially on borderline cases. The burden of proof that something is not critical is on you.
Is there an official list of CIFs by sector?
No. DORA intentionally provides a principles-based definition (Article 3(22)), not a prescriptive list. Each financial entity must self-assess based on its own business model, materiality, and sector. EBA/EIOPA/ESMA Q&As provide interpretation guidance but no exhaustive enumeration.
How does CIF interact with the Register of Information?
Every ICT third-party service in your Register of Information (ITS 2024/2956) must be flagged with whether it supports a CIF. This flag drives contractual obligations (RTS 2024/1773), subcontracting rules (RTS 2025/532), and oversight intensity. Incorrect CIF tagging propagates errors through your entire DORA compliance chain.
What happens if we classify too few functions as CIF?
Under-classifying CIFs is a major supervisory red flag. Supervisors will challenge your methodology, require remediation, and may issue enforcement actions. Under DORA, fines can reach up to 2% of annual worldwide turnover. It also cascades: under-flagged ICT contracts won't have mandatory DORA clauses.
How often should we review the CIF list?
At least annually, and whenever a material change occurs: new product launch, M&A, outsourcing decision, regulatory change, or significant volume shift. The management body must approve each update.
Can an ICT service itself be a CIF?
Technically, DORA defines CIFs as business functions, not ICT services. But ICT services supporting CIFs inherit strict obligations. In practice, if a core banking platform exclusively supports CIFs, its criticality equals the CIF it serves.

Related Resources

Continue deepening your understanding of DORA's interconnected obligations.

Third-Party Risk Management

Register of Information, contractual clauses, subcontracting under DORA.

Read Guide →

Free Gap Analysis Tool

Assess your DORA compliance across all 5 pillars in 10 minutes.

Start Assessment →

RTS & ITS Overview

All 13 Regulatory and Implementing Technical Standards in one place.

Read Overview →

How Compliant Is Your Institution?

Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.

Get Your Free DORA Score Join Free Monthly Webinar