--- title: "DORA Critical or Important Functions: mapping ICT dependencies and evidence" canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions" source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions" author: "Sorena AI" description: "How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "EU DORA" - "critical or important functions" - "ICT third-party risk" - "register of information" - "DORA incident classification" - "DORA TLPT" - "DORA" - "incident classification" - "TLPT" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Critical or Important Functions: mapping ICT dependencies and evidence How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence. *Artifact Guide* *EU* ## DORA Critical or Important Functions Classify financial-entity functions, map the ICT services that support them, and preserve the evidence DORA expects across contracts, registers, incidents, testing, and exit planning. For ICT risk, resilience, outsourcing, procurement, legal, security operations, incident response, audit, and business-service owners who need the classification to drive real controls rather than sit in a spreadsheet. Under DORA, a critical or important function is not just a label for a business process. It determines which ICT services need tighter risk assessment, contract controls, subcontractor visibility, register-of-information records, testing coverage, and incident classification. The practical task is to connect each regulated financial service or activity to the ICT systems, providers, data locations, subcontractors, continuity assumptions, and evidence that keep it available and secure. ## What counts as a critical or important function under DORA? DORA defines a critical or important function by impact: the function is critical or important when a defect or failure in its performance would materially impair a financial entity's financial performance, soundness, continuity of services and activities, or continued compliance with authorisation conditions and regulatory obligations. The assessment therefore starts with the business function and its regulated service, not with the vendor catalogue. Use one classification record per function and licensed activity. A payments incident response platform, trading venue matching engine, securities settlement workflow, client authentication service, or actuarial calculation process may be supported by many ICT services; the function classification should explain why disruption to those ICT services would or would not impair the regulated activity. - Name the financial entity, licensed activity, function name, and function owner. - State whether the function is critical or important, not critical or important, or not yet assessed. - Document the impact rationale: financial performance, soundness, service continuity, authorisation, or regulatory compliance. - Link the function to each supporting ICT system, ICT service type, data set, location, internal service owner, and third-party provider. - Record the trigger for reassessment, such as a new ICT service, major architecture change, outsourcing change, incident, concentration finding, or business-service redesign. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Defines critical or important functions by the effect that defective or failed performance would have on a financial entity's performance, soundness, continuity, authorisation, or regulatory obligations. - [Implementing Regulation (EU) 2024/2956 on the register of information](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Requires register templates to identify functions with a function identifier and a criticality or importance assessment. ## Map ICT dependencies before approving or changing the function A useful DORA classification is a dependency map. For each function, identify the ICT services that support it, the direct ICT third-party service provider, the contractual arrangement reference number, the service location, data-processing and storage locations, and whether the service is concentrated in one provider or a small provider group. The map should cover intra-group providers as well as external providers. DORA and the contract-policy RTS treat ICT intra-group service providers as ICT third-party service providers for this purpose; internal group sourcing can change the risk profile but does not remove the need for documented oversight. - Assign a stable function identifier and keep it consistent across entity, sub-consolidated, and consolidated register views. - For each supporting ICT service, record the ICT service type, service owner, provider identifier, contract reference, data category, processing and storage locations, and continuity dependency. - Identify single points of failure, provider concentration, technology-specific lock-in, and limited transferability to another provider. - Mark which ICT services support critical or important functions so incident playbooks, audit plans, business continuity plans, and contract reviews use the same scope. - Keep evidence that data quality checks were performed: accuracy, completeness, consistency, integrity, uniformity, and validity. Sources for this answer: - [Implementing Regulation (EU) 2024/2956 on the register of information](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Explains that the register links contractual arrangements, provider identifiers, function identifiers, and ICT service types, and that register data must be accurate and consistent. - [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Requires the contract policy to account for ICT service type, provider location, data location, concentration, transferability, and disruption impact for ICT services supporting critical or important functions. ## Use the register of information as the operating record DORA's register of information is more than a vendor inventory. It is the record that lets a financial entity, group, supervisor, and Lead Overseer see which ICT contracts and providers support which functions. If the criticality decision is separate from the register, the organization will struggle to prove why a contract, subcontractor, incident, or TLPT scope was treated as higher risk. The register should make the dependency chain reviewable. For ICT services supporting critical or important functions, the register must include subcontractors that effectively underpin those services, including subcontractors whose disruption would impair the service's security or continuity. - Keep the function identifier, contract reference number, financial-entity LEI or EUID, provider identifier, and ICT service type aligned across register templates. - Use one row per valid value where a template field has multiple valid values, rather than burying multiple providers, locations, or services in a note field. - Include entity, sub-consolidated, and consolidated views where applicable so group-level register data reconciles with entity-level records. - Record direct ICT providers at rank 1 and subcontractors at higher ranks in the ICT service supply chain. - Add only relevant additional information, such as internal control IDs or service-tier mappings, without changing the mandatory register data model. Sources for this answer: - [Implementing Regulation (EU) 2024/2956 on the register of information](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Provides the standard register templates, supply-chain ranking rules, required identifiers, group-level register expectations, and data quality principles. - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Requires financial entities to maintain and update a register of information for contractual arrangements on ICT services provided by ICT third-party service providers. ## Translate the classification into third-party and subcontractor controls When an ICT service supports a critical or important function, DORA expects stronger lifecycle control before and during the contract. The contract policy should define how the entity determines which ICT services support critical or important functions, when that assessment is reviewed, who approves and monitors the contract, what due diligence is required, what assurance is accepted, and when exit planning is tested. Subcontracting needs its own control record. Before allowing a provider to subcontract ICT services supporting critical or important functions or material parts of them, assess whether the provider can identify and monitor relevant subcontractors, pass through access and inspection rights, maintain continuity through the subcontracting chain, notify material changes in time, and support termination where changes exceed the entity's risk tolerance. - Before contract signature or material change, complete risk assessment, provider due diligence, concentration analysis, information-security review, continuity review, and approval evidence. - Put in writing the service description, performance targets, reporting obligations, access and audit rights, testing rights, incident obligations, termination rights, and exit plan. - Do not rely solely on certifications or audit reports over time; verify their scope, freshness, control coverage, testing basis, and right to request scope changes or individual and pooled audits. - For subcontractors, assess service type, subcontracted service type, subcontractor and parent-company location, chain length, data shared, group relationship, supervisory status, concentration, transferability, and disruption impact. - Treat intra-group ICT providers and intra-group subcontractors as in-scope providers when they support critical or important functions. Sources for this answer: - [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Specifies contract-policy content for ICT services supporting critical or important functions, including methodology, governance, due diligence, audits, monitoring, exit plans, and annual review. - [Delegated Regulation (EU) 2025/532 on subcontracting ICT services](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - Specifies the elements to determine and assess when ICT services supporting critical or important functions are subcontracted. ## Connect critical-function mapping to incidents, testing, and resilience evidence Critical or important function mapping changes operational response. Under the incident classification RTS, incidents affecting ICT services or network and information systems supporting critical or important functions are treated as incidents affecting critical services. Malicious unauthorised access to systems supporting those functions is singled out as a serious reporting concern, and service downtime thresholds are tighter where critical or important functions are involved. Testing also depends on the classification. DORA requires annual appropriate testing of ICT systems and applications supporting critical or important functions for financial entities other than microenterprises. For entities selected for TLPT, the TLPT scope must cover several or all critical or important functions, identify the underlying ICT systems, processes, technologies, and outsourced or contracted ICT services, and preserve the rationale for including or excluding functions from the test scope. - Feed the function map into incident classification so responders know whether affected systems support critical or important functions. - Store incident evidence by function: affected ICT services, affected clients or financial counterparts, downtime, data losses, transactions, economic impact, cross-border effects, root cause, and remediation. - Use the same function list for business continuity, response and recovery, vulnerability testing, penetration testing, and TLPT scoping. - For TLPT, retain the scope specification, targeted threat intelligence report, red team test plan, red team and blue team reports, summary findings, remediation plan, and attestation. - When a third-party provider supports a tested function, document how the provider participated or why a pooled TLPT approach was used. Sources for this answer: - [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Links critical or important functions to incident criticality, including incidents affecting supporting ICT services and malicious unauthorised access to supporting systems. - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Requires digital operational resilience testing, annual appropriate tests for ICT systems supporting critical or important functions, and TLPT coverage for selected entities. - [Delegated Regulation (EU) 2025/1190 on TLPT criteria and methodology](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Specifies TLPT scoping, threat intelligence, scenario, reporting, remediation, and attestation evidence for critical or important functions. *Recommended next step* *Placement: before sources* ## Build a register-ready DORA critical-function map Sorena can help connect critical or important function assessments to ICT dependency maps, contract controls, incident classification, testing scope, and evidence requests. - [Open Research Copilot for EU DORA](/solutions/research-copilot.md): Ask source-linked questions about DORA critical or important functions, ICT dependencies, register records, third-party risk, and evidence. - [Talk through DORA function mapping](/contact.md): Review your function classification, ICT service map, provider controls, register fields, and open evidence gaps with Sorena. ## Primary sources - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA regulation used for the definition of critical or important functions and the links to ICT risk management, continuity, testing, third-party risk, and the register of information. - Quote: "critical or important function" - [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Used for incident classification implications where ICT services or systems supporting critical or important functions are affected. - Quote: "critical services affected" - [Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Used for contract-policy, due-diligence, assurance, audit, monitoring, and exit-plan requirements for ICT services supporting critical or important functions. - Quote: "contractual arrangements" - [Implementing Regulation (EU) 2024/2956 on the register of information](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Used for register-of-information templates, function identifiers, criticality assessment, ICT service supply-chain ranking, provider identifiers, and data quality expectations. - Quote: "standard templates for the register of information" - [Delegated Regulation (EU) 2025/532 on subcontracting ICT services](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - Used for subcontractor due diligence, notification, risk assessment, pass-through rights, and termination controls for ICT services supporting critical or important functions. - Quote: "subcontracting ICT services" - [Delegated Regulation (EU) 2025/1190 on TLPT criteria and methodology](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Used for TLPT scoping, third-party participation, test reports, remediation plans, and attestation evidence involving critical or important functions. - Quote: "threat-led penetration testing" ## Related Topic Guides - [DORA deadlines and compliance calendar for financial entities](/artifacts/eu/digital-operational-resilience-act/deadlines-and-compliance-calendar.md): Calendar the grounded DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and CTPP oversight milestones. - [DORA ICT Third-Party Contract Remediation Workflow](/artifacts/eu/digital-operational-resilience-act/contract-remediation-workflow.md): A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence. - [DORA ICT Third-Party Contracts FAQ](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md): What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence. - [DORA ICT third-party risk and contract clauses guide](/artifacts/eu/digital-operational-resilience-act/third-party-risk-and-contract-clauses.md): Source-grounded DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight. - [DORA incident classification forms: criteria, fields, and reporting clocks](/artifacts/eu/digital-operational-resilience-act/incident-classification-forms.md): Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records. - [DORA incident clock workflow: classification, reports, deadlines, and evidence](/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow.md): Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence. - [DORA major ICT incident reporting: classification, reports, and timing](/artifacts/eu/digital-operational-resilience-act/major-incident-reporting.md): Source-grounded DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications. - [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md): FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts. - [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md): FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence. - [DORA Register of Information Import and Build Workflow](/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow.md): Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks. - [DORA Register of Information Template: ICT Provider Fields and Evidence](/artifacts/eu/digital-operational-resilience-act/dora-register-of-information-template.md): A grounded DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence. - [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md): FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep. - [DORA vs EBA outsourcing guidelines: ICT third-party risk comparison](/artifacts/eu/digital-operational-resilience-act/dora-vs-eba-outsourcing-guidelines.md): Compare binding DORA ICT third-party risk duties with the EBA/ESA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence. - [DORA vs ISO 22301: ICT resilience and business continuity compared](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-22301.md): Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements. - [DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-27001.md): Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps. - [DORA vs NIS2: financial-sector obligations, overlap, and evidence](/artifacts/eu/digital-operational-resilience-act/dora-vs-nis2.md): Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence. - [DORA vs PSD2 incident reporting: major ICT and payment incidents](/artifacts/eu/digital-operational-resilience-act/dora-vs-psd2-incident-reporting.md): Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence. - [EU DORA Applicability Test for Financial Entities and ICT Providers](/artifacts/eu/digital-operational-resilience-act/applicability-test.md): A source-grounded DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence. - [EU DORA Compliance Checklist for Financial Entities](/artifacts/eu/digital-operational-resilience-act/checklist.md): A source-grounded DORA checklist covering ICT risk governance, major incident reporting, resilience testing, TLPT, ICT third-party contracts, register-of-information records, and audit evidence. - [EU DORA Compliance Obligations and Evidence Guide](/artifacts/eu/digital-operational-resilience-act/compliance.md): A source-grounded DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence. - [EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence](/artifacts/eu/digital-operational-resilience-act/faq.md): Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence. - [EU DORA ICT risk management control baseline](/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline.md): A source-grounded DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence. - [EU DORA ICT subcontracting chain controls for critical functions](/artifacts/eu/digital-operational-resilience-act/subcontracting-chain-controls.md): DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence. - [EU DORA penalties and fines: enforcement powers and limits](/artifacts/eu/digital-operational-resilience-act/penalties-and-fines.md): Grounded guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers. - [EU DORA Register of Information Data Model: templates, fields, and evidence](/artifacts/eu/digital-operational-resilience-act/register-of-information-data-model.md): Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence. - [EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk](/artifacts/eu/digital-operational-resilience-act/requirements.md): A grounded overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence. - [EU DORA Scope and Covered Entities: financial entities and ICT providers](/artifacts/eu/digital-operational-resilience-act/scope-and-covered-entities.md): Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency. - [EU DORA Scope and Proportionality Workflow](/artifacts/eu/digital-operational-resilience-act/scope-and-proportionality-workflow.md): Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals. - [EU DORA testing and TLPT readiness guide](/artifacts/eu/digital-operational-resilience-act/testing-and-tlpt-readiness.md): A grounded DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence. - [EU DORA TLPT eligibility workflow for financial entities](/artifacts/eu/digital-operational-resilience-act/tlpt-eligibility-workflow.md): Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance. - [EU DORA TLPT Runbook: scope, providers, reports, and remediation](/artifacts/eu/digital-operational-resilience-act/tlpt-runbook.md): Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation. - [How does proportionality work under EU DORA?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md): A grounded FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived. - [How to build a DORA register of information](/artifacts/eu/digital-operational-resilience-act/register-of-information-how-to-build.md): Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions