How do we decide which of our functions are critical or important under DORA?

Start

We have to name the functions DORA treats as critical or important

DORA does not give a list. It gives a definition and leaves each financial entity to apply it to its own functions. The answer then drives much else: the register of information, the contract terms, exit plans, testing scope, recovery targets and which incidents count as major. Get this list right first.

• Then: Do we know that DORA binds us as a financial entity?

Decision

Do we know that DORA binds us as a financial entity?

Only a financial entity makes this list. A supplier to a financial entity does not; its customer decides which of its functions the supplier's service supports. If you are not sure whether you are in scope, settle that first.

• Yes: List the functions the firm performs, regulated and supporting
• No, or not known: Settle what you are first; a supplier answers its customer's request

Outcome

Settle what you are first; a supplier answers its customer's request

Run the scope assessment to learn whether DORA binds you and which duties follow. If you are a supplier, your customer decides what your service supports and may ask you for information. Return here once you know you are a financial entity.

Step

List the functions the firm performs, regulated and supporting

Start from what the firm is authorised to do and list each activity as a function, then add the support functions that run on ICT, such as payments processing, customer onboarding, finance and corporate IT. DORA asks for ICT-supported business functions, with roles, assets and dependencies, to be identified, classified and documented. Group them at a level a person can judge.

• Then: Apply the definition's two tests to each function

Step

Apply the definition's two tests to each function

A function is critical or important if its disruption would materially impair the firm's financial performance, or the soundness or continuity of its services and activities, or if its discontinued, defective or failed performance would materially impair continuing compliance with the conditions of its authorisation or its other duties under financial services law. Ask both questions for each one.

• Then: Can the function owner and Compliance judge it now?

Decision

Can the function owner and Compliance judge it now?

The pack has the function owner propose the answer and the programme lead record the reason. If the owner cannot say what a failure would do, or the facts are missing, do not guess in either direction. Mark it not assessed and set a date. Not known takes this branch.

• Yes: Would its disruption or failure materially impair the firm?
• No, or not known: Leave it unassessed, treat it as critical for now and set a date

Step

Leave it unassessed, treat it as critical for now and set a date

This is the pack's cautious default, not a rule in DORA: a function left at assessment not performed is treated as critical or important until it is assessed. This keeps the contract terms, exit plans and register fields in place while the work is done. Put a date on the assessment.

• Then: Record the owner, the date, recovery objectives and effect of stopping

Decision

Would its disruption or failure materially impair the firm?

Think of the effect on the firm's results, on its ability to keep services running and on its permission to operate. Use what the function stops: payments, trades, claims, customer access. Material means more than an inconvenience, and the judgement is yours, recorded with its reasons.

• Yes: Mark it critical or important and write the reason
• No: Would a critical or important function stop if this one failed?

Step

Mark it critical or important and write the reason

Record the reason in a sentence a supervisor can read, such as which service stops and what it does to the authorisation. A bare yes with no reason cannot be defended, and a supervisor may ask for it.

• Then: Record the owner, the date, recovery objectives and effect of stopping

Decision

Would a critical or important function stop if this one failed?

A function can be minor in itself and still hold up a critical one, such as identity, network access or a data feed. Look at the dependencies you listed. If a critical function stops when it fails, say so.

• Yes, or not known: Record the dependency; treat its ICT as supporting that function
• No: Mark it not critical or important and record why

Step

Record the dependency; treat its ICT as supporting that function

Link the function to the critical or important function it holds up, and treat the ICT services it uses as supporting that function in the register. This keeps hidden dependencies from escaping the contract terms and exit plans. This is your judgement; record why.

• Then: Record the owner, the date, recovery objectives and effect of stopping

Step

Mark it not critical or important and record why

A reasoned no is as much a part of the record as a reasoned yes. Say what the firm could do while it was down, and for how long. Review it when the business changes.

• Then: Record the owner, the date, recovery objectives and effect of stopping

Step

Record the owner, the date, recovery objectives and effect of stopping

For each function note who owns it, the date of assessment, its recovery time and recovery point objectives and the impact of discontinuing it. The register templates ask for the date, the objectives and the effect, so one set of figures serves both; the owner is your own record.

• Then: Take the list to the management body for approval

Step

Take the list to the management body for approval

The management body decides the framework and is responsible for it, so it should approve the list and see the reasons. Record the minute, and say which body approved it where governance is split between a board and a committee.

• Then: Hand the list to the work that depends on it

Step

Hand the list to the work that depends on it

The register flags arrangements that support these functions, which then need the extra contract terms and an exit plan. Testing covers the systems behind them at least yearly. Incident classification treats an incident affecting them as touching critical services. Continuity and recovery plans start from them.

• Then: Is a function newly critical, or a new arrangement planned for one?

Decision

Is a function newly critical, or a new arrangement planned for one?

DORA asks the firm to tell its competent authority in a timely manner about a planned arrangement for a critical or important function, and when a function has become critical or important. Your authority sets the channel and form. Not known takes the yes branch.

• Yes, or not known: Tell your competent authority in a timely manner
• No: Is the yearly review due, or has the business changed?

Step

Tell your competent authority in a timely manner

For a planned arrangement, tell your authority before you sign it. For a function that has become critical or important, tell it in a timely manner. Use the route your authority names, give the function and the provider, and keep the date and the acknowledgement. This is a duty to inform, and the pack lists it among the steps its register sheet shows for an arrangement.

• Then: Is the yearly review due, or has the business changed?

Decision

Is the yearly review due, or has the business changed?

Review the classification at least yearly, and after a new product, merger, major incident or test finding. A function can become critical when volumes grow or a new customer relies on it. Not known takes the yes branch.

• Yes, or not known: List the functions the firm performs, regulated and supporting (back to an earlier step)
• No: A reasoned, approved list that the register and plans use

Outcome

A reasoned, approved list that the register and plans use

Keep the list, the reasons, the approval minute and the review dates. Do not say a function is not critical because the provider is small or the ICT is cheap. Criticality follows what the function does, not the supplier or the cost.