How to identify critical or important functions under DORA

If you are a budget owner or compliance lead, you cannot settle contracts, resilience testing or the register of information until you know which functions are critical or important. Under DORA, a function is critical or important (Article 3(22)) if its disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services and activities, or if its failed performance would materially impair continuing compliance with its authorisation conditions or other financial services obligations. The organization owns this classification. Your policy must set out the methodology, the named senior manager must oversee it, and an auditor or competent authority will test whether the result holds up.

The answer changes with the entity, the service and the dependencies behind it. The same cloud platform can support a payments function in one business line and an internal reporting tool in another, and the classification follows the impact of failure, not the vendor's name or the contract value. Start by mapping ICT-supported business functions, the roles that run them, and the information and ICT assets they depend on, as Article 8(1) requires. Record the impact of disruption in terms your management body can weigh, such as customer harm, regulatory breach, or loss of continuity, and review the result at least yearly and whenever the function or its dependencies change.

Document the decision so a reviewer can follow it. For each function, keep the rationale, the data behind the impact assessment, the dependent ICT services and the date of the last review. This classification then drives the contract clauses under Article 30(3), the yearly testing duty under Article 24(6), and whether the function falls within threat-led penetration testing scope. Confirm with your competent authority and your own legal advisers how they expect the methodology to be evidenced, because the regulator's view of materiality shapes the outcome more than any generic template.

How the classification process runs from function to register

The sequence turns the Article 3(22) definition into a documented decision for each business function, then carries those decisions into the register templates that supervisors read. Each step ends with a named record that a reviewer can check.

Inventory business functions and their ICT roles
Business owners and the operational risk or compliance function list the services the entity provides and the business functions behind them, then record which ICT systems each function relies on at a day-to-day level. Article 8(1) expects this to cover roles and responsibilities as well as the information and ICT assets involved. The output is a function inventory that names an accountable owner for each function. The step is complete when every in-scope function has an owner and at least one documented ICT dependency.
Apply the methodology from the ICT policy
Risk and compliance staff run each function through the criteria the management body approved in the ICT services policy, which must set out how critical or important functions are decided. The test asks whether disruption would materially impair financial performance, the soundness or continuity of services, or continuing compliance with authorisation conditions, as Article 3(22) defines it. The output is a scored decision sheet for each function, with the criterion that drove the outcome written next to it. The step is complete when every function has a recorded yes or no and a named reviewer.
Map supporting ICT services and dependencies
For each function marked critical or important, the ICT team traces the services, subcontractors and hosting arrangements that support it, including any intra-group links and fourth-party dependencies that can be identified. This is where the entity learns whether a single provider or cloud region supports several critical functions, which is the concentration risk Article 28(4) asks it to assess. The output is a dependency map linking each function to its systems, providers and contracts. The step is complete when each system in the map points to a contract or to an internal owner.
Record the decision and its rationale
The function owner, the risk function and the relevant approver sign a classification record that states the decision, the criteria applied, the evidence used and the date of review. Article 8(1) requires this classification to be reviewed as needed and at least yearly, so the record must show when the next review falls due. The output is a signed classification record per function, stored where audit can retrieve it. The step is complete when the record is approved by the role the policy names and linked to the function inventory.
Populate the function template B_06.01
The register team transfers the function inventory into template B_06.01 of the register of information, using the terminology in B_99.01 so that the function names match across records. Entries must agree with the dependency map and the classification records, because supervisors compare them. The output is a populated B_06.01 extract with a reconciliation sheet showing each entry traced to its source record. The step is complete when a second reviewer has checked the extract against the classification records and found no unexplained differences.
Populate the critical services assessment B_07.01
For each function confirmed as critical or important, the register team completes the assessment entry in template B_07.01, linking it to the ICT services and providers identified in the dependency map. The entry shows which contracts carry the Article 30(3) clauses and which systems fall within the yearly testing duty in Article 24(6). The output is a B_07.01 extract and a list of contracts that still lack the required clauses. The step is complete when every critical function has a linked service, and any contract gaps are logged as remediation items with an owner.
Feed results into testing and contract plans
The classification results drive the testing programme and the contract remediation plan, since the same decisions determine which systems receive yearly tests and which agreements need the enhanced terms. The resilience testing lead and the procurement team receive the approved list and confirm their schedules against it. The output is an updated testing plan and contract remediation tracker that reference the classification record IDs. The step is complete when each critical or important function has a test entry and each gap has a dated action owner.

