← Back to all articles
SUCCESSCOMPLIANCE
DORA in Austria/EU: Who is Affected and 10 Steps to Minimal Compliance Setup
·
15 min
Author: NEXORA Team Date: December 2025 Reading time: approx. 12 minutes
Brief description
This article precisely explains which financial companies and ICT service providers in Austria and the EU are affected by the Digital Operational Resilience Act (DORA), describes a practical minimal compliance setup in 10 concrete steps, and provides checklists as well as typical audit questions for internal implementation and supervisory communication.
For decision-makers:
- Who is affected: DORA applies from January 17, 2025, to almost all supervised financial companies in the EU (banks, payment institutions, e-money institutions, insurance companies, securities firms, crypto service providers, etc.) as well as indirectly to their ICT service providers. Providers classified as "critical ICT third-party providers" are subject to a European oversight framework by the ESAs.
- Minimal Compliance Setup: A functioning basic setup includes: documented ICT risk policy and integration into overall risk management, defined incident management process with clear reporting channels, complete outsourcing/ICT register (Register of Information), clear roles and responsibilities at management level, regular resilience tests, and due diligence and monitoring processes for ICT third-party providers.
- Timeline: DORA has been directly applicable in all EU member states since January 17, 2025. In Austria, the complete Register of Information had to be submitted to the FMA for the first time by March 31, 2025 (according to current FMA communication, as of December 2024). Ongoing Compliance means continuous updating of all artifacts, annual reviews, and adaptation to new RTS/ITS of the ESAs.
- Supervisory focus: The FMA and other European supervisory authorities place particular emphasis on: ICT Risk Governance at the management body level, a complete and up-to-date ICT register, a functioning major incident reporting process, a verifiable testing strategy (including TLPT for significant institutions in accordance with the relevant RTS), and third-party risk management with clear contractual arrangements (audit rights, exit strategies, security standards).
- Consequences of non-compliance: Inadequate implementation can lead to supervisory measures, including: demand for improvement plans, on-site inspections (together with OeNB/FMA), administrative sanctions, reputational risks, and operational disruptions in the event of unclear ICT dependencies. Missing evidence of ICT resilience can also strain business relationships with clients.
1. Context & why the topic is relevant now (AT/EU)
The Regulation (EU) 2022/2554 – Digital Operational Resilience Act (DORA) has been directly applicable in all EU member states since January 17, 2025. DORA closes a central gap in European financial supervisory law: While financial resilience (capital, liquidity) was strengthened after the 2008 financial crisis, ICT-related risks remained anchored in fragmented national regulations. With the increasing digitalization of the financial sector – cloud usage, API-based services, outsourcing of critical functions – operational resilience to cyber threats and IT disruptions has become a systemic challenge.
DORA harmonizes the requirements for digital operational resilience EU-wide and integrates ICT third-party providers directly into the supervisory framework for the first time. For Austrian institutions, this means: The FMA (Financial Market Authority) monitors compliance with DORA in close cooperation with the OeNB (Oesterreichische Nationalbank). The FMA works, among other things, with surveys on the digital landscape and ICT dependencies in Austria; details can be found in ongoing FMA publications and supervisory formats.
Relevance for 2025: Companies must not only demonstrate formal compliance, but also establish substantial processes. The supervisory authority does not check "paper compliance", but expects verifiable implementation in governance, testing, incident management and third-party oversight.
2. Who is affected? (Scope)
Financial companies according to Art. 2 DORA
DORA applies according to Article 2 to a broad spectrum of financial companies ("financial entities"), including:
- Credit institutions (Art. 2 para. 1 lit. a) – e.g. banks, building societies
- Payment institutions and e-money institutions (lit. b–c) – also FinTechs with a payment license
- Securities firms (lit. d)
- Crypto-Asset Service Providers (CASP) according to MiCA regulation (lit. e)
- Central counterparties (CCPs), central securities depositories (CSDs), trading venues (lit. f–h)
- Managers of investment funds (AIFMs, UCITS-ManCos) (lit. i–j)
- Insurance and reinsurance companies, insurance intermediaries (lit. k–m)
- Institutions for occupational retirement provision (IORPs) (lit. n)
- Rating agencies, administrators of critical benchmarks, crowdfunding service providers, data provision services (lit. o–s)
- Securitization registers (lit. t)
ICT service providers: Normal and "critical"
DORA affects ICT service providers indirectly and directly:
Indirectly: All ICT third-party service providers ("ICT third-party service providers") that provide ICT services to financial companies are integrated into DORA compliance via contractual obligations of the financial companies (Art. 28, 30):
- Audit rights for financial companies and supervisory authorities
- Security and resilience requirements
- Incident reporting obligations
- Exit strategies, data repatriation, interoperability
- Systemic importance (how many financial companies use the provider?)
- Systemic effects in the event of a failure
- No simple alternatives available (concentration/lock-in risk)
Practical examples
Example 1 – Austrian bank with cloud outsourcing: A medium-sized Austrian bank (credit institution according to CRR/CRD) outsources its core banking systems and payment processing to two cloud service providers. The bank is a DORA financial company. It must:
- List both cloud providers in the ICT register (with all DORA/FMA fields, incl. criticality, sub-outsourcing)
- Check contracts for DORA clauses (audit rights, exit, security)
- Perform due diligence and continuous monitoring
- If one of the cloud providers is designated as "critical", the bank must integrate the Lead Overseer's recommendations into its third-party management.
- Define ICT risk policy and testing strategy
- List the SaaS provider in the register, document due diligence
- Ensure contractual exit regulations and interoperability
- Report major ICT incidents (e.g. failure of the SaaS system) to the FMA in accordance with Art. 19.
3. What does "Minimal Compliance Setup" mean? (Definition + Target Image)
Definition
A "Minimal Compliance Setup" is the smallest consistent and verifiable set of governance elements, policies, processes, registers and artifacts with which a financial company can demonstrate to the supervisory authority, internal/external auditors and stakeholders that the DORA basic requirements are implemented seriously, systematically and proportionally.
"Minimal" does not mean "insufficient", but rather:
- No redundant or purely formal documents without practical implementation
- Focus on substance instead of volume
- Proportional to the size, complexity and risk profile of the company
- Scalable: A minimal setup forms the basis for future maturity increases.
Target image of a minimal compliance setup
A minimal setup typically includes:
- ICT Risk Management Framework
- Documented ICT risk policy (integrated into overall risk management)
- Inventory of ICT and information assets
- Risk assessment methodology (incl. legacy systems, concentration risks)
- Assignment of roles and responsibilities (Management Body, CISO/ICT managers, Control Functions)
- Defined ICT Business Continuity Policy and recovery plans
- Incident Management & Reporting
- Process for classification of ICT incidents (based on Delegated Regulation (EU) 2024/1772)
- Definition "Major ICT-related Incident" with clear thresholds
- Internal escalation paths, roles (e.g. CISO, Incident Response Team)
- Interface to the FMA notification (Initial Notification, Intermediate/Final Report in accordance with Delegated Regulation (EU) 2025/301)
- Voluntary Notification process for significant cyber threats
- Testing & Resilience
- Testing strategy that covers different test types:
- Vulnerability Assessments, Penetration Tests
- Scenario-based Testing
- If applicable, Threat-Led Penetration Testing (TLPT) in accordance with Art. 26 for significant institutions (at least every 3 years)
- Documented test results and remediation plans
- Review process for test results at management level
- Third-Party Risk Management
- ICT Third-Party Risk Policy (strategy in accordance with Art. 28 DORA)
- Complete Register of Information (Outsourcing/ICT Register) in accordance with Implementing Regulation (EU) 2024/2956, including:
- All ICT third-party providers (including sub-outsourcing)
- Classification by criticality
- Contract details, SLAs, exit regulations
- Due diligence process before conclusion of contract
- Continuous monitoring (KPIs, SLA compliance, incident reports from third-party providers)
- Exit strategy and contingency plans for critical outsourcing arrangements
- Governance & Roles
- Management Body Responsibility: Formal approval of the ICT risk policy, DORA strategy, budget, testing plan
- Defined Roles: e.g. CISO, ICT Risk Control Function (can be combined with CISO under conditions), Compliance, Operational Risk
- Reporting lines: regular management reports on ICT risks, incidents, testing, third-party monitoring
- Awareness & Training: Training programs for employees, management and (where relevant) ICT third-party providers
- Contracting & Vendor Oversight
- Contract templates/standard clauses for ICT services that integrate DORA requirements (see section "Contracting" below)
- Processes for contract negotiation, monitoring and adaptation
- Documentation & Evidence
- Evidence Pack: A structured set of supporting documents for internal/external audit and supervision (see download artifact below)
- Change Management for policies and processes
- Continuous Improvement: Lessons Learned from Incidents, Tests, Audits
4. The "10 Steps" Roadmap to Minimal Compliance Setup
The following roadmap leads from "hardly prepared" to a functioning minimal setup. The steps build on each other in some cases, but can also be processed in parallel.
Step 1: Clarify scope & roles
Step goal: Define which company parts, business areas and ICT services fall under DORA. Identify who is responsible internally (Management Body, CISO, Compliance, Risk, Legal, Procurement) and who could provide external support.
Typical evidence/artifacts:
- DORA project charter with scope definition
- Stakeholder matrix (roles, responsibilities, RACI)
- List of affected companies (in the case of groups)
- Consolidation logic for notifications (e.g. group level)
- Defining the scope too narrowly (e.g. only IT, not Operational Risk, Procurement, Legal)
- Management Body not involved early on
- Unclear responsibilities between parent company and subsidiaries
Step 2: Formally anchor governance & management body ownership
Step goal: Ensure that the Management Body (Executive Board/Management) formally assumes responsibility for ICT risk and DORA, as required in Art. 5 DORA.
Typical evidence/artifacts:
- Executive Board resolution/Managing Director resolution on the DORA strategy
- Organizational manual/rules of procedure with DORA responsibilities
- Resource planning (budget, personnel) for DORA implementation
- Escalation paths for Major Incidents (CISO → Management Body)
- Management Body considers DORA as an "IT topic" without its own responsibility
- No clear assignment to Executive Board department/Managing Director
- Missing documentation of the Management Body decisions
Step 3: Perform gap analysis
Step goal: Mirror the existing ICT risk, security and outsourcing framework against DORA requirements. Identify what already exists (e.g. from ISO 27001, EBA Outsourcing Guidelines, NIS2) and where gaps exist.
Typical evidence/artifacts:
- Gap analysis report (DORA requirements vs. current status)
- Prioritized list of measures with responsible parties and deadlines
- Mapping existing policies/processes to DORA articles
- Risk register for identified gaps
- Analysis at the document level, without checking practice ("paper compliance")
- No prioritization according to risk and supervisory relevance
- Missing involvement of business units and specialist departments (only IT)
Step 4: Define/update ICT Risk Management Policy & Methodology
Step goal: Adapt existing ICT risk policy or create new policy in accordance with Art. 6 DORA. Integration into overall risk management.
Typical evidence/artifacts:
- ICT Risk Management Policy (approved by Management Body), comprising:
- Risk categories (e.g. Cyber, System Availability, Data Integrity, Third-Party)
- Risk assessment methodology (Likelihood/Impact)
- Risk Appetite/Tolerances
- Roles and responsibilities
- Escalation mechanisms
- Continuous monitoring and reporting
- Asset inventory (ICT and information assets)
- Risk Register (ICT risks)
- Policy is too generic and not tailored to the actual ICT landscape
- No integration with existing risk frameworks (Operational Risk, Compliance Risk)
- Missing connection to Business Continuity and Disaster Recovery
Step 5: Set up Incident Management & Incident Reporting Process
Step goal: Establish process for detection, classification, response, recovery and reporting of ICT incidents. Build interface to FMA notification in accordance with Art. 19 DORA.
Typical evidence/artifacts:
- Incident Management Policy with:
- Incident classification criteria (in accordance with Delegated Regulation (EU) 2024/1772)
- Definition "Major ICT-related Incident" and thresholds
- Escalation paths (internal and external)
- Roles (Incident Response Team, CISO, Communication)
- Incident Reporting Procedure (incl. Timelines, Templates in accordance with Implementing Regulation (EU) 2025/302)
- Incident log/ticket system (including for non-major incidents)
- Test run of the reporting process (e.g., tabletop exercise)
- Thresholds for "Major" are unclear or set too high
- No interface between IT incident management and compliance/risk
- Reporting channel to the FMA is not tested or not documented
- No processes for "Voluntary Notification" of cyber threats
Step 6: Establish testing & resilience concept
Step objective: Define a strategy and plan for regular testing of ICT systems and processes (Art. 24-26 DORA), proportional to the risk profile.
Typical evidence/artifacts:
- ICT Testing Strategy/Plan, comprehensive:
- Test types (vulnerability scans, penetration tests, scenario-based tests, possibly TLPT)
- Frequency and scope
- Roles (internal/external testers)
- Remediation process
- Test reports and remediation plans (including historical data)
- For significant institutions: TLPT plan in accordance with Delegated Regulation (EU) 2025/1190, TIBER-EU Framework (every 3 years)
- Purple teaming exercises (for TLPT)
- Testing is reduced to "penetration test once a year" without a systematic strategy
- Remediation plans are not implemented or tracked
- No integration of test results into risk register and management reporting
- TLPT requirements are ignored (if applicable)
Step 7: Implement third-party risk management
Step objective: Strategy and processes for managing ICT third-party risks throughout the entire lifecycle (Art. 28 DORA): due diligence, contracting, monitoring, exit.
Typical evidence/artifacts:
- ICT Third-Party Risk Policy (in accordance with Art. 28 DORA), comprehensive:
- Classification criteria for criticality
- Due diligence requirements (depending on criticality)
- Monitoring mechanisms
- Exit strategy requirements
- Sub-outsourcing management
- Due diligence checklists and reports (per provider)
- Continuous monitoring (KPIs, SLA tracking, incident reports)
- Exit plans and contingency measures for critical providers
- Due diligence is purely formal ("tick the box"), without substantial assessment
- No continuous monitoring after conclusion of contract
- Exit strategies are theoretical but not tested
- Sub-outsourcing is not recorded or managed
Step 8: Set up outsourcing/ICT register and register of information
Step objective: Establish a complete, up-to-date, and consistent register of all ICT third-party providers in accordance with Art. 28 para. 2 DORA and Implementing Regulation (EU) 2024/2956.
Typical evidence/artifacts:
- Register of Information (Excel/Database/GRC tool), comprehensive of all fields in accordance with ITS:
- Provider (name, LEI, location)
- ICT service description
- Classification (critical/important function, sub-outsourcing)
- Contract data (start, end, SLAs)
- Criticality and concentration risk
- Data storage locations
- Exit regulations
- Audit rights
- Process for continuous updating (at least annually, immediately in the event of changes)
- Responsibilities for register maintenance
- Initial notification to FMA in Austria (deadline 2025-03-31, then annually)
- Register is incomplete (e.g., smaller providers, sub-outsourcing are missing)
- Classification (critical/important) is inconsistent or not documented
- No clear assignment of responsibilities for register maintenance
- Data quality is poor (inconsistent entries, outdated information)
Step 9: Adapt contract management/standard clauses
Step objective: Adapt contract templates and standard clauses for ICT services in accordance with Art. 30 DORA to reflect DORA requirements (audit rights, security, exit, etc.).
Typical evidence/artifacts:
- Standard contract clauses (template/playbook) for ICT services, comprehensive:
- Scope of services and criticality
- Security and resilience requirements (including standards such as ISO 27001, NIS2 compliance)
- Audit, information, and access rights (for financial companies and supervisory authorities)
- Incident reporting obligations (timelines, formats)
- Sub-outsourcing regulations (approval, enforcement)
- Exit strategy, data repatriation, interoperability, transition services
- Proof of insurance, liability
- Negotiation playbook (how to negotiate with providers that have standard terms)
- Contract inventory (which old contracts need to be adapted)
- Standard clauses are available but are not used in actual contracts
- No differentiated clause sets depending on criticality
- Exit regulations are vague or impractical
- No processes for regular contract reviews
Step 10: Training, awareness, reporting & continuous improvement
Step objective: Ensure that all relevant employees (including management, IT, risk, procurement) understand DORA requirements. Establishment of management reporting and lessons-learned process.
Typical evidence/artifacts:
- Training plan (DORA awareness for everyone, specific training for roles)
- Training materials and proof of participation
- Management reports (e.g., quarterly):
- ICT risk dashboard
- Incident statistics
- Testing progress
- Third-party monitoring results
- Progress of measures (DORA roadmap)
- Lessons-learned process (after incidents, tests, audits)
- Annual DORA compliance review (gap analysis, policy update)
- Training is purely formal ("tick the e-learning box"), without real awareness
- Management reporting is too detailed or too superficial
- No structured evaluation of lessons learned
- Continuous improvement does not take place (setup remains static)
5. Core areas of DORA in the minimal setup (detailed)
5.1 ICT Risk Management (Chapter II, Art. 5-16 DORA)
Regulatory requirement: DORA obliges financial companies to establish a comprehensive ICT risk management framework (Art. 6) that is integrated into overall risk management. The Management Body bears overall responsibility (Art. 5). Specific requirements include:
- Governance and roles (Management Body, CISO, ICT Risk Control Function)
- ICT risk policy, strategy, and risk tolerance
- Asset inventory and risk assessment
- Protection and prevention measures
- Detection and monitoring
- Response and recovery (including business continuity)
- Backup strategies and redundancy
- Vulnerability management
- Continuous monitoring and adaptation
- ICT Risk Management Policy (approved by Management Body) covering the above points
- Asset inventory (ICT and information assets), with risk classification
- Risk register (ICT risks), with assessment (likelihood/impact), measures, responsible parties
- Role definition: Management Body, CISO (or ICT managers), ICT Risk Control Function (can be combined with CISO while maintaining independence in accordance with Art. 6 para. 4)
- Integration: ICT risks are part of the Operational Risk Framework and are reported in Risk Committees, Audit Committee, and Board
- Reporting: At least annual ICT risk report to Management Body
- Policy is a copy from a standard template, without adaptation to the actual ICT landscape
- Asset inventory is incomplete (e.g., legacy systems are missing)
- Risk register is static and is not updated
- No connection between ICT risks and business impact
- CISO has insufficient resources or escalation options
5.2 Incident Management/Reporting (Chapter III, Art. 17-23 DORA)
Regulatory requirement: Financial companies must have processes for detection, management, and response to ICT incidents (Art. 17). Major ICT-related incidents must be reported to the competent supervisory authority (FMA) (Art. 19):
Note: The following time specifications are based on the relevant delegated legal acts (RTS/ITS) and may be subject to change through future adjustments.
- Initial Notification (within 4 hours of awareness, in accordance with Delegated Regulation (EU) 2025/301)
- Intermediate Report (in the event of significant status changes)
- Final Report (with root cause analysis)
Voluntary reporting of significant cyber threats is possible (Art. 19 para. 2).
Minimal setup:
- Incident Management Policy/Procedure, comprehensive:
- Incident detection (monitoring tools, alerting)
- Incident classification (in accordance with DORA criteria)
- Internal escalation (Incident Response Team, CISO, Management)
- Response and containment
- Recovery and restoration
- Post-incident review (root cause analysis, lessons learned)
- Incident Reporting Procedure to the FMA:
- Defined thresholds for "Major"
- Templates in accordance with Implementing Regulation (EU) 2025/302
- Timelines (4h, Intermediate, Final)
- Responsibilities (who reports, who approves)
- Incident log (all incidents, including non-major)
- Customer communication: Process for informing affected customers in the event of major incidents (Art. 19 para. 3)
- Testing: Tabletop exercises to test incident response and reporting
- Thresholds for "Major" are too high, so reportable incidents are not reported
- Incident response is purely IT-driven, without the involvement of risk, compliance, communication
- No clear responsibility for FMA reporting (IT thinks compliance is responsible, and vice versa)
- Incident log is incomplete or cannot be analyzed
- No evaluation of incidents for continuous improvement
5.3 Testing/Resilience (Chapter IV, Art. 24-27 DORA)
Regulatory requirement: Financial companies must regularly test their ICT systems and operational resilience (Art. 24-25):
- Various test types: vulnerability assessments, penetration tests, scenario-based tests
- Proportional to the risk profile and criticality
Significant institutions (identified by supervision in accordance with Art. 26 para. 8 and the relevant RTS on Threat-Led Penetration Testing, Delegated Regulation (EU) 2025/1190) must carry out Threat-Led Penetration Testing (TLPT) (Art. 26):
- At least every 3 years
- TLPT is based on the TIBER-EU Framework (or national implementations)
- TLPT simulates realistic attack scenarios (threat intelligence, red teaming)
- Purple teaming (cooperation between Red Team / Blue Team) is mandatory in the closure phase
- Internal testers are allowed (under conditions), but every 3rd TLPT must involve external testers
- ICT Testing Strategy, which defines various test types:
- Vulnerability scans (e.g., quarterly automated)
- Penetration tests (e.g., annually on critical systems)
- Scenario-based tests (e.g., cyber-attack simulation, ransomware scenario)
- Business Continuity/Disaster Recovery Tests (e.g., annually)
- Test plan (frequency, scope, responsibilities, budget)
- Test reports and remediation plans (including tracking of measures)
- For significant institutions: TLPT plan in accordance with Delegated Regulation (EU) 2025/1190, including:
- Scope definition (which critical/important functions)
- Selection of external/internal testers
- Coordination with TLPT Authority (FMA)
- Purple-teaming exercise
- Remediation and management reporting
- Testing is not systematic (ad-hoc penetration tests without a strategy)
- Remediation plans are not implemented or tracked (findings remain open)
- No integration of test results into risk register and management reporting
- TLPT is misunderstood as a "normal penetration test"
- No documentation that tests were carried out (missing evidence for supervision)
5.4 Third-Party Risk/Oversight (Chapter V, Art. 28-44 DORA)
Regulatory requirement: DORA introduces comprehensive requirements for the management of ICT third-party risks (Art. 28-30):
- ICT Third-Party Risk Policy (Art. 28 para. 1), including strategy, risk classification, exit regulations
- Due diligence before conclusion of contract (Art. 28 para. 2)
- Continuous monitoring (Art. 28 para. 3)
- Register of Information (Art. 28 para. 2) – complete directory of all ICT third-party providers
- Contractual requirements (Art. 30):
- Service description and SLAs
- Security and resilience requirements
- Audit, information, and access rights (including for supervisory authorities)
- Incident reporting obligations
- Sub-outsourcing regulations (approval, transparency)
- Exit strategy, data repatriation, interoperability, transition services
- Notification to FMA for planned contracts for critical/important functions (Art. 28 para. 3 last sentence) (details unclear, FMA guidance required)
- ESAs designate critical providers (annually)
- Lead Overseer (EBA/ESMA/EIOPA) carries out oversight: information requests, inspections, recommendations
- Financial companies must integrate recommendations of the Lead Overseer into their third-party management (Art. 42)
- ICT Third-Party Risk Policy, comprehensive:
- Risk classification (e.g., Critical / Important / Standard, based on criticality of the function, data sensitivity, concentration/replaceability risk)
- Due diligence requirements (depending on risk class)
- Monitoring mechanisms (KPIs, SLA tracking, incident reports, periodic reviews)
- Exit strategy requirements (contingency, transition plan, testing)
- Sub-outsourcing management (transparency, approval, enforcement)
- Due diligence process:
- Checklist/questionnaire (security, resilience, financial stability, compliance, certifications)
- Documentation of the due diligence results
- Risk acceptance decision (in the event of risks)
- Register of Information (see step 8)
- Continuous monitoring:
- KPI tracking (e.g., availability, response times)
- SLA reports
- Incident reports from third-party providers
- Periodic reviews (e.g., annually)
- Change management (in the event of changes at the provider, e.g., change of location, sub-outsourcing)
- Exit strategy:
- Contingency plans for critical providers
- Transition plan (how to switch to an alternative)
- Testing of exit plans (e.g., every 2 years)
- Contracting: see step 9
- Risk classification is inconsistent or not documented
- Due diligence is purely formal (tick the box), without substantial analysis
- No continuous monitoring (only due diligence at the conclusion of the contract, then nothing)
- Exit strategies are theoretical but not tested or not practical
- Sub-outsourcing is not recorded or managed
- No integration of third-party risks into the overall risk register
5.5 Governance/Roles/Reporting to Management
Regulatory requirement: DORA places explicit responsibility on the Management Body (Art. 5):
- Definition, approval, and monitoring of all ICT risk arrangements
- Approval of ICT risk policy, testing plan, budget
- Regular information about ICT risks, incidents, testing, third-party monitoring
ICT Risk Control Function (Art. 6 para. 4): Independent control function for ICT risk (can be combined with CISO under conditions).
Minimal setup:
- Management Body Responsibility:
- Formal approval of the DORA strategy/roadmap (board resolution/management resolution)
- Approval of ICT risk policy, testing plan, third-party risk policy
- Budget for DORA implementation (personnel, tools, external consultants, testing)
- Definition of ICT risk tolerances/thresholds
- Role definition:
- CISO/ICT Managers: Clear Job Description, Resources, Escalation Options
- ICT Risk Control Function: Can be combined with CISO if independence is guaranteed (Art. 6 para. 4)
- Incident Response Team: Defined roles (Lead, IT, Communication, Legal, Risk)
- Third-Party-Management-Team: Procurement, Risk, IT, Legal
- Reporting lines:
- Regular management reports (e.g. quarterly):
- ICT risk dashboard (top risks, measures, trends)
- Incident statistics (number, classification, major incidents)
- Testing progress (planned vs. performed, findings, remediation)
- Third-party monitoring (new providers, risk assessment, concentration risk)
- DORA compliance status (roadmap, open measures)
- Ad-hoc reporting: In the event of major incidents, immediate information to the Management Body
- Management Body is not substantially involved (considers DORA as an IT project)
- CISOs/ICT managers do not have sufficient resources or authority
- Reporting is too detailed (technical details) or too superficial (no recommendations for action)
- No clear escalation in the event of major incidents or critical risks
6. Contracting & Vendor Oversight: What belongs in contracts/SLAs
According to Art. 30 DORA, contracts with ICT third-party providers (especially for critical/important functions) must contain certain elements. The following principles and content should be enshrined in contracts/SLAs (no model clauses, only content-related guard rails):
- Scope of services and service levels:
- Clear description of ICT services
- Service Level Agreements (Availability, Performance, Response Times)
- Criticality of the Function/Service
- Security and resilience requirements:
- Security standards (e.g. ISO 27001, SOC2, NIS2 compliance)
- Encryption, Access Controls, Monitoring
- Business Continuity/Disaster Recovery (RTO/RPO)
- Backup strategies and testing
- Audit, information and access rights:
- Right of the financial undertaking to conduct audits/inspections (on-site or remote)
- Right of the supervisory authorities (FMA) to conduct audits/inspections at the ICT third-party provider (Art. 30 para. 3 lit. e DORA)
- Information rights: Regular reports (Security, Availability, Incidents)
- Alternative Assurance Levels: If “traditional” audits impair the rights of other customers, alternative evidence can be agreed (e.g. third-party certifications, pooled audits)
- Incident reporting obligations:
- ICT third-party providers must report incidents affecting the financial undertaking without delay
- Timelines (e.g. within 2h of detection)
- Formats (e.g. incident report template)
- Sub-outsourcing:
- Sub-outsourcing only with the approval of the financial undertaking
- Transparency about sub-service providers (register)
- “Right of access” to sub-service providers (audit rights)
- Data storage locations and data protection:
- Clear agreement on where data is stored (EU/EEA preferred)
- GDPR compliance (Data Processing Agreement)
- Data portability and interoperability
- Exit strategy, data repatriation, transition services:
- Exit clause: Possibility of ordinary and extraordinary termination
- Data repatriation: Process and timelines for the repatriation of all data (structured, readable)
- Interoperability: Standards to easily migrate data/services to other providers
- Transition services: ICT third-party provider continues to provide services during the transition period (e.g. 6-12 months)
- Testing of exit: Regular tests of the exit plan (e.g. every 2 years)
- Insurance and liability:
- Proof of sufficient insurance coverage (cyber, professional liability)
- Liability regulations (caps, exclusions)
- Change management:
- ICT third-party providers must notify planned changes (e.g. change of location, technical upgrades, sub-outsourcing) in good time
- Approval requirement for significant changes
- Contract term and extension:
- Reasonable notice periods (at least 6-12 months for critical services)
- Regular contract reviews (e.g. every 2-3 years)
- Negotiate an addendum/side letter that covers DORA requirements
- Use alternative assurance (e.g. SOC2 Type II, ISO 27001, DORA attestations from providers)
- Pay attention to ESA recommendations if the provider is designated as “critical”
7. Typical audit questions (checklist style)
The following list contains questions that internal audit, external auditors or supervisors (FMA) could ask. They serve as an internal checklist:
- Governance:
- Has the Management Body formally approved the DORA strategy/roadmap (board resolution)?
- Are roles and responsibilities for ICT risk and DORA clearly defined and communicated?
- Is there a CISO/ICT manager with sufficient resources and direct access to the Management Body?
- ICT Risk Management:
- Is there a documented ICT risk policy that is integrated into the overall risk management?
- Is a complete asset inventory (ICT and information assets) maintained and regularly updated?
- How are ICT risks assessed (methodology, criteria) and recorded in the risk register?
- Are ICT risks regularly (at least annually) reported to the Management Body?
- Incident Management:
- Is there a documented incident management process with clear escalation paths?
- How do you define “Major ICT-related Incident”? What thresholds do you use?
- Has the FMA reporting process (Art. 19) already been tested (e.g. tabletop exercise)?
- Are all ICT incidents (including non-major ones) recorded and evaluated in a log?
- Testing:
- Is there an ICT testing strategy that covers different test types (vulnerability, penetration, scenario-based)?
- How often are tests carried out? Are the frequencies commensurate with the risk?
- Are test results and remediation plans documented and tracked?
- If applicable: Is TLPT planned/carried out in accordance with Art. 26 DORA?
- Third-Party Risk:
- Is there an ICT third-party risk policy with a clear strategy and risk classification?
- How is due diligence carried out on new ICT third-party providers? Is the process documented?
- Is there a continuous monitoring system for ICT third-party providers (KPIs, SLA tracking)?
- Are exit strategies defined and tested for critical ICT third-party providers?
- Register of Information:
- Is the Register of Information complete (all ICT third-party providers, incl. sub-outsourcing)?
- How do you ensure that the register is up to date (process, responsibilities)?
- Was the register submitted to the FMA on time (in Austria: 31.03.2025)?
- Are all required fields completed in accordance with Implementing Regulation (EU) 2024/2956?
- Contracting:
- Do your contracts with ICT third-party providers contain the elements required in Art. 30 DORA (audit rights, exit, security)?
- How do you handle standard contracts from large providers (e.g. cloud providers)?
- Is there a contract inventory and a process for regular contract reviews?
- Management Reporting:
- Does the Management Body regularly receive reports on ICT risk, incidents, testing, third-party monitoring?
- How are recommendations for action and escalations communicated to the management?
- Training & Awareness:
- Are all relevant employees (IT, Risk, Procurement, Management) trained on DORA requirements?
- Is there a regular training plan?
- Continuous Improvement:
- Is there a lessons-learned process after incidents, tests, audits?
- How is it ensured that DORA compliance is continuously improved (annual reviews, policy updates)?
- Documentation & Evidence:
- Are all relevant proofs (policies, processes, reports, meeting minutes) structured and accessible?
- Could you compile a DORA evidence pack for the supervisor within 2 weeks?
- Oversight of “critical ICT third-party providers”:
- If you use critical ICT third-party providers that have been designated as such by the ESAs: How do you integrate recommendations from the Lead Overseer into your third-party management?
What to do next? – 3 options
Option 1: Self-Check (internal)
Procedure: Use the 10-step roadmap and the audit questions in this article to carry out an internal screening:
- Work through each step and check whether the typical artifacts are present and up to date.
- Document gaps in a list of measures (incl. priority, responsibility, deadline).
- Present the results to the Management Body with recommendations for action.
Time frame: 2-4 weeks (depending on size and complexity).
Option 2: Workshop (internal or with external support)
Procedure: Conduct a focused DORA readiness workshop (1-2 days), ideally with a cross-functional team (IT, Risk, Compliance, Procurement, Legal):
- Clarify scope & roles: Who is affected, who is responsible?
- Gap analysis: Where are we, what is missing?
- Prioritization: Which measures are urgent (minimal setup), which are medium-term (maturity increase)?
- Roadmap & Timeline: When does what need to be completed?
- Resources & Budget: What internal/external resources do we need?
Suitable for: Companies that are still at the beginning or where it is unclear how large the gaps are.
Time frame: 1-2 day workshop + 1 week follow-up (documentation, management presentation).
Option 3: Implementation (step-by-step implementation)
Procedure: Set up a DORA implementation project (internal or with external support):
- Project setup: Project management, steering committee (with Management Body representation), working groups (Governance, Incident, Testing, Third-Party)
- Step-by-step implementation of the 10 steps (see above):
- Create/update policies
- Define and implement processes
- Build/complete register
- Adapt contracts
- Carry out testing
- Carry out training
- Reporting: Regular status updates to the Management Body
- Go-Live: Formal commissioning of the minimal setup
- Post-Go-Live: Continuous improvement, annual reviews
Time frame: 6-12 months (depending on initial situation and resources).
9. FAQ (6-8 questions)
F1: Does DORA apply to my FinTech / my insurance / my payment institution?
A: DORA applies to almost all supervised financial undertakings in the EU (see Art. 2 DORA). Specifically:
- FinTechs: Yes, if they have a financial license (e.g. payment institution, e-money institution, crypto-asset service provider according to MiCA, securities firm).
- Insurances: Yes, all insurance and reinsurance companies as well as insurance intermediaries.
- Payment institutions: Yes, all payment institutions and e-money institutions (according to PSD2/EMD2).
A: Yes, but indirectly and (for critical providers) directly:
Indirectly: All ICT service providers that provide services to financial undertakings are integrated into DORA compliance via contractual obligations (Art. 28, 30):
- Financial undertakings must demand certain security, audit and exit regulations from their ICT third-party providers.
- ICT third-party providers must meet these contractual requirements in order to retain financial undertakings as customers.
- Lead Overseer (EBA/ESMA/EIOPA) can request information, conduct inspections, issue recommendations.
- No licensing requirement, but factual supervision.
- Developing DORA-compliant contract templates
- Obtaining certifications (ISO 27001, SOC2)
- Creating transparency about sub-outsourcing and data storage locations
F3: Which documents do I need for a DORA minimal compliance setup?
A: Core documents of a minimal setup:
- ICT risk policy (approved by Management Body)
- Incident management policy/procedure (incl. FMA reporting process)
- ICT testing strategy/plan
- ICT third-party risk policy
- Register of Information (complete, up-to-date)
- Contract templates (with DORA clauses)
- Asset inventory (ICT and information assets)
- Risk register (ICT risks)
- Management reports (ICT risk, incidents, testing, third-party)
- Training certificates (DORA awareness)
- Evidence pack (structured documentation of all evidence)
F4: How long does it typically take to implement a DORA minimal setup?
A: The duration depends heavily on the initial situation:
- Companies with good ICT risk management (e.g. ISO 27001, EBA Outsourcing Guidelines): 3-6 months for DORA-specific adjustments (completing the register, adapting policies, setting up the FMA reporting process).
- Companies with a fragmented setup: 6-12 months for substantial changes (new policies, process redesign, tool implementation, contract adjustments).
- Companies without structured ICT risk management: 12-18 months (building from scratch).
- Availability of internal resources (personnel, budget)
- Management commitment
- Complexity of the ICT landscape and outsourcing structure
- Necessity to adapt legacy contracts
F5: How does DORA differ from existing outsourcing regulations and national requirements (e.g. FMA minimum standards)?
A: DORA harmonizes and expands existing regulations:
Similarities:
- DORA builds on EBA Outsourcing Guidelines (EBA/GL/2019/02) and adopts many principles (due diligence, monitoring, exit strategies).
- National requirements (e.g. FMA minimum standards for outsourcing management) are largely integrated into DORA.
- Broader scope: DORA applies to all financial undertakings EU-wide (not just banks), incl. insurance companies, payment institutions, crypto service providers.
- ICT focus: DORA comprehensively covers all ICT risks (not just outsourcing), incl. incident management, testing, resilience.
- Direct oversight for critical ICT third-party providers: DORA introduces direct supervision of critical ICT providers by ESAs for the first time (previously only indirectly via financial companies).
- Standardized reporting processes: DORA introduces EU-wide uniform templates and timelines for major incident reporting.
- Testing requirements: DORA defines explicit testing requirements, including TLPT for significant institutions.
- Expand scope (all ICT services, not just outsourcing)
- Complete register (all ICT third-party providers, including sub-outsourcing)
- Adapt incident reporting process (new templates, timelines)
- Expand testing strategy (possibly TLPT).
F6: What is a “Major ICT-related Incident” and how do I recognize it?
A: A “Major ICT-related Incident” is an ICT incident that exceeds certain thresholds and therefore must be reported to the supervisory authority (FMA) (Art. 19 DORA).
Classification criteria according to Delegated Regulation (EU) 2024/1772 (Art. 18 DORA):
- Impact on availability, integrity, confidentiality of data or services
- Number of affected customers/counterparties (including relevance)
- Geographical reach of the impact
- Duration of the disruption
- Criticality of the affected services (e.g., payment transactions, trading platform)
- Outage of the online banking platform for >100,000 customers for >4 hours
- Data leak with access to personal data of >10,000 customers
- Ransomware attack that impairs critical business processes
- Failure of payment processing with significant financial impact
- Define clear thresholds for your company (based on DORA criteria and risk profile)
- Document the classification logic in the Incident Management Policy
- Train incident response team and management to quickly recognize “Major” incidents
- When in doubt (especially in the first months after DORA application begins): it is better to report (Initial Notification) and correct later than not to report.
F7: What happens if I do not meet DORA requirements?
A: Possible consequences of non-compliance:
- Supervisory measures:
- FMA can demand improvement plans with deadlines
- On-site inspections (together with OeNB) to review ICT resilience
- Orders to rectify specific points (e.g., completion of the register, adaptation of contracts)
- Administrative sanctions:
- DORA enables fines for violations (amount varies depending on the violation and member state)
- Publication of sanctions (reputational damage)
- Operational consequences:
- Unresolved ICT dependencies can lead to operational disruptions (failure of critical services, data loss)
- Missing exit strategies can lead to business continuity problems in the event of a provider failure
- Business consequences:
- Reputational risks: Customers and partners lose confidence in the event of known compliance deficiencies
- Business relationships: Financial companies that themselves must be DORA-compliant may terminate or not renew contracts with non-compliant ICT third-party providers
- Personal consequences:
- Management Body can be held accountable (Art. 51 DORA: sanctions also against natural persons)
F8: Do I have to update my Register of Information annually?
A: Yes, but not only annually:
- Initial notification: In Austria, the complete register had to be submitted to the FMA for the first time by March 31, 2025 (according to current FMA communication, as of December 2024; Art. 28 para. 9 DORA, Implementing Regulation (EU) 2024/2956). In other EU member states, the national deadlines may differ.
- Annual update: After that, the register must be updated annually (each time by March 31) and submitted to the FMA.
- Ad-hoc update: In the event of significant changes (e.g., new critical ICT third-party provider, termination of an important contract, significant change in sub-outsourcing), the register should be updated immediately (internal obligation, notification to FMA according to notification obligation in Art. 28 para. 3 last sentence – details unclear, FMA guidance required).
- Implement a process for continuous updating (not just “all at once” once a year)
- Define clear responsibilities (who maintains the register, who approves changes)
- Use a GRC tool or database instead of Excel to ensure consistency and traceability
10. Download package
A) DORA Minimal Compliance Setup – 10-Step Checklist (1 page):
| Requirement | Evidence | Owner | Status | Notes |
|---|---|---|---|---|
| Clarify scope & roles | DORA project charter, stakeholder matrix (RACI), list of affected companies | Project management, Management Body | ☐ Open ☐ In progress ☐ Done | Define consolidation logic for group reports |
| Anchor governance & Management Body Ownership | Management Board resolution/Managing Director resolution on DORA strategy, organizational manual with responsibilities, budget planning | Management Body, HR | ☐ Open ☐ In progress ☐ Done | Define escalation paths for major incidents |
| Perform gap analysis | Gap analysis report, list of measures (prioritized), mapping of existing policies to DORA | Risk, Compliance, IT | ☐ Open ☐ In progress ☐ Done | Prioritization according to risk and supervisory relevance |
| Define/update ICT Risk Management Policy | ICT risk policy (approved), asset inventory, risk register | CISO, Risk | ☐ Open ☐ In progress ☐ Done | Ensure integration into overall risk management |
| Set up incident management & incident reporting process | Incident Management Policy, Incident Reporting Procedure (incl. FMA reporting path), Incident Log, Test Run (Tabletop Exercise) | CISO, IT, Compliance | ☐ Open ☐ In progress ☐ Done | Clearly define thresholds for “Major”; use templates according to ITS |
| Establish testing & resilience concept | ICT testing strategy/plan (Vulnerability, Penetration, Scenario, possibly TLPT), test reports and remediation plans | CISO, IT | ☐ Open ☐ In progress ☐ Done | Proportional to risk profile; TLPT plan for significant institutions according to RTS |
| Implement third-party risk management | ICT Third-Party Risk Policy, Due Diligence Checklists, Monitoring KPIs, Exit Plans | Procurement, Risk, IT, Legal | ☐ Open ☐ In progress ☐ Done | Do not forget sub-outsourcing management; test exit plans |
| Build outsourcing/ICT register and register of information | Register of Information (complete, all fields according to ITS), process for updating, notification to FMA in Austria (03/31/2025) | Procurement, Risk, Compliance | ☐ Open ☐ In progress ☐ Done | GRC tool or database recommended instead of Excel |
| Adapt contract management/standard clauses | Standard contract clauses (template/playbook) for ICT services, negotiation playbook, contract inventory | Legal, Procurement | ☐ Open ☐ In progress ☐ Done | Differentiated clause sets depending on criticality; check existing contracts |
| Training, awareness, reporting & continuous improvement | Training plan, proof of participation, management reports (ICT risk dashboard), lessons-learned process, annual DORA compliance review | HR, Compliance, Risk | ☐ Open ☐ In progress ☐ Done | Management reports quarterly; annual policy reviews |
Note: This checklist is a guide. It does not constitute legal advice. Adapt the checklist to your specific risk profile and initial situation.
B) DORA Evidence Pack – Sample Table of Contents (structured):
This table of contents shows how a typical DORA Evidence Pack could be structured. It serves as a template for internal documentation and as preparation for audits/supervisory reviews.
1. Governance & Organization
1.1 DORA roles and responsibilities
- Organizational manual/rules of procedure (excerpt: DORA responsibilities)
- Job Description CISO/ICT Officer
- Role matrix (RACI) for DORA implementation
- Management Board resolution/Managing Director resolution: Approval of DORA strategy/roadmap
- Management Board resolution/Managing Director resolution: Approval of ICT risk policy
- Management Board resolution/Managing Director resolution: Budget for DORA implementation
- Minutes of relevant management meetings (e.g., Risk Committee, Audit Committee)
- Escalation paths for major ICT incidents
- Communication plans (internal, external, supervisory authority, customers)
2. ICT Risk Management
2.1 Policy
- ICT Risk Management Policy (current version, approved by Management Body)
- Change history of the policy (previous versions, change log)
- ICT risk register (Excel/GRC tool export)
- Risk assessment methodology (description, criteria, matrix)
- ICT asset inventory (Excel/CMDB export)
- Information asset inventory (data classification)
- ICT Business Continuity Policy
- Disaster Recovery Plan
- Test reports from BCM/DR tests (e.g., annually)
- Management reports on ICT risk (quarterly reports, latest report)
- Presentations to Management Body (e.g., Risk Dashboard)
3. Incident Management & Reporting
3.1 Policies & Procedures
- Incident Management Policy
- Incident Reporting Procedure (incl. FMA reporting process)
- Incident log (all incidents, including non-major) (Excel/ticket system export)
- Sample incident reports (major and non-major)
- Overview of all FMA notifications (Major ICT-related Incidents)
- Copies of Initial Notifications, Intermediate/Final Reports
- Minutes of tabletop exercises (incident response tests)
- Lessons-learned reports after incidents
4. Testing & Resilience
4.1 Testing Strategy
- ICT Testing Strategy/Plan
- Annual Testing Calendar
- Vulnerability Scan Reports (e.g., quarterly)
- Penetration Test Reports (e.g., annually)
- Scenario-based Test Reports
- (For significant institutions:) TLPT Report and Remediation Plan
- Tracking list for findings from tests (status, responsibility, deadline)
5. Third-Party Risk & Register of Information
5.1 Third-Party-Risk-Policy
- ICT Third-Party Risk Policy (current version)
- Register of Information (complete, all fields according to ITS) (Excel/GRC-Tool-Export)
- Process description for register maintenance
- Evidence of FMA notifications in Austria (03/31/2025, then annually)
- Due-diligence checklist/template
- Sample due-diligence reports (for critical providers)
- KPI dashboard for ICT third-party providers
- SLA reports (examples)
- Incident reports from third-party providers (examples)
- Exit-plan template
- Sample exit plans (for critical providers)
- Evidence of exit-plan tests
- List of critical providers used (if applicable)
- Recommendations of the Lead Overseer (if received)
- Documentation of the integration of recommendations into third-party management
6. Contracting
6.1 Contract Templates
- Standard contract clauses (template/playbook) for ICT services
- Negotiation playbook
- List of all ICT contracts (including status regarding DORA compliance)
- Prioritization list for contract adjustments
- Anonymized sample contracts (DORA-compliant)
7. Training & Awareness
7.1 Training Plan
- DORA training plan (annually)
- Training materials (presentations, e-learning modules)
- Attendance lists (anonymized or aggregated)
- Training certificates (examples)
- Internal communication (newsletter, intranet articles) on DORA
8. Management-Reporting & Continuous Improvement
8.1 Management Reports
- Quarterly reports: ICT risk dashboard, incident statistics, testing progress, third-party monitoring, DORA compliance status
- Presentations to Management Body
- Process description for Lessons Learned
- Sample Lessons-Learned-Reports (after Incidents, Tests, Audits)
- Annual DORA Compliance Review Report
- Policy Update Logs
9. External Audits & Assessments
9.1 Internal Audit
- Audit reports of the Internal Audit on DORA compliance (if available)
- Reports from external auditors (e.g., auditors, security consultants) on DORA compliance (if available)
- Letters from/to FMA on DORA (e.g., inquiries, clarifications)
10. Project Documentation
10.1 DORA Project
- Project Charter
- Project Plan (Roadmap, Milestones)
- Status Reports
- Gap Analysis Report (AS IS vs. TO BE)
- List of measures (prioritized, with status)
Would you like to professionally build or optimize your DORA compliance setup?
- Free 20-minute initial consultation: Discuss your DORA challenges and receive an initial assessment (non-binding, without obligation).
- DORA Readiness Assessment (Fixed Scope): Structured gap analysis based on the 10 steps and audit questions, with prioritized list of measures and management presentation (duration: 2-3 weeks).
- Vendor-Contract Review under DORA: Review of existing ICT contracts for DORA compliance, identification of critical gaps, development of renegotiation strategies.
Contact us for a non-binding consultation:
About NEXORA Unternehmensberatung GmbH:
NEXORA Unternehmensberatung GmbH is a Vienna-based boutique consultancy focusing on Strategy, Compliance/RegTech, Market Entry and Digital Transformation for financial institutions and international companies in Austria and the EU. Our team combines in-depth regulatory know-how with practical implementation experience to deliver clients not just “paper compliance” but substantial, practical solutions. We work closely with our clients to develop tailored approaches that both meet regulatory requirements and increase operational efficiency.
Disclaimer
This article does not constitute legal or tax advice and cannot replace individual advice in specific cases. The contents are based on the current legal situation (as of December 2025) and publicly available sources. For specific questions regarding DORA compliance, you should seek qualified professional advice (e.g., lawyers specializing in financial market law, specialized consultants). The authors assume no liability for the completeness, accuracy or timeliness of the information provided.
Sources & further links
This article is based exclusively on primary sources and official documents:
- EUR-Lex – Regulation (EU) 2022/2554 (DORA):
- European Supervisory Authorities (ESAs) – DORA:
- EBA: https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act-dora
- ESMA: https://www.esma.europa.eu/policy-activities/digital-operational-resilience-act-dora
- EIOPA: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
- Delegated and Implementing Regulations (RTS/ITS):
- Commission Delegated Regulation (EU) 2024/1772 (ICT incident classification)
- Commission Delegated Regulation (EU) 2025/301 (Incident reporting content and timelines)
- Commission Implementing Regulation (EU) 2025/302 (Templates for incident reporting)
- Commission Delegated Regulation (EU) 2024/1774 (ICT risk management framework)
- Commission Delegated Regulation (EU) 2024/1773 (ICT third-party service provider policy)
- Commission Implementing Regulation (EU) 2024/2956 (Register of information)
- Commission Delegated Regulation (EU) 2025/1190 (TLPT RTS)
- Commission Delegated Regulation (EU) 2025/532 (Subcontracting ICT services)
- FMA Austria – DORA Information:
- https://www.fma.gv.at/en/cross-sectoral-topics/dora/
- https://www.fma.gv.at/en/cross-sectoral-topics/dora/dora-managing-of-ict-third-party-risk/
- https://www.fma.gv.at/en/cross-sectoral-topics/dora/dora-ict-risk-management/
- https://www.fma.gv.at/en/banks/incoming-platform/reporting-circumstances-under-dora/
- FMA Publications: "Let's talk about supervision" (DORA-specific editions)
- TIBER-EU Framework (ECB):
- ESAs – Guide on Oversight Activities:
Note: The above links were current at the time of creation (December 2025). Please check regularly for updates, as DORA is a dynamic set of rules and is continuously supplemented by new RTS/ITS, guidelines and Q&As from the ESAs and national supervisory authorities.
This article serves as a guide for DORA compliance preparation and does not replace individual legal or regulatory advice. Adapt the content to your specific risk profile and organizational structure.
Need a consultation?
Book a free initial consultation with the NEXORA team.