B_06.01 — Functions identification | DORA Register of Information

Purpose

This template defines the business functions of each financial entity that are supported by ICT services. It establishes the link between the entity's operational activities and the ICT services that underpin them.

Each row represents one function within one entity, identified by a unique function ID combined with the entity LEI. Functions are classified by their criticality level:CI_1 (Critical), CI_2 (Important), or CI_3 (Neither).

Business function owners, in coordination with the ICT risk management team, are responsible for identifying and classifying their functions. This template is a prerequisite for B_02.02 (service-function mapping) and B_07.01 (assessments).

Critical Function Assessment Fields

For functions classified as critical or important (CI_1 or CI_2), additional fields become conditionally mandatory per EBA validation rules:

c0060 — Date of last assessment of criticality or importance
c0070 — Reasons for criticality or importance (free text, max 1000 chars)
c0080 — Date of last identification as critical or important
c0090 — Recovery Time Objective (RTO)
c0100 — Recovery Point Objective (RPO)

These fields are optional for non-critical functions (CI_3) but must be filled when the function is critical or important, as enforced by EBA rules v8880_m through v8883_m.

Fields Reference

Code	Field Name	Type	Req.	Description
c0010	Function identifier*	text	Yes	Unique identifier for the function Max length: 255
c0020	LEI of the financial entity*	lei	Yes	LEI of the entity that defines this function Max length: 20
c0030	Licensed activity*	text	Yes	Licensed activity the function supports Max length: 255
c0040	Function name*	text	Yes	Name or description of the function Max length: 255
c0050	Critical or important function*	select	Yes	Whether this function is classified as critical or important Show 2 allowed values `Y` — Critical or important function `N` — Not critical or important
c0060	Date of last assessment of criticality or importance	date	No	Date when the function was last assessed for criticality or importance
c0070	Reasons for criticality or importance	text	No	Reasons why the function is classified as critical or important Max length: 1000
c0080	Date of last identification as critical or important	date	No	Date when the function was identified as critical or important
c0090	Recovery Time Objective (RTO)	text	No	Maximum acceptable time to restore the function after disruption Max length: 255
c0100	Recovery Point Objective (RPO)	text	No	Maximum acceptable data loss measured in time Max length: 255

Relationships

Referenced by (incoming)

←

B_02.02(c0050 → c0010)

Contractual arrangements - Specific information

←

B_07.01(c0020 → c0010)

Assessments of ICT services supporting critical or important functions

Validation Rules

Function ID must be unique per entity. The combination of function ID and entity LEI must be unique. The same function ID can be used by different entities, but not repeated within the same entity.
Entity LEI must be valid. The LEI must pass ISO 17442 checksum validation and reference an entity in B_01.01 or B_01.02.
Criticality assessment required. Every function must have a criticality classification (CI_1, CI_2, or CI_3).
Activity field required. The business activity category must be specified for each function.
Conditional fields for critical functions (EBA rules). When criticality is CI_1 or CI_2, fields c0060 (assessment date), c0070 (reasons), c0080 (identification date), c0090 (RTO), and c0100 (RPO) become mandatory per EBA validation rules.

Example

Field	Value
Function ID	`FN-001`
Entity LEI	`529900T8B...`
Activity	Banking
Function Name	Core Banking System
Criticality	`CI_1` (Critical)
Last Assessment Date	2025-06-15
Reasons for Criticality	Supports all customer transactions and real-time payment processing
RTO	4 hours
RPO	1 hour

Common Mistakes

Not marking critical functions as critical. Under-classifying functions that genuinely support critical operations. This leads to missing risk assessments in B_07.01 and reduced regulatory oversight.
Duplicate function IDs within the same entity. Each function within an entity must have a unique ID. Duplicates break the reference from B_02.02 and B_07.01.
Generic function names. Using overly broad names like "IT Services" instead of specific function descriptions like "Core Banking Transaction Processing" reduces the value of the register.
Missing RTO/RPO for critical functions. When a function is classified as CI_1 or CI_2, the recovery objectives (c0090, c0100) and assessment details (c0060, c0070, c0080) are mandatory. Leaving these empty triggers EBA validation errors.