The single most common methodological weakness EU supervisors find in DORA inspections is a CIF inventory that cannot be traced back to a structured Business Impact Analysis. Article 3(22) of Regulation (EU) 2022/2554 defines what a Critical or Important Function is, but it does not prescribe how to identify one. The bridge between the legal definition and an auditable CIF register is the BIA — a methodology codified in ISO 22317 that pre-dates DORA by more than a decade and that supervisors expect to see operating beneath every CIF list.
This article sets out a complete BIA → CIF workflow: from the service catalogue to the Article 3(22) gate, with the seven steps every financial entity needs to defend its inventory in front of a competent authority.
Why the BIA Is the Foundation, Not an Optional Extra
DORA does not name the BIA explicitly, but it grounds the entire ICT continuity stack on its outputs. Article 11(2)(a) requires institutions to maintain a business continuity policy that is "based on impact analysis". Article 5 mandates an ICT risk management framework that "takes into account the size, nature, scale and complexity" of services. Article 8 calls for a comprehensive identification of ICT-supported business functions. None of these obligations can be discharged credibly without a structured BIA producing a service catalogue with quantified impact and recovery objectives.
The role of the BIA in the CIF identification chain is therefore non-optional:
| BIA phase | Output | DORA linkage |
|---|---|---|
| Service inventory | Catalogue of all business services delivered, internal and external | Pre-requisite to Article 6 ICT risk framework |
| Impact assessment | Five-axis 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 | Article 11(2)(a) business continuity policy — drives the CIF gating threshold |
| 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) | Article 11(6) testing requirement |
The Function vs Service Question, Resolved
One linguistic confusion delays BIA → CIF programmes more than any other: should a CIF be modelled at the level of a "process", an "activity", a "service" or a "function"? DORA Article 3(22) uses the word function — but the EBA Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) clarify in paragraph 29 that "the term function should be understood broadly as any service, activity, process or task". The entire DORA cascade then operates at the service level:
- The Register of Information (ITS 2024/2956) records one row per ICT contractual service, mapped to the business services it supports.
- The incident classification under RTS 2024/1772 explicitly assesses the "criticality of services affected" (criterion 6).
- The mandatory contractual clauses (RTS 2024/1773) and the subcontracting rules (RTS 2025/532) regulate the services supporting CIFs.
- TLPT scoping under Article 26 targets the technology supporting critical services.
A BIA naturally produces a service catalogue, not an abstract function list, which is why supervisors find the BIA-grounded CIF register significantly more defensible than a top-down classification done at the function level. More on the function vs service question →
The Seven-Step BIA → CIF Workflow
Step 1: Build the service catalogue
Inventory every business service the entity delivers, distinguishing customer-facing services (T1: payments, custody, underwriting, claims) from support services (T2: regulatory reporting, AML/KYC, treasury, finance) and ICT services (T3: cloud infrastructure, identity, application platforms). Use the operating model or value chain as the starting point. Aim for 30 to 80 entries for a typical mid-size institution — a catalogue under 20 services is usually too coarse to support DORA, and one over 200 typically conflates services with sub-processes.
Step 2: Score the five impact axes per service
For each service, score the impact of a 24-hour disruption on a 1-5 scale across five axes:
- Financial: direct revenue loss, contractual penalties, capital impact
- Operational: cascade effect on dependent services, transaction backlog
- Regulatory: breach of authorisation conditions, supervisory escalation, fines
- Reputational: media coverage, client complaints, contagion risk
- Customer: number of clients affected, severity of detriment, vulnerable client exposure
The ratings are then aggregated into a service criticality score. Calibrate thresholds against your own risk appetite — not against external benchmarks. The objective is internal consistency, not industry comparison.
Step 3: Determine the MTPD per service
The Maximum Tolerable Period of Disruption (MTPD) is the trump-card metric. It expresses the longest interval the institution can sustain a service interruption before any of the impact axes crosses the materiality threshold. MTPD is not RTO — RTO is the recovery objective the institution commits to achieving; MTPD is the absolute outer limit beyond which the institution itself becomes unviable for that service.
MTPD is the input to the CIF gate. RPO (Recovery Point Objective) is recorded alongside MTPD because it drives the data backup architecture, but it is not used in the CIF gating decision.
Step 4: Apply the CIF gate
A service qualifies as CIF if either of these conditions is met:
- MTPD ≤ the chosen materiality threshold (3 days is the most defensible benchmark, mirroring the DORA major incident reporting cycle and PRA SS1/21 impact tolerance precedent), or
- Disruption breaches at least one Article 3(22) criterion regardless of MTPD — for example, a service whose disruption immediately impairs authorisation conditions (Article 3(22) third indent) is CIF even if MTPD exceeds 3 days.
DORA does not prescribe a quantitative MTPD threshold, but supervisors expect institutions to define and document their own. A threshold above 5 days is generally indefensible.
Step 5: Tier each CIF (T1, T2, T3)
Each CIF service is classified by nature:
- T1 (Core business service): revenue-generating or customer-facing, directly delivers regulated activities — e.g. SEPA credit transfer, custody, underwriting, claims management.
- T2 (Support business service): regulatory or internal control, enables T1 to operate compliantly — e.g. AML/KYC screening, COREP/FINREP reporting, treasury operations.
- T3 (ICT service): technology layer underpinning T1 and T2 — e.g. cloud infrastructure, identity and access management, application hosting.
The tier does not determine CIF status (which is set in step 4); it provides the structural taxonomy supervisors expect to see during inspections.
Step 6: Map the ICT dependencies
For each CIF business service (T1 or T2), enumerate the ICT services that enable it — internal applications, third-party SaaS, infrastructure providers. This dependency map is the source of truth for the Register of Information: each ICT service that supports a CIF business service must appear in the RoI with the criticality flag set.
Step 7: Reverse propagation of the CIF flag
An ICT service supporting at least one CIF business service inherits the CIF flag and the full obligations stack: the contract must include the mandatory clauses of RTS 2024/1773, subcontracting falls under RTS 2025/532 controls, and the technology is in scope for TLPT under Article 26. This reverse propagation is the mechanism through which a CIF mapping at the service level produces the operational obligations across the DORA cascade.
Common Methodological Errors
Mapping at the process level instead of the service level. Processes (e.g. "customer onboarding workflow") are sub-components of services. A CIF inventory at the process level cannot answer the RTS 2024/1772 incident classification criterion 6 ("criticality of services affected") nor populate the RoI which has no process field.
Treating the BIA as a one-off project. Service catalogues drift. Material change events — product launches, M&A, outsourcing decisions, regulatory changes — require re-running the BIA on the affected scope. DORA Article 6(7) requires the ICT risk framework to be reviewed at least annually, which in practice forces an annual BIA refresh.
Ignoring the qualitative dimensions. Quantitative impact scoring captures financial loss but underweights authorisation impact and customer detriment for vulnerable clients. The Article 3(22) third indent ("material impairment of continuing compliance") is a qualitative trigger that pure financial scoring misses.
Skipping the management body sign-off. DORA Article 5(2) makes the management body fully accountable for the ICT risk framework, including the CIF inventory. A BIA → CIF list approved only at executive committee level is a supervisory red flag.
How Resiplan Operationalises the BIA → CIF Bridge
Resiplan is the specialised SaaS for DORA, business continuity and GRC. The BIA → CIF workflow is implemented end-to-end: institutions can import their BIA Excel or CSV directly, the platform applies the Article 3(22) materiality gate with the configured MTPD threshold, the T1/T2/T3 tier is auto-suggested from a sector taxonomy (banking, insurance, payments, investment), and the resulting CIF register feeds the Register of Information generator. Each CIF decision is timestamped, attributed to the assessor, and routed through an electronic management body approval workflow — the audit trail every supervisor expects to find.
What used to take 2 weeks of workshops and a 30-tab spreadsheet becomes 60 minutes of guided clicks — and a register that survives an inspection.
Conclusion
The BIA is not an alternative to CIF identification. It is CIF identification, viewed from the methodological angle. Institutions that approach the CIF inventory as a regulatory deliverable disconnected from BIA produce lists that look complete but cannot be defended under supervisory challenge. Those that treat the BIA as the engine, with the CIF list as one of its outputs, produce inventories that withstand inspection and that integrate cleanly with the rest of the DORA cascade — the Register of Information, incident classification, contractual obligations and TLPT scoping.
Start from the service catalogue, score the five impact axes, determine the MTPD, apply the Article 3(22) gate, tier the CIF, map the ICT dependencies, and propagate the flag. Seven steps, one defensible register, one supervisory conversation made simple.
