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 requires it by name: Article 11(5) obliges financial entities to conduct a business impact analysis of their exposure to severe business disruptions, and to assess the potential impact through quantitative and qualitative criteria. Article 12(6) then requires the recovery time and recovery point objectives to be set for each function. Supervisors expect 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.
Run it, rather than read about it. Our DORA Business Impact Analysis Toolkit is the Excel implementation of exactly this method: you rate impact over time, and MTPD, RTO, RPO, the criticality band and the Article 3(22) determination with its written rationale derive themselves. The CIF register tab then exports in Register of Information field order.
See the BIA Toolkit →| 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 |
Illustrative. The entity below is fictional and the scores are an example of the method, not a benchmark for your entity. Take an authorised payment institution offering merchant acquiring and SEPA transfers. Its BIA scores seven services on the five impact axes (1–5), sets an MTPD per service, then runs each through the Article 3(22) gate with a chosen materiality threshold of MTPD ≤ 3 days.
| Service | Tier | Peak impact axis (score) | MTPD | Art. 3(22) criterion triggered | Decision |
|---|---|---|---|---|---|
| Merchant payment processing | T1 | Customer (5), Financial (5) | 2h | Soundness and continuity of services; financial performance | CIF |
| SEPA credit transfer execution | T1 | Customer (5) | 4h | Continuity of a regulated payment service | CIF |
| Safeguarding of client funds | T2 | Regulatory (5) | 24h | Authorisation conditions: the PSD2 safeguarding duty attaches to the licence | CIF |
| AML transaction monitoring | T2 | Regulatory (5) | 48h | Continuing compliance with financial-services law | CIF |
| Regulatory reporting to the NCA | T2 | Regulatory (4) | 72h | Authorisation compliance, exactly at the chosen threshold | CIF borderline, documented |
| Corporate website CMS | T3 | Reputational (2) | 10d | None, no Article 3(22) criterion materially impaired | Not CIF |
| Cloud hosting platform | T3 | Inherited from supported services | 2h | Runs merchant processing and AML monitoring: inherits their CIF status | CIF (supporting) |
Regulatory reporting sits exactly at MTPD = 72h. The entity classifies it as CIF and records why: a missed submission window breaches authorisation conditions regardless of how the MTPD arithmetic falls. If it had excluded the service instead, the written rationale would matter even more, the burden of proof that something is not critical sits with you.
Nobody asks whether hosting is "important" in the abstract. The platform inherits CIF status because two CIF business services run on it. That inheritance is what upgrades the cloud contract to the stricter clause set for services supporting critical or important functions and pulls the platform into TLPT scope.
The website CMS is not a CIF, but it does not disappear: it remains in the service inventory with its assessment and exclusion rationale. When a supervisor asks "why is this not on the list?", the answer is a documented decision, not an absence.
Downstream, this register produces: five Register of Information rows flagged as CIF-supporting (the cloud contract plus its material subcontractors), a contract remediation list for the Article 30 mandatory clauses, the incident classification input for criterion 6 of RTS 2024/1772, and the TLPT scope baseline. One assessment, four regulatory artefacts, which is why the methodology has to be defensible.
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.
Each of these produces a defect that surfaces later: in the Register of Information, in a contract review, or in a supervisory inspection. The fix is listed with each one.
An inventory of "the IT department" or "the onboarding process" cannot populate the Register of Information, which requires one row per contracted ICT service. Fix: remap to services, the granularity at which clients experience an interruption and RTO/RPO become measurable.
"It's T1, so it's critical" skips the legal test. Tier describes what kind of service it is; CIF status comes from the Article 3(22) materiality evaluation. Fix: run every service, including T1, through the gate, and record the result separately from the tier.
The absence of a service from the CIF list is itself a decision supervisors will probe. Fix: document exclusions with the same care as inclusions, assessment scores, the criterion examined, and why materiality is not reached.
An ICT service supporting a CIF business service inherits the flag. Miss it, and the supporting contract lacks the stricter clauses for CIF-supporting services, the subcontracting controls of Delegated Regulation 2025/532, and its place in TLPT scope. Fix: propagate CIF status through the T3 → T1/T2 dependency map every time either side changes.
Article 3(22) is principles-based on purpose: the same service can be critical in one business model and immaterial in another. Supervisors test the methodology, not the list. Fix: derive the list from your own BIA scores and thresholds, and be ready to defend the method.
The list decays with every product launch, outsourcing decision and reorganisation. Fix: annual review with board approval as the floor, plus change-triggered reassessment, and keep the approval trail.
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 →Once a critical function stops: activation criteria, who commands, who must be told and by when, and the Article 11(8) decision log.
Read Guide →Assess your DORA compliance across all 5 pillars in 10 minutes.
Start Assessment →All 13 technical standards with the mandate → legal act → EUR-Lex cross-reference table.
Read Guide →Go further: premium resources
59-page manual: all five pillars, six-phase roadmap, 34 worked examples.
Free self-paced course + a verifiable certificate you can add to LinkedIn. Start here.
Article 30 clause library, Register of Information build guide, exit playbooks, CTPP oversight.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.