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.
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
DORA uses "function" in Article 3(22). However, per EBA Guidelines on Outsourcing Arrangements (EBA/GL/2019/02 §29), a "function" encompasses "any service, activity, process or task". EU financial institutions therefore identify and operate their CIFs at the business service level — because that is the layer at which the entire DORA cascade actually operates:
business service for T1/T2 (revenue/customer-facing or support) ·
ICT service for T3 (technology layer) ·
function only inside regulatory citations.
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.
Every ICT service supporting a CIF must be flagged in the RoI (ITS 2024/2956) with enhanced attributes.
RTS 2024/1773 →Stricter mandatory clauses apply to ICT providers supporting CIFs (audit, subcontracting, exit).
Third-Party Risk →Threat-Led Penetration Tests must cover ICT systems supporting CIFs (DORA Art. 26).
TLPT Guide →The criticality of services affected (i.e. impact on CIFs) is one of the seven RTS 2024/1772 criteria triggering major incident reporting.
RTS 2024/1772 →Stricter subcontracting controls apply to ICT services supporting CIFs: chain mapping, prior authorisation, notification windows and termination rights (RTS 2025/532).
RTS 2025/532 →CIF inventory is an input to risk assessment, BCP/DRP, and resilience testing (DORA Art. 5-16).
RTS 2024/1774 →DORA Article 3(22) sets out three exhaustive criteria. A function qualifies as CIF when its disruption would materially impair at least one of them. Each criterion can be assessed via quantitative metrics and qualitative judgment.
For each function, the materiality test against these three criteria is supported by both quantitative metrics and qualitative judgment. The two columns below are illustrative inputs — DORA does not prescribe specific thresholds; you must define and document your own.
DORA does not prescribe thresholds — set and document your own (e.g. >5% revenue, RTO ≤ 3 days).
Each input maps back to one of the three Article 3(22) criteria.
Note on reputation: reputational impact is not a primary CIF criterion under DORA Article 3(22). Reputation can act as a leading indicator that one of the three legal criteria may be met (a reputational shock often translates into client losses or supervisory action), but reputational concerns alone are not sufficient to qualify a function as critical or important. Adjacent frameworks like BRRD, EBA Outsourcing Guidelines or ISO 22301 do include reputation explicitly — do not confuse them with DORA.
A structured approach reviewed by EBA, EIOPA and ESMA in their joint Q&A on DORA.
Inventory every business service your financial entity delivers — core services (payments, custody, underwriting), support services (treasury, compliance, regulatory reporting). For each, run a BIA producing impact scores (financial, operational, regulatory, reputational, customer) and recovery objectives (RTO, RPO, MTPD). The BIA service catalogue is the input to CIF identification. See dedicated BIA section below ↓
Resiplan imports your BIA (Excel/CSV) and applies the Article 3(22) gate automaticallyFor 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 thresholdsComplement with non-numeric dimensions tied to Article 3(22): authorisation conditions (does this support your licence?), customer protection obligations, service continuity, substitutability, compliance dependencies. Workshop with business heads, legal, risk, compliance.
Resiplan workflow: multi-stakeholder scoring with evidence attachmentsAggregate 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 rationaleFor 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 mappingsThe 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"Mapping at the service level" is not a stylistic choice — it is a hard requirement of the DORA cascade. Here is the operational evidence:
Each row of the RoI (ITS 2024/2956) describes one ICT contractual service, mapped to one or more "functions supported". The xBRL-CSV template has no field for an abstract function — every record must name a concrete service tied to a contract.
RTS 2024/1772 criterion 6 is literally "criticality of services affected". If your CIF inventory is at the process or activity level, you cannot answer the criterion at the granularity supervisors expect.
RTS 2024/1773 (mandatory clauses) and RTS 2025/532 (subcontracting) both regulate the ICT services supporting CIFs — termination rights, sub-contracting authorisation, exit plans. Contracts cannot be signed against abstract functions.
Every mature BCM/BIA methodology (ISO 22301, ISO 22317) inventories impacts and recovery objectives at the service level — because that is the granularity at which clients perceive an interruption and at which RTO/RPO/MTPD become measurable.
Behind every defensible CIF inventory there is a structured Business Impact Analysis (ISO 22317 methodology). DORA does not require a BIA by name, but Article 11(2)(a) explicitly grounds business continuity policies on "impact analysis", and supervisors expect to see the BIA evidence chain when challenging your CIF list. The BIA is therefore the methodological engine that takes you from a service catalogue to a board-approved CIF register.
| BIA phase | Output | DORA linkage |
|---|---|---|
| Service inventory | Catalogue of all business services delivered (internal + external) | Pre-requisite to Art. 6 ICT risk framework — you cannot protect what you have not catalogued |
| Impact assessment | Five-axis impact scoring per service: financial · operational · regulatory · reputational · customer | Direct input to the Article 3(22) materiality test |
| Recovery objectives | RTO, RPO, MTPD, MBCO per service | Art. 11(2)(a) "business continuity policy based on impact analysis" — drives the RTO ≤ 3 days CIF gate |
| Critical service tier | Services ranked by impact severity | Becomes the input to the CIF flag and the T1/T2/T3 tier assignment |
| Recovery testing | Continuity tests per service (tabletop, simulation, full failover) | Art. 11(6) — testing is mandatory; BIA-derived recovery scenarios feed the test plan |
Resiplan importe votre BIA (Excel/CSV) et applique automatiquement le gate Article 3(22) + le RTO ≤ 3 jours. Votre service catalogue devient un CIF register board-ready en quelques clics.
Try the BIA → CIF bridgeIllustrative examples across sectors. The Tier column shows the structural classification of the service (T1 = core business service · T2 = support business service · T3 = ICT service); the CIF Status column shows the result of the materiality evaluation (DORA Art. 3(22) + RTO ≤ 3 days). Your actual classification depends on your specific business model and thresholds.
| Function | Sector | Tier | Typical RTO | CIF Status | Why |
|---|---|---|---|---|---|
| Core banking / transaction processing | Banking | T1 | < 4h | CIF | Direct client impact, regulatory authorisation, systemic relevance |
| Payment initiation (SEPA, instant) | Payments | T1 | < 2h | CIF | High volume, customer-facing, regulated service |
| Claims management | Insurance | T1 | < 24h | CIF | Core to insurance obligations, direct client impact, Solvency II relevance |
| Custody / safekeeping of assets | Investment firms | T1 | < 4h | CIF | Client asset protection is a regulated activity |
| Regulatory reporting (COREP, FINREP) | All | T2 | < 48h | CIF | Failure = breach of authorisation conditions |
| AML / KYC screening | All | T2 | < 24h | CIF | Direct authorisation obligation under AMLD — failure breaches licence conditions |
| Cloud infrastructure (AWS/Azure) | All | T3 | < 4h | CIF (supporting) | T3 ICT service supporting T1/T2 business services — flagged in Register of Information |
| Cybersecurity SOC operations | All | T3 | < 4h | CIF (supporting) | Detection critical for incident reporting timelines |
| HR payroll | All | T2 | 5–10 days | Not CIF | RTO > 3 days, no regulatory or client impact |
| Marketing automation | All | T3 | > 7 days | Not CIF | Disruption does not materially impair services or compliance |
| Internal corporate email | All | T3 | 3–5 days | Depends | Borderline — CIF only if email is the primary regulated communication channel |
| Document management (contracts) | All | T2 | 2–7 days | Depends | CIF if tied to regulatory archiving (RTO < 3 days), otherwise not |
DORA defines CIF as a binary concept (Critical OR Important — yes or no). But operational reality requires a structured catalogue. We classify every business service (T1/T2) and every ICT service (T3) into three tiers based on its nature, then evaluate each one against DORA criteria to determine its CIF status. (See the "function vs service" note above on why we tier services, not abstract functions.)
The tier classifies what kind of service it is (Core business / Support business / ICT). Whether each tiered service is a CIF under DORA is then determined by a separate materiality evaluation against the three Article 3(22) criteria. We illustrate the methodology using a chosen RTO threshold of 3 days (≤ 72h) — DORA does not prescribe a specific RTO; this is an internal materiality benchmark each institution must define and document.
Revenue-generating & client-facing
Regulated business services that directly deliver the institution's authorised activities to clients and the market.
Internal services enabling T1
Compliance, risk, regulatory reporting, finance — without them, T1 services cannot operate or stay compliant.
Technology layer underpinning T1 + T2
Cloud, cybersecurity, identity, network, applicatives — the ICT services flagged in your Register of Information.
Regulated, customer-facing or revenue-generating business services that directly deliver the institution's authorised activities. Failure of a T1 service = immediate impact on clients, market, or licence.
Internal control, regulatory and operational business services that enable T1 services to operate legally and safely. Failure of T2 = T1 cannot remain compliant or operate at scale.
The ICT service layer that supports both T1 and T2 business services. This is the layer that populates the DORA Register of Information (ITS 2024/2956). Each T3 ICT service is then linked to the T1/T2 business services it supports — and inherits the CIF flag of any business service it enables.
Every T1, T2 and T3 service must pass the same materiality evaluation. Tier defines structure; DORA criteria + RTO threshold determine CIF status.
Assign every service to T1, T2 or T3 based on its nature.
Apply Article 3(22): materiality of disruption, regulatory impact, soundness of services.
Define your materiality RTO (we illustrate with ≤ 3 days / 72h). Above the threshold = non-CIF, with documented rationale. Not DORA-mandated — your institution sets this.
Result for each service:
CIF — DORA obligations apply Non-CIF — Documented exclusionDORA does not prescribe a specific RTO threshold for CIF identification; institutions must define and justify their own. We use 3 days (≤ 72h) as a defensible benchmark because: (1) if a service tolerates more than 3 days of disruption without materially impairing the three Article 3(22) criteria, it logically fails the materiality test; (2) it aligns with the DORA major incident reporting cycle (4h → 72h → 1-month); (3) it mirrors PRA SS1/21 "impact tolerance" precedent. A tighter threshold (e.g. 24h) is also acceptable — looser is harder to defend.
Don't run this 3-step evaluation in spreadsheets. Resiplan's CIF Evaluation Module catalogues every business service and ICT service by tier, applies DORA Article 3(22) criteria with the RTO ≤ 3 days rule, and produces a board-ready CIF register — auditable, defensible, ready for supervisory review.
Pre-built T1/T2/T3 sector taxonomies (banking, insurance, payments, investment) — drag-and-drop classification.
Walks each tiered service through the Article 3(22) materiality criteria with structured questions — no expert needed.
Auto-applies the 3-day rule. Above 72h with no regulatory stake = excluded with documented rationale.
Link ICT services to the business services they support. CIF flag inherits up the chain automatically.
The Register of Information (ITS 2024/2956) builds itself from your T3 → T1/T2 mappings. XML-ready.
Every CIF decision is timestamped, attributed, and evidenced. Electronic board approval workflow.
What takes 4 hours of workshops becomes 15 minutes of guided clicks — with full audit trail.
Resiplan operationalises the exact model described above: every business service and ICT service is catalogued by tier, then automatically evaluated against DORA Article 3(22) criteria with the RTO ≤ 3 days threshold. No more spreadsheets, no more arbitrary judgement calls — every CIF decision is auditable.
Drag-and-drop business services into T1 (Core) and T2 (Support); ICT services into T3, using our pre-built sector catalogue.
For each tiered service, Resiplan walks you through the Article 3(22) criteria with guided questions — no expert needed.
Enter the RTO. Resiplan auto-applies the 3-day rule: ≤ 72h = CIF candidate, > 3 days = excluded with documented rationale.
Each T3 ICT service is linked to the T1/T2 business services it supports. CIF flag inherits up the chain automatically.
The ITS 2024/2956 Register of Information is generated from your T3 → T1/T2 mappings. Submit-ready XML.
Electronic board approval, annual review reminders, change-triggered alerts. Full audit trail per CIF decision.
Continue deepening your understanding of DORA's interconnected obligations.
Build the DORA RoI step-by-step: 9 templates, xBRL-CSV format, CIF flagging, 6-step playbook.
Read Methodology →5 phases of TIBER-EU Threat-Led Penetration Testing, team setup, timeline, budget.
Read Methodology →Register of Information, contractual clauses, subcontracting under DORA.
Read Guide →Assess your DORA compliance across all 5 pillars in 10 minutes.
Start Assessment →All 13 Regulatory and Implementing Technical Standards in one place.
Read Overview →Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.