If you read DORA carefully, you notice the same five words appearing on almost every page that matters: critical or important function. The defined term — CIF for short — is the trigger that flips an ordinary ICT arrangement into an arrangement subject to the heaviest obligations the regulation imposes. Get the CIF list right and your DORA programme has a defensible perimeter. Get it wrong and every downstream control inherits the error.

This guide walks through the Article 3(22) definition, why CIF is the master switch across the DORA cascade, how it differs from the Critical ICT Third-Party Provider (CTPP) designation that the European Supervisory Authorities make at EU level, and a five-step practical method for building a CIF inventory you can defend in front of a supervisor.

What Article 3(22) Actually Says

Article 3(22) of Regulation (EU) 2022/2554 defines a critical or important function as a function the disruption of which would:

  • materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities; or
  • have a material impact on the continued compliance of a financial entity with the conditions of its authorisation or with its other obligations under applicable financial services law; or
  • be subject to a discontinued, defective or failed performance that would materially impair such continuing compliance.

Three observations matter. First, this is a functional test — the law speaks of functions, not systems, not assets, not third-party contracts. Second, it is a materiality test — the threshold is “material impairment”, a deliberately broad and judgement-based standard. Third, it covers three distinct dimensions: financial impact, continuity of services, and continuing compliance with authorisation. A function only needs to fail one limb to qualify.

This is exactly the kind of definition that requires a documented methodology behind it. Supervisors do not expect a single “correct” list to fall out of the regulation; they expect to see how you reached your list, what criteria you applied, what evidence you weighed, and how the conclusion is reviewed when circumstances change.

Why CIF Is the Master Switch

The CIF determination is not an end in itself. It is the threshold that activates the most demanding parts of DORA across four major areas.

1. Third-party contracts (Article 28-30)

The enhanced contractual requirements in Article 30 — full audit rights, exit strategy obligations, mandatory sub-outsourcing controls, regulatory cooperation clauses, incident notification provisions, location-of-data clauses — only apply where the ICT service in question supports a critical or important function. The recently finalised RTS on sub-outsourcing of ICT services supporting CIFs cascades these obligations down the entire chain of material subcontractors, not just direct providers. Without an accurate CIF list, you do not know which of your contracts need the heavier clauses, and which can safely use the baseline framework.

2. Threat-Led Penetration Testing (Article 26-27)

TLPT, where required, must cover the ICT systems underpinning the entity's critical or important functions. The CIF list is therefore the scoping document that determines the testing perimeter. A narrow CIF inventory produces a narrow TLPT; a sprawling one inflates testing cost and operational risk. Either error is visible to supervisors, who cross-check scope against the documented business-services catalogue.

3. The Register of Information (Article 28(3))

Every ICT third-party arrangement must be entered in the Register of Information, and each entry must indicate whether the arrangement supports a CIF. Supervisors compare the CIF flag in the Register against the entity's CIF inventory and against the underlying service catalogue. Inconsistencies are the first signal of a weak governance trail and the most common trigger for a follow-up question.

4. Resilience controls

Business continuity and response-and-recovery plans (Article 11), ICT business continuity policy (Article 11(2)), and concentration-risk assessment (Article 29) all set their priority and rigour according to whether the function or arrangement supports a CIF. The CIF flag drives recovery-time objectives, the depth of impact-tolerance analysis, and the level of board reporting.

In short: misclassify a CIF and you mis-scope four downstream control families at once.

CIF vs CTPP — Clearing Up a Frequent Confusion

One of the most common confusions in DORA conversations is the conflation of two distinct concepts:

  • A Critical or Important Function is an internal classification made by each financial entity for its own functions, under Article 3(22). Every regulated entity makes its own CIF determinations.
  • A Critical ICT Third-Party Provider (CTPP) is an EU-level designation made by the European Supervisory Authorities under the Oversight Framework (Article 31), targeting a small population of systemically important third-party providers across the European financial system.

They are related — a provider supporting many CIFs across many entities is more likely to be designated a CTPP — but the determination is owned by different parties, follows different criteria, and produces different obligations. Your internal CIF list and the published CTPP list should not be confused.

Five Steps to Classify Your CIFs Defensibly

Step 1 — Start from business functions, not IT systems

