--- title: "EU DORA ICT risk management control baseline" canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline" source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline" author: "Sorena AI" description: "An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "EU DORA" - "DORA ICT risk management" - "ICT control baseline" - "digital operational resilience" - "ICT assets" - "ICT third-party risk" - "DORA" - "ICT risk management" - "ICT controls" - "critical or important functions" --- **[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) --- # EU DORA ICT risk management control baseline An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence. *Control Baseline* *EU DORA* ## EU DORA ICT Risk Management Control Baseline This baseline helps translate DORA's ICT risk management framework into concrete controls, records, tests, and review evidence. Built for financial-entity management bodies, ICT risk teams, security operations, resilience owners, procurement, outsourcing, legal, incident response, internal audit, and control owners supporting critical or important functions. DORA does not ask financial entities to keep a generic cybersecurity checklist. It requires a sound, comprehensive, documented ICT risk management framework that protects information assets, ICT assets, physical infrastructure, critical or important functions, and third-party dependencies. This baseline turns that framework into control areas a visitor can review independently: governance, inventory, protection, detection, response, recovery, testing, third-party links, and evidence. ## Baseline scope and governance Start the baseline at DORA Article 6: the ICT risk management framework must sit inside the financial entity's overall risk management system and include strategies, policies, procedures, ICT protocols, and tools. The management body remains central because DORA assigns it responsibility for approving the digital operational resilience strategy, risk tolerance, business continuity policy, response and recovery plans, ICT audit plans, budget, and ICT third-party policy. A useful baseline therefore names the accountable management-body forum, the ICT risk control function, the first-line system and service owners, the internal audit touchpoint, and the senior-management owner for ICT third-party arrangements. If verification of ICT risk management requirements is outsourced, keep the outsourcing record separate from accountability: DORA says the financial entity remains fully responsible. - Record the DORA control area, owner, approving body, applicable entity or group scope, and whether the simplified ICT risk management framework applies. - Link the digital operational resilience strategy to ICT risk tolerance, impact tolerance for ICT disruption, information-security objectives, KPIs, KRIs, reference architecture, incident communication, and testing. - Keep evidence of annual or periodic framework review, event-driven review after major ICT incidents, supervisory instructions, testing findings, audit findings, and remediation follow-up. - Separate ICT risk management, control, and internal audit responsibilities under the three-lines model or the entity's equivalent risk and control model. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the baseline's governance structure: management-body duties in Article 5 and the ICT risk management framework requirements in Article 6. - [Delegated Regulation (EU) 2024/1774 on DORA ICT risk management](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Specifies the detailed ICT security policies, procedures, protocols, tools, simplified framework, and review-report content used to turn DORA's framework into controls. ## Asset, function, and dependency map The baseline should not begin with control names. It should begin with what each control protects. DORA Article 8 requires financial entities to identify, classify, and document ICT-supported business functions, roles and responsibilities, information assets, ICT assets, dependencies, remote-site assets, network resources, hardware, critical assets, asset configuration, links between assets, and processes dependent on ICT third-party service providers. Delegated Regulation 2024/1774 makes the inventory more operational. It expects records such as a unique ICT asset identifier, physical or logical location, classification, asset owner, supported business functions or services, continuity requirements including recovery time and recovery point objectives, internet or external-network exposure, interdependencies, and support end dates where ICT third-party support is relevant. - Maintain a function-to-asset-to-service view for every critical or important function instead of a flat infrastructure inventory. - Map information assets, ICT assets, network resources, remote sites, configuration links, service dependencies, and ICT third-party interconnections. - Flag critical assets and legacy ICT systems so risk assessments, patching, access reviews, testing, backup, and recovery controls can be prioritised. - Update inventories periodically and whenever a major infrastructure, process, procedure, service, supplier, or system change affects ICT-supported functions. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the asset, function, dependency, and inventory requirements in DORA Article 8. - [Delegated Regulation (EU) 2024/1774 on DORA ICT risk management](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Supports the detailed ICT asset-management record fields and criticality assessment criteria. ## Protection and prevention controls For protection and prevention, DORA Article 9 requires controls that preserve availability, authenticity, integrity, and confidentiality of data and ICT systems, especially systems supporting critical or important functions. Treat this baseline area as a set of linked controls rather than a single information-security policy. The minimum control set should cover information security rules, network and infrastructure management, access rights, strong authentication, cryptographic controls, change management, data and system security, logging, network segmentation, secure information in transit, ICT project management, ICT acquisition, development and maintenance, vulnerability management, patch management, physical and environmental security, and human-resource security responsibilities. - Access control: apply need-to-know, need-to-use, least privilege, segregation of duties, identifiable users where possible, controlled emergency access, and periodic access-right reviews. - Vulnerability and patching: monitor trusted vulnerability sources, scan ICT assets in line with classification and risk profile, prioritise remediation, verify closure, and keep escalation procedures when patch deadlines cannot be met. - Data and system security: define secure configuration baselines, authorised software controls, malware controls, media controls, endpoint controls, secure deletion, decommissioning, data-loss prevention, and third-party-operated service requirements. - Network security: document network connections and data flows, segregate or segment ICT systems by criticality and classification, control unauthorised connections, review firewall rules and connection filters, and encrypt network connections based on data classification and ICT risk assessment. - Change and project controls: record, test, assess, approve, implement, verify, and document ICT changes; keep fall-back procedures; report critical-function ICT projects and associated risks to the management body. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the protection and prevention objectives in DORA Article 9. - [Delegated Regulation (EU) 2024/1774 on DORA ICT risk management](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Supports the detailed control topics for ICT asset management, encryption, operations, vulnerability and patch management, data and system security, logging, network security, access control, change management, and project management. ## Detection, response, and recovery controls DORA separates detection from response and recovery, so the baseline should do the same. Detection controls should identify anomalous activities, ICT network performance issues, ICT-related incidents, and potential material single points of failure. Response and recovery controls should then activate documented arrangements, plans, procedures, and mechanisms that contain incidents, limit damage, prioritise resumption, estimate impacts, manage communication, and report where required. The evidence should show that detection is not limited to logs. Delegated Regulation 2024/1774 requires analysis of internal and external factors, logs, business and ICT function information, user-reported issues, cyber-threat scenarios, threat intelligence, and ICT third-party incident notifications that may affect the financial entity. - Define detection roles, alert thresholds, incident-response triggers, automated alerts for critical or important assets, alert prioritisation, and tamper-resistant anomaly records. - Keep incident evidence, significant-or-recurring incident analysis, root-cause records, escalation records, communication records, and lessons learned. - Maintain ICT business continuity, response, and recovery plans aligned to business impact analysis, mapped functions, assets, dependencies, and third-party services. - Document backup scope, minimum backup frequency by data criticality or confidentiality, restoration methods, segregated restore systems, integrity checks, recovery time objectives, and recovery point objectives. - Include continuity measures for failures of ICT third-party service providers supporting critical or important functions. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the detection, business continuity, response, recovery, backup, restoration, and learning requirements in DORA Articles 10 to 13. - [Delegated Regulation (EU) 2024/1774 on DORA ICT risk management](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Supports detailed incident policy, anomalous-activity detection, business continuity testing, and ICT response and recovery plan content. ## Testing, audit, and review evidence A DORA ICT risk management baseline is incomplete unless every control has a test or review path. DORA requires ICT business continuity and response and recovery plans to be tested at least yearly for ICT systems supporting all functions and after substantive changes to ICT systems supporting critical or important functions. The testing plan should include cyber-attack scenarios and switchovers between primary ICT infrastructure and redundant capacity, backups, and redundant facilities for entities in scope of that requirement. Delegated Regulation 2024/1774 also expects an ICT security testing plan to validate the effectiveness of security measures and a review report that can summarise the current and near-term ICT risk profile, threat landscape, control effectiveness, security posture, weaknesses, remediation measures, residual-risk acceptance, past reviews, audits, compliance assessments, digital operational resilience testing, and, where applicable, TLPT results. - Define the test method for each control family: design review, operating effectiveness test, vulnerability scan, restore test, switchover exercise, tabletop, incident simulation, audit, or control self-assessment. - Link each test to the protected function, asset, information asset, supplier service, risk scenario, BIA assumption, recovery objective, and expected evidence. - Document deficiencies, severity, owner, remediation action, expected implementation date, implementation status, control retest, and management-body reporting. - Feed incident lessons, test results, audit recommendations, supervisory findings, and relevant external information back into the ICT risk assessment and framework review. **What evidence proves a DORA ICT risk management control baseline is implemented?** Useful evidence includes the approved ICT risk management framework, digital operational resilience strategy, risk tolerance, asset and dependency inventories, information-security policy, access-control reviews, vulnerability and patch records, secure configuration checks, logs and detection rules, incident records, BIA records, continuity and recovery plans, backup and restore tests, ICT security testing results, audit findings, remediation plans, and management-body approvals. **How should DORA control owners connect ICT assets to third-party risk?** Control owners should link each critical or important function to its supporting ICT assets, information assets, ICT services, direct ICT third-party provider, supply-chain providers where applicable, contractual arrangement reference, substitutability assessment, exit plan, audit evidence, and the impact of discontinuing the ICT service. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the annual and change-driven continuity and response testing requirements, learning loop, and review of the ICT risk management framework. - [Delegated Regulation (EU) 2024/1774 on DORA ICT risk management](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Supports the control-testing plan and the required content of the ICT risk management framework review report. ## Third-party risk links and register evidence DORA's ICT risk management baseline has to connect internal controls to ICT third-party dependencies. DORA Article 8 requires documentation of processes dependent on ICT third-party service providers and interconnections with providers that support critical or important functions. Delegated Regulation 2024/1773 adds the contract-policy layer for ICT services supporting critical or important functions: business need, ex-ante risk assessment, due diligence, approval, monitoring, documentation, exit, and termination. The register of information is a practical source of evidence for this link. The standard templates require financial entities to identify ICT third-party service providers, intra-group providers, subcontractors, ultimate parent undertakings, ICT service supply chains, type of ICT service, substitutability, reasons for difficult substitution, last audit date, exit-plan existence, reintegration possibility, impact of discontinuing services, and whether alternative providers have been identified. - Before approving a critical-function ICT service, record the business need, risk assessment, due diligence, approval owner, contractual reference, data location, processing and storage location, concentration risk, transferability, and service-disruption impact. - Check that contractual arrangements do not remove the financial entity's responsibilities, do not block effective supervision, require provider cooperation with competent authorities, and preserve access to data and premises for the entity, auditors, and competent authorities. - Tie provider vulnerability handling, incident notifications, audit reports, certifications, business continuity measures, exit plans, and subcontractor chains back to the relevant ICT assets and critical or important functions. - Use register fields as control evidence, not merely reporting data: missing audit dates, missing exit plans, no alternatives, high discontinuity impact, or hard reintegration should trigger control review. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the requirement to map third-party dependent processes and interconnections with providers supporting critical or important functions. - [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) - Supports the policy lifecycle for ICT services supporting critical or important functions, including risk assessment, due diligence, monitoring, documentation, exit, and access rights. - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Supports the register-of-information evidence fields for ICT service providers, supply chains, substitutability, audits, exit plans, reintegration, discontinuity impact, and alternative providers. ## Control baseline checklist This checklist helps decide whether the DORA ICT risk management baseline is concrete enough to operate, test, and evidence. Each item should point to an owner, a control record, a test or review record, and a cited reason for inclusion. - Governance: management-body approvals, ICT risk tolerance, digital operational resilience strategy, ICT audit plan, budget, third-party policy, communication channels, and training responsibilities are documented. - Framework: ICT risk management responsibilities, control-function independence, internal audit coverage, review triggers, remediation follow-up, and competent-authority-ready review report content are defined. - Inventory: ICT-supported business functions, information assets, ICT assets, critical assets, remote sites, configurations, interdependencies, third-party processes, and legacy systems are identified and reviewed. - Protect and prevent: information security, access control, authentication, cryptography, data and system security, network security, vulnerability management, patch management, ICT operations, change management, project management, acquisition and development, and physical security controls are documented. - Detect: anomalous-activity detection uses logs, business and ICT reports, user reports, threat intelligence, external inputs, and ICT third-party incident notifications, with thresholds and response triggers. - Respond and recover: BIA, continuity plans, response and recovery plans, crisis communications, backup scope and frequency, restore procedures, redundant capacity, recovery objectives, and third-party failure scenarios are maintained. - Test and improve: ICT security tests, continuity tests, restore tests, switchover exercises, audit results, incident lessons, deficiencies, remediation actions, and management-body reporting are retained. - Third parties: contract-policy lifecycle, due diligence, provider resources, audit and access rights, subcontractor chains, exit plans, register fields, substitutability, discontinuity impact, and alternatives are linked to critical or important functions. Sources for this answer: - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Supports the checklist's core control areas across DORA Chapter II: governance, ICT risk management, identification, protection, detection, response, recovery, learning, and communication. - [Delegated Regulation (EU) 2024/1774 on DORA ICT risk management](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Supports the detailed implementation checks for policies, procedures, tools, access, logging, network controls, testing, continuity, response and recovery, and review reports. - [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) - Supports the checklist items for ICT third-party contract-policy lifecycle, due diligence, monitoring, documentation, exit, and access rights. - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Supports the checklist items that use register-of-information fields as third-party dependency and exit evidence. *Recommended next step* *Placement: before sources* ## This DORA baseline helps structure control evidence Sorena can help convert this baseline into owner-ready control records, evidence requests, source citations, testing prompts, and third-party dependency checks for DORA implementation work. - [Open Research Copilot for EU DORA](/solutions/research-copilot.md): Ask official source questions about DORA ICT risk management controls, asset mapping, third-party dependencies, testing, and evidence using the sources on this page. - [Talk through implementation](/contact.md): Review your DORA ICT risk management baseline, source gaps, control owners, and evidence plan 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 source for management-body responsibility, the ICT risk management framework, identification, protection, detection, response, recovery, backup, restoration, learning, communication, testing, and third-party risk links. - Quote: "digital operational resilience" - [Delegated Regulation (EU) 2024/1774 on DORA ICT risk management](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Detailed RTS source for the ICT security policies, procedures, protocols, tools, simplified framework, control testing, continuity testing, response and recovery plans, and review-report evidence used in the baseline. - Quote: "ICT risk management tools" - [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) - RTS source for contract-policy governance, risk assessment, due diligence, monitoring, documentation, access rights, exit strategies, and termination for ICT services supporting critical or important functions. - Quote: "ICT services supporting critical" - [Implementing Regulation (EU) 2024/2956 on DORA register templates](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - ITS source for register-of-information fields used as evidence of ICT third-party providers, supply chains, service types, substitutability, audits, exit plans, reintegration, discontinuity impact, and alternatives. - Quote: "register of information" ## Related Topic Guides - [DORA Critical or Important Functions: mapping ICT dependencies and evidence](/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions.md): How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence. - [DORA deadlines and compliance calendar for financial entities](/artifacts/eu/digital-operational-resilience-act/deadlines-and-compliance-calendar.md): Calendar the official source 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): Official source 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): Official source 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): Official source 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): Official source 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 based on 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): An official source 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): An official source 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): An official source 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): An official source 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 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): Official source 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): An official source 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): An official source 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): An official source 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/ict-risk-management-control-baseline