Most teams don’t struggle to produce a first pass at function mapping. The friction shows up later, when someone asks a very plain question: why is this function critical, what actually breaks, and how fast does that turn into a regulatory problem. That is usually where the logic starts to thin out.
Under DORA, critical or important functions (CIFs) are those where disruption would materially impair financial performance, service continuity, or compliance with authorisation conditions, as defined in Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. Firms must also record the assessment, the reasons, and the assessment date in the register, as required by Commission Implementing Regulation (EU) 2024/2956 on the RoI templates.
Mapping CIFs sits inside the broader structure of how the DORA register of information is designed and used in practice, but the pressure point is always the same: define the function clearly, test what happens when it breaks, and record enough detail to explain the decision.
Function definitions fail quietly, then all at once
Most CIF problems start with unstable function boundaries.
DORA leaves room for firms to define functions according to their internal organisation, but those definitions are still recorded in a structured way, tied to the financial entity, a function identifier and name, and—where relevant—a licensed activity.
The flexibility is useful, but it creates drift. A function starts as “payments processing,” then absorbs reconciliation, then partially splits when systems change. The label stays. The meaning shifts. The CIF decision does not get revisited.
That is where reviews start to bite.
Keep function definitions aligned
Function definitions often drift as services evolve. Copla Registry maintains structured records and update controls to keep classifications aligned with operations.
What a function entry needs to stay usable
| Field | What it captures | Why it matters |
|---|---|---|
| Purpose | One-sentence description of the function | Anchors the definition |
| In scope | Included activities or services | Prevents silent expansion |
| Out of scope | Explicit exclusions | Avoids overlap and duplication |
| Owner | Accountable role | Ensures someone updates it |
| Assessment cadence | Review frequency | Stops drift over time |
| Licensed activity link | Where relevant | Connects to regulatory scope |
Outsourcing registers tend to build from vendors and contracts upward. CIF mapping works the other way around, which is why outsourcing registers rarely map cleanly into DORA’s structure.
Once the function is stable, the real test begins.
The CIF decision only works when you force the chain
Disruption on its own is not enough. Impact statements are often too broad. The useful work happens when you force the link between the two and add time and constraint.
The material impairment chain
| Step | Question | What it reveals |
|---|---|---|
| Disruption | What fails? | The starting point |
| Consequence | What is affected? | The business impact |
| Time-to-impact | How quickly it matters | Urgency |
| Constraint | What limits recovery | Real exposure |
| Compliance impact | Which obligation is affected | Regulatory consequence |
Most weak CIF classifications stop at “this would be disruptive.” That is rarely enough to defend the decision.
Illustrative scenario
What happens when login fails
Take a simple case: customer login.
- Function: customer access to online banking (login and session management)
- ICT service: authentication service
Walk the chain:
- Disruption: authentication fails
- Consequence: customers cannot log in
- Time-to-impact: immediate
- Constraint: no manual fallback at scale
- Compliance impact: interruption of access to account services
There is no ambiguity left. The function is either critical, or the definition itself is wrong.
The rationale is short in the register, but it has to stand up
The register only captures a compressed version of the decision. The underlying logic still needs to exist.
The ITS specifies that firms must record the CIF assessment, provide reasons (with a 300-character limit), and include the date of the last assessment, with 9999-12-31 used where no assessment has been performed.
That structure exposes weak reasoning quickly.
What the rationale actually needs behind the fields
| Element | What it must include | Why it matters |
|---|---|---|
| What breaks | Named service or activity | Makes impact concrete |
| Time-to-impact | Hours or days | Shows urgency |
| Constraint | Workaround or recovery limit | Explains why impact cannot be contained |
| Compliance consequence | Specific obligation or condition | Links to DORA test |
| Owner + date | Responsible role and timestamp | Creates accountability |
| Trigger | Reason for assessment | Explains context |
A weak rationale might say: “important due to dependency.”
A strong one says what stops, how fast, and why it matters.
Weak CIF reasoning tends to surface quickly when reviewers test consistency, evidence, and timing against supervisory expectations, which is why what supervisors will likely test in a function-mapping review and which RoI fields actually evidence the criticality decision become relevant at the same time.
Ownership is usually split as well: business and risk define the function and its importance, technology defines the dependency, and procurement or legal identify contract changes that should trigger reassessment. When those views diverge, the rationale starts to contradict itself.
ICT mapping breaks when the service level is wrong
Teams often map vendors or applications instead of services.
That makes the CIF logic hard to follow. If the service definition does not explain what fails, it cannot support the classification.
The useful level is the delivered capability the function depends on.
What “right level” actually looks like
| Right level (usable) | Why it works | Wrong level | Why it fails |
|---|---|---|---|
| Payment routing service | Direct link to transaction flow | Vendor name | No functional meaning |
| Login authentication service | Explains access failure | Cloud provider | Too broad |
| Trade processing service | Matches business activity | Database cluster | Too technical |
| Document storage service | Tied to compliance need | Application name | Too vague |
A good mapping links a function to a service that clearly explains what would fail. The definition also needs to stay stable enough that technology, risk, and procurement or legal continue working from the same dependency picture when contracts, services, or providers change.
Copla Registry
Map CIFs to the right service level
CIF classifications often drift when linked to vendors or systems instead of services. Copla Registry ensures functions are mapped to clearly defined ICT service layers.
- Link functions to the correct ICT service definitions
- Avoid misclassification based on vendors or systems
- Maintain accurate dependency mapping for supervision
CIF mapping usually fails on the second pass
The first version is rarely challenged. The second version is where problems appear.
Functions evolve. Systems are replaced. Providers change. Workarounds turn out to be weaker than expected. If the mapping is not updated, the CIF classification becomes detached from reality.
What should trigger a reassessment
| Trigger | What changes |
|---|---|
| Major incident or near miss | Reveals real weaknesses |
| System change or migration | Alters dependencies |
| Contract renewal or amendment | Changes service scope |
| Provider change | Introduces new risk profile |
| New location or region | Affects resilience assumptions |
| New subcontractor | Extends dependency chain |
Subcontracting is often where hidden dependencies sit, especially when services rely on additional providers behind the scenes. That is why the ICT service chain that extends beyond the contracted provider needs to be visible.
This is also where cross-functional gaps become obvious. Business and risk may still be working with an old function definition, technology may have updated the service layer, and procurement may have changed the contract terms. Each piece looks correct on its own. Together, they no longer line up.
Once the CIF mapping is accurate, concentration exposure and exit feasibility stop being abstract. They become visible in the same dependency structure, which is why turning CIF visibility into concentration exposure you can actually see and where CIF mapping forces exit feasibility to be real follow naturally.
