Critical or important functions: making the determination defensible.

What the test actually says

Article 3 of Regulation (EU) 2022/2554 defines a critical or important function by reference to the consequences of its failure. A function is critical or important where a disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services and activities, or where discontinued, defective or failed performance would materially impair continuing compliance with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law.

Three things follow directly. The test is about consequence, not about spend, headcount or how modern the system is. It is assessed before mitigation — existing controls do not make a function non-critical. And authorisation compliance is an independent limb: a function that would not move the financial numbers can still qualify because failing it would breach a regulatory obligation.

Getting the unit right

The determination attaches to a function, and functions are business capabilities rather than technology. “The core banking platform” is not a function. “Executing client payments” is. Assessing systems instead of functions produces a list that is simultaneously too long and wrong: it misses functions delivered by several systems, and it treats infrastructure as an end in itself.

A method that holds up

1. Catalogue functions at a consistent level of granularity, sourced from the business rather than from an application inventory. Allocate permanent identifiers now — renumbering later orphans every register row that references them.
2. Define materiality in advance and in writing: what impairment of financial performance is material for this entity, and what constitutes impairment of soundness or continuity. Deciding this per function invites the answer to follow convenience.
3. Assess each limb separately — financial performance, soundness and continuity, authorisation compliance — and record which limb was met. A function qualifying on the third limb alone is common and entirely valid.
4. Assess before mitigation, then record the mitigations separately as context.
5. Challenge the result. A second reviewer outside the function owner’s reporting line is the cheapest control available, and the absence of one is visible in the output.
6. Approve at the right level and record who approved, on what date, on what inputs.

What the answer changes

The evidence to retain

Retain the function catalogue with identifiers, the written materiality definitions, the per-limb assessment with its reasoning, the inputs relied on, the challenge and its outcome, the approval with date and approver, and the review trigger. A determination that exists only as a flag in a spreadsheet is not defensible, whatever the flag says.

Errors that undermine it

• Assessing after mitigation, which systematically understates the population.
• Using spend or provider size as a proxy for consequence.
• Assessing systems rather than functions.
• Ignoring the authorisation limb, which is where regulatory reporting functions themselves usually qualify.
• Letting the answer follow the workload — concluding non-critical because the consequences are expensive.
• Never re-reviewing. A determination is a point-in-time judgement; new products, migrations and growth all change it.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.