What the classification changes in contracts, testing and reporting

Once a function is classified as critical or important, four obligations follow in sequence: how a provider is assessed before signing, what the contract must contain, how often supporting systems are tested, and whether threat-led testing applies. Each card below names the obligation and the check that shows it has been met.

Pre-contract assessment under Article 28(4)

Before signing, the entity must assess whether the service supports a critical or important function, whether supervisory conditions are met, and all relevant risks, including ICT concentration risk. The entity also performs due diligence on the provider and identifies conflicts of interest. Check that the assessment is recorded against the classification in the policy, so the file shows why the contract was approved and by whom.

Service levels and monitoring in Article 30(3)

For services supporting a critical or important function, the contract must set full service levels with precise quantitative and qualitative targets, along with notice and reporting duties. Ask whether the targets are measurable from the entity's side and whether the provider must report breaches within a set time. Vague targets such as "high availability" will not show that monitoring can work.

Audit, access and TLPT participation clauses

The contract must give the entity unrestricted access, inspection and audit rights, extend those rights to the competent authority, and require the provider to take part in the entity's threat-led penetration testing. Confirm that the provider's obligations cover its subcontractors where they support the function. Without these clauses, the entity cannot test or verify the service it depends on.

Exit strategies with a transition period

The contract must include an exit strategy with a mandatory adequate transition period, during which the provider keeps delivering the service while the entity moves to an alternative. Check that the transition period is written into the contract, not left to negotiation at termination, and that data return and deletion terms are stated. The exit plan itself must be documented and tested separately.

Yearly testing of supporting systems

Article 24(6) requires testing at least yearly on all ICT systems and applications that support critical or important functions, for entities other than microenterprises. For self-hosted platforms, this means the platform itself and its configuration, not only the provider's hosting. Confirm the test inventory maps each system to the function it supports, so the yearly test scope can be shown to match the classification.

TLPT scope and competent authority validation

A threat-led penetration test covers several or all critical or important functions and runs against live production systems. The competent authority validates the scope before testing begins, so the entity cannot pick a narrow set of systems on its own. Plan with the scope in mind early, since it determines which providers must take part and which production environments need coordinated testing windows.

Who decides, who prepares, and who tests the classification

The management body carries final responsibility for how the financial entity decides which ICT services support critical or important functions. Under DORA, the ICT risk management policy must set out a methodology for making that decision, and the management body must review the policy at least once a year. The policy must also name the role or senior manager responsible for monitoring the arrangements, so the board can point to one accountable person when a regulator asks who owns the classification.

Approve the methodology: Board minutes should show that members reviewed the criteria used to decide critical or important status, not only that a policy document exists.
Review at least yearly: The annual review should cover changes in services, providers and business functions since the last cycle.
Name the accountable senior manager: The policy should identify the role, its reporting line and its authority to challenge business owners.
Accept or challenge results: Board records should show that the classification list was presented, questioned and accepted.
Fund the work: Budget decisions for assessment, testing and evidence collection sit with this body.

Confirm with your legal and governance team how your entity's board records and delegations will show this oversight.

Common errors that make the classification fail review

Most failed classifications share a few causes: the analysis starts from software rather than from the business function, and the documents that record it do not agree with each other. The cards below cover the errors reviewers look for first and the fix for each one.

Classifying by application, not function

Teams often tag a platform as critical because it is important, or mark a single application as non-critical because it looks like a back-office tool. Article 3(22) asks what happens to the function if it is disrupted, not how large the application is. Start from the business function, then list every ICT system that supports it. Check that each function's assessment names the function's own impact, such as continuity of a payment service, not the product name.

Missing hidden dependencies