A CIF is a function in the legal sense: an activity or process the entity performs in pursuit of its authorised business. The classification exercise must therefore start from the business-services catalogue (or, where none exists, from the entity's product and process inventory), not from the IT asset register. Beginning with applications or infrastructure inverts the analysis and produces lists that look like a CMDB rather than a regulatory inventory.

A workable starting set covers: the entity's authorised activities (e.g. credit transfer, custody, underwriting, claims management), its regulatory reporting and control functions (AML/KYC, transaction reporting, prudential reporting), and the customer-facing services that materialise those activities (digital channels, branch operations, contact centre).

Step 2 — Apply a documented materiality test

The Article 3(22) language is qualitative. To make it operational, define an explicit scoring framework with criteria tied to the three limbs of the definition:

  • Financial impact — expected loss, revenue at risk, cost of disruption per unit of time (e.g. per hour of outage).
  • Continuity of services — number of customers affected, severity of customer detriment, dependence of other services on the function.
  • Compliance with authorisation — would prolonged disruption cause a breach of regulatory obligations or a loss of authorisation conditions?

Each criterion should have an explicit threshold above which the function qualifies. The threshold itself is a board-level decision; document the rationale, calibrate it against your entity's scale, and revisit it when scale changes (M&A, new product lines, exits).

Step 3 — Trace the ICT dependencies

For each CIF, enumerate the ICT services that enable it — internal applications, third-party SaaS, infrastructure providers, network services, identity and access management. This dependency map is the step that flips third-party arrangements into “supporting a CIF” in your Register of Information. The granularity should be the ICT service, not the individual asset: a payment-processing application is one service, even if it runs on a cluster of servers.

The output is a service-to-CIF matrix. Each ICT service that supports at least one CIF inherits the CIF flag and the full obligations stack: enhanced contractual clauses, sub-outsourcing controls, TLPT scope where applicable.

Step 4 — Reconcile with the Register of Information

The Register of Information has a dedicated field for whether each contractual arrangement supports a critical or important function. Reconcile your CIF inventory with the Register, line by line. Mismatches are the most common cause of supervisory follow-up: a contract flagged as supporting a CIF that does not appear in your CIF mapping, or an ICT service in the dependency map that does not appear in the Register, are both visible and both costly.

This reconciliation should be a recurring control, not a one-off exercise. The Register is refreshed annually for submission to the competent authority; the CIF inventory should be aligned to the same cycle.

Step 5 — Govern it — don't freeze it

Three governance steps separate a defensible CIF list from a static document:

  • Management body sign-off. Article 5(2) makes the management body fully accountable for the ICT risk framework, including the CIF inventory. Approval at executive committee level alone is not sufficient.
  • Annual reassessment. The framework must be reviewed at least annually under Article 6(7), which in practice forces an annual CIF refresh tied to the strategic-planning cycle.
  • Trigger-based review. Material change events — new product launches, outsourcing decisions, mergers and acquisitions, divestments, significant regulatory changes — require the CIF analysis to be re-run on the affected scope.

Common Methodological Mistakes

Under-scoping to avoid heavier obligations. The most expensive mistake in CIF classification. Supervisors will challenge a narrow list, the Register of Information will betray the inconsistency, and the cost of remediating after a supervisory finding is multiples of the cost of doing it correctly the first time.

Over-scoping to be safe. The mirror error. Flagging every function as critical inflates contractual rework, TLPT cost, and continuity-control overhead without proportionate risk reduction. The Article 3(22) materiality threshold exists for a reason.

Mapping at the wrong level. CIF is a service-level classification. Mapping at the process level produces a list that cannot be reconciled with the Register of Information (which has no process field) and cannot answer the incident-classification criterion on “criticality of services affected”. Mapping at the IT asset level inverts the analysis and produces a CMDB, not a regulatory inventory.

Treating the inventory as static. Service catalogues drift. Without an annual refresh and a trigger-based review process, the CIF list ages out of step with the business within twelve to eighteen months.

Ignoring the qualitative limb. Pure financial scoring misses the “continuing compliance with authorisation” limb of the definition. Functions that produce limited direct revenue (regulatory reporting, AML/KYC screening, customer-facing dispute handling) can still be CIFs because their failure would impair the entity's ability to remain compliant. Build a qualitative override into the scoring framework.

How the CIF Inventory Connects to the BIA

Many institutions confuse the relationship between the Business Impact Analysis (BIA) and CIF identification. They are not alternatives. A correctly designed BIA is the engine of CIF identification: the impact scoring across financial, operational, regulatory and reputational dimensions provides the materiality evidence; the maximum tolerable period of disruption (MTPD) operationalises the materiality threshold; the recovery-time objectives feed the resilience controls. We covered this end-to-end in our BIA → CIF methodology guide; the present article is the conceptual frame, that one is the workshop method.

Where Most Programmes Lose Time

In practice, the bottleneck in CIF classification is rarely the analytical step. It is the documentation trail. A defensible CIF inventory requires:

  • a written methodology (criteria, thresholds, scoring approach);
  • traceable evidence behind each determination (BIA outputs, board minutes, function-owner sign-off);
  • reconciliation reports between the CIF list, the Register of Information, the contract repository, and the TLPT scope document;
  • a review cadence with named owners and dates.

Programmes that approach the CIF inventory as a one-off compliance deliverable produce lists that look complete but cannot be defended under supervisory challenge. Programmes that build the documentation trail in parallel with the analytical work end up with an artefact that survives inspection — and that integrates cleanly with the rest of the DORA cascade.

Conclusion

The Critical or Important Function is the master switch of DORA. It scopes TLPT, gates the enhanced Article 30 contractual obligations, drives the Register of Information criticality flag, and sets the priority of business-continuity and concentration-risk controls. Article 3(22) gives you a deliberately broad definition and a deliberately broad set of triggers; the supervisor's expectation is not that your list will match anyone else's, but that you can show how you reached it and how you keep it current.

Start from business functions, apply a documented materiality test, trace the ICT dependencies, reconcile against the Register of Information, and govern the result through management-body sign-off and a refresh cycle. Five steps, one defensible inventory, one supervisory conversation that goes the way you want it to go.

If you want a senior practitioner to pressure-test your methodology, your function inventory and your ICT-dependency mapping against Article 3(22) and against your Register of Information, our 1-Day Remote Audit ships a written gap report within ten business days. For a faster, free baseline, the interactive Gap Analysis covers your scoping and ICT-risk controls in about ten minutes.