A function can look non-critical while depending on shared identity, logging, DNS, certificate or backup services that sit outside its own scope. If those services fail, the function fails too. Map dependencies from the asset inventory and from the function's data flows, and assess the shared services in their own right. Record each dependency so that the classification of the function reflects the whole chain.

Leaving the methodology undocumented

A classification without a written method cannot be repeated or challenged. Reviewers ask which criteria were applied, who approved them, and how a borderline case was decided. The policy must set out the methodology for deciding which ICT services support critical or important functions, and management must review that policy at least once a year. Keep a dated record of each decision and the rationale behind it.

Testing only the scoped systems

Once a function is classified, every ICT system supporting it falls under yearly testing as required by Article 24(6). Teams often test the main application and skip the supporting components that were never classified. Confirm that each system in the function's dependency map has a test entry, and that the test plan covers the same systems as the classification.

Register and policy disagree

The policy, the function assessment and the register of information are reviewed separately, and they drift apart. A provider marked as supporting a critical function in one document may appear as ordinary in another. Reconcile the three sources before each review, using the template structure for function assessments and contractual arrangements. Document every change with its date and reason.

Skipping reviews after change

Classifications made at one point in time go stale when services are added, providers change or a function is redesigned. Article 8(1) requires review of the classification as needed and at least yearly. Set triggers for an early review, such as a new provider, a new hosting location or a merger, and record who checks them.

Questions buyers ask about critical or important functions

Who is responsible for classifying critical or important functions under DORA?

The financial entity is responsible, and the management body carries the accountability. Article 8(1) requires entities to identify, classify and document their ICT-supported business functions, the roles behind them, the information and ICT assets that support them, and their dependencies. Article 3 requires the management body to approve the ICT services policy, including the methodology for deciding which services support critical or important functions, and to name the role or senior manager who monitors those arrangements. Consultants and implementation partners can prepare the analysis, but the entity owns the result and must explain each decision to its competent authority. A software vendor or service provider cannot make that determination on the client's behalf.

How often must the critical or important function classification be reviewed?

At least once a year, and earlier when the business changes. Article 8(1) requires entities to review the classification as needed and at least yearly, and Article 3 requires the management body to review the policy at least once a year. Typical triggers include a new product or customer segment, an acquisition, moving workloads to a different cloud region or provider, a major release that changes data flows, a significant incident, or a change in how a provider supports a function. Each review should record what changed, the reasoning, the date and the approver. Those records are often the first thing a supervisor asks to see.

Can a small financial firm classify critical or important functions in-house?

Yes, provided the people doing the work understand the definition and can document their reasoning. The definition in Article 3(22) applies to every entity: would a disruption materially impair financial performance, the soundness or continuity of services, or continuing compliance with authorisation conditions and other financial services obligations? What changes with size is the volume of functions and the depth of documentation, not the test itself. Confirm which obligations apply to your entity type before you scope the work, because some requirements differ for smaller entities. External help is most useful for a facilitated workshop and an independent challenge review, not for handing over a list you cannot defend.

What input do business owners need to give for the classification?

Business owners supply the impact picture that technical teams cannot see alone. Ask them to describe the processes and services each function delivers, the customers and regulatory obligations affected, how long the function can be unavailable before material harm occurs, which manual workarounds exist, and which systems and providers the function depends on. Use concrete failure scenarios, such as a missed payment cut-off or a claims system unavailable for a full business day. Assign a named owner for each function and record the answers. Without this input, the work tends to produce a list of systems with no link to business impact, which leaves the classification incomplete.

How does the classification connect to the DORA register of information?

The classification decides which entries need the most detail. The register of information follows the templates set out in Article 5, and two of them carry the classification directly: B_06.01 covers functions, and B_07.01 covers the assessment of critical or important services. Every ICT service you flag as supporting a critical or important function must trace back to a function entry and to the assessment behind it. Use one identifier for each function, system and provider across the policy, the asset inventory and the register, so an assessor can follow a chain from business function to provider without manual reconciliation. Mismatches between the function list and the register are a frequent source of questions.

Can a critical or important function classification be certified?

No. DORA sets no certification scheme, and a classification is not a certifiable product. Competent authorities supervise compliance using the powers in Article 50, and they review your documented classification during supervision. The only authority-issued attestation the Regulation provides for is the one confirming that a threat-led penetration test met the requirements under Article 26(7). Be cautious with any offer of a DORA certificate for a function list. What you can build is evidence: approved policy minutes, dated classification records, the rationale for each decision and the register extract. DeployOpen can prepare systems, controls and evidence for that review, but it does not issue audit reports, attestations or certifications.

Why does a critical or important label change contracts and testing?

The label triggers stricter requirements in two places. Article 30(3) adds clauses for services supporting critical or important functions, including full service levels with precise targets, unrestricted access, inspection and audit rights, participation in the entity's threat-led penetration testing, and exit strategies with a mandatory transition period. Article 24(6) requires appropriate tests at least yearly on all ICT systems and applications supporting these functions. TLPT covers several or all critical or important functions on live production systems, and the competent authority validates its scope. A function left unlabelled can mean systems left untested and contracts missing required clauses, so the classification must be right before contracts are renewed.

What to confirm with your supervisor and your own legal team

The Article 3(22) test requires judgement, and the rationale behind each decision is the part supervisors are most likely to ask about. Whether a disruption would materially impair financial performance, the soundness or continuity of services, or continuing compliance with authorisation conditions is not answered by a checklist. Record, for each function you classify as critical or important and for each you decide is not, the facts you relied on, the impact scenario you assessed, the person who approved the decision and the date. A register entry that says only "critical" or "not critical" will be harder to defend than a short memo that shows how the test was applied to the specific function.

Before you finalise the methodology, confirm with your competent authority how it expects the classification to be documented and reviewed, including any supervisory expectations that go beyond the Regulation. Ask your legal team to confirm which of the technical standards you rely on are currently in force, in what form, and whether any amendments affect the classification or the register. Confirm the status of the Digital Omnibus proposal, COM(2025) 837, and procedure 2025/0360(COD) with counsel, and plan your methodology so that a change to the incident reporting route or to other provisions would not force a rewrite of your classification decisions. Treat the current status of each source as something to verify on the day you rely on it, not something this page can settle for you.

Agree in writing who owns each confirmation. Typically the compliance function or the role named in the policy as responsible for monitoring the arrangements holds the supervisor dialogue, legal counsel reviews the legal basis, and the business owner of each function confirms its impact description. If you bring in an implementation partner or an external advisor to prepare the classification workpapers, the advisor prepares the analysis and evidence, but the management body remains accountable for the decisions and for the answers given to the supervisor. Ask any advisor to state in the engagement scope which parts are preparation and which are decisions you must take yourself.

How DeployOpen prepares function inventories and evidence

DeployOpen works on the critical or important function question as a fixed-scope piece of implementation work inside your own infrastructure. We prepare the function inventory, the systems behind each function and the evidence your management body and competent authority will ask to see, while your organization keeps ownership of every classification decision.

How we scope

Agree in writing which business functions, entities and systems fall inside the review before work starts.
Confirm which people in your organization own the classification decision and sign off the methodology.
Set out the deliverables, timeline and responsibilities in the written scope, with any retainer for later reviews agreed separately.

How we build

Map each function to the ICT services, applications, data and dependencies that support it in your environment.
Document the impact assessment method against the Article 3(22) definition so each classification can be traced and re-tested.
Test the resulting inventory against your open-source and self-hosted platforms so the yearly testing scope follows from it.

How we hand over

Deliver the function inventory, classification rationale, system dependency records and mapping to register templates in editable form.
Provide the evidence trail that shows how each classification was reached, ready for internal audit and supervisory review.
Walk your named owner through the record so they can keep it current when services, providers or functions change.

How we support

Offer ongoing support and periodic reviews of the classification as the annual review cycle requires, under a retainer.
Support updates when new ICT services, subcontractors or open-source components change which functions depend on them.
Confirm with your legal and compliance team how the outcome feeds contracts, the register and testing plans. Independent auditors and supervisors make the final assessment.

How to identify critical or important functions under DORA