Exit Strategy DORA: Vendor Termination Planning (2026)

DORA exit strategy expectations are not just a contractual “termination clause” exercise. Under the Digital Operational Resilience Act (DORA), vendor termination planning typically needs to be operational, testable, and evidence-backed, especially where ICT third-party service providers (ICT TPPs) support critical or important functions. For many financial entities, the hardest part is not writing an exit plan, but keeping it current across vendors, services, contracts, dependencies, and internal owners, while proving governance and decision-making to auditors and supervisors.

This article explains what “exit strategy DORA” means in practice, how termination rights tie to operational feasibility, and how to evaluate tooling and workflows to maintain termination readiness year-round. If you need a DORA baseline refresher first, see what is dora.

Contents

What DORA expects from exit strategies and termination planning

DORA exit strategy requirements: the obligations that drive evidence

DORA Article 28 in practice: what to document, maintain, and test for exit readiness

DORA Article 30 contractual provisions that make exit strategies executable

What “good” vendor termination planning looks like (operationally)

Exit strategy design under concentration risk and critical ICT third-party oversight

Product evaluation: what to look for in a DORA exit strategy workflow

How Dorapp can support vendor termination planning (verified capabilities)

Strengths and Challenges

Who this approach is for

Selection guide: how to evaluate your options

Frequently Asked Questions

What DORA expects from exit strategies and termination planning

DORA requires financial entities to manage ICT third-party risk across the full lifecycle, including contract design, ongoing oversight, and the ability to exit arrangements without unacceptable disruption. In practice, supervisors tend to focus on whether your institution can actually execute an exit, not whether an exit plan document exists.

Vendor termination planning is where several DORA themes converge:

Governance and accountability for ICT third-party decisions, including documented approvals and exceptions.

Contractual enforceability, including termination rights, access, audit, data return, and cooperation obligations.

Operational feasibility, including transition steps, data migration, and internal capabilities.

Evidence quality, including an auditable trail of assessments, decisions, and periodic review.

DORA entered into full application on 17 January 2025. That timing matters because many institutions are now moving from “program build” to “supervisory defensibility,” where gaps in exit readiness can surface during audits, onsite inspections, and thematic reviews.

Exit strategy work also sits inside the broader dora third party risk operating model. If your vendor inventory, service mapping, and contract data are incomplete, termination planning usually becomes speculative.

DORA exit strategy requirements: the obligations that drive evidence

DORA’s exit strategy expectations are primarily anchored in the ICT third-party risk management framework and contractual requirements. While the exact supervisory focus may vary by competent authority and entity type, exit readiness typically needs to be demonstrable for material ICT dependencies.

Key DORA anchors to consider

DORA Article 28 (ICT third-party risk management) sets the requirement for a sound, comprehensive, and well-documented framework, including lifecycle controls that logically extend to exit planning.

DORA Article 30 (contractual arrangements) establishes minimum contractual content for ICT services, which commonly includes termination rights and provisions that make exit practically executable (for example data return, cooperation, and service continuity obligations).

DORA Article 29 (key principles) emphasizes governance, risk-based approach, and proportionality. Exit planning is normally expected to scale with criticality, complexity, and concentration risk.

Terminology matters. A “vendor” in procurement language may not match how DORA expects you to model an dora ict service provider, the ICT service, and the supported business function. For exit strategies, this mapping determines what you are exiting, what must continue, and which downstream dependencies you may need to unwind.

What supervisors typically test (practical interpretation)

Whether termination rights exist for relevant ICT services, and whether they are aligned with your risk appetite and resilience requirements.

Whether you have defined exit triggers (for example material breaches, sub-outsourcing issues, persistent service failures, insolvency indicators, or unacceptable risk levels).

Whether you can evidence feasibility: data portability, transition period planning, access to logs and records, and staffing and technical readiness.

Whether exit planning is connected to your vendor oversight cadence, not treated as a one-time procurement artifact.

This is where many institutions underestimate effort. A DORA exit plan that is not maintained tends to fail precisely when needed, because vendor architectures, sub-outsourcing chains, and internal systems change faster than policy documents.

DORA Article 28 in practice: what to document, maintain, and test for exit readiness

Under Article 28 of DORA, exit readiness is typically treated as an outcome of your ICT third-party risk management framework, not a standalone document stored in procurement files. What the regulation actually requires is that your framework covers the full lifecycle of ICT third-party arrangements supporting critical or important functions, and that it is “sound, comprehensive, and well-documented.” In most institutions, the defensible way to show this is to define what “exit ready” means, then operationalize it with evidence-producing controls.

What “well-documented” exit readiness typically looks like

A defined scope for which arrangements require exit planning depth, typically anchored to critical or important functions and risk-based tiering.

Documented exit triggers and decision criteria, including how risk signals from ongoing monitoring could lead to an exit decision.

A maintained list of prerequisites for executing the exit, such as data export mechanisms, identity and access dependencies, encryption key handling, and operational runbooks.

Named owners for plan maintenance and for execution roles during a transition, including who approves exceptions and who confirms readiness.

Evidence of periodic review and updates, so exit plans do not drift from actual architectures and sub-outsourcing dependencies.

Testing expectations: what you can realistically evidence

DORA does not prescribe one universal “annual exit test” requirement for every vendor. Still, supervisors may expect that critical exit plans are not purely theoretical. From a practical standpoint, testing can take several forms, depending on feasibility and proportionality:

Tabletop exercises that simulate termination triggers and transition decisions, including communications, governance, and control continuity.

Data portability drills, such as extracting datasets, validating completeness and integrity, and measuring elapsed time against your transition assumptions.

Partial migrations or pilots for key components, where a full exit is impractical but you can validate critical dependencies and restore procedures.

Operational readiness checks tied to contract renewal, material change, or significant incidents, evidenced through approvals and remediation tickets.

Testing is where many compliance teams overlook a key point: you can often evidence readiness without “switching off” a production service. The goal is to show that exit planning is credible, current, and owned, subject to your institution’s risk profile and supervisory expectations.

This content is for informational purposes only and does not constitute legal advice. Financial institutions should seek qualified regulatory counsel for institution-specific DORA compliance guidance.

DORA Article 30 contractual provisions that make exit strategies executable

Article 30 of DORA is where exit strategies and termination planning become tangible, because it sets minimum contractual content for the use of ICT services. In practice, an exit strategy fails when the contract does not give you the rights, cooperation, and operational access needed to execute a transition without unacceptable disruption.

Consider this: an “exit plan” that depends on vendor goodwill is difficult to defend under supervisory scrutiny. Your contract is typically the mechanism that turns a plan into enforceable obligations, especially for ICT services supporting critical or important functions.

Contract areas that commonly determine whether exit is feasible

Clear termination rights and termination assistance, including transition periods, cooperation obligations, and responsibilities during wind-down.

Data return, portability, and deletion requirements, including format expectations, timelines, and confirmation evidence.

Access, audit, and information rights, including the ability to obtain records needed for security monitoring, incident investigations, and supervisory requests during a transition.

Sub-outsourcing conditions that prevent exit blockers, such as undisclosed subcontractors or contractual chains that limit your visibility and control.

Service continuity and resilience commitments during termination, especially where a poorly managed wind-down could create new operational resilience risks.

Linking contract provisions to your evidence pack

A common supervisory question is not “do you have the clause,” but “can you prove you can use it.” In operational terms, you typically strengthen your evidence position by linking each critical contract provision to:

a corresponding operational step in the exit plan (who invokes it, when, and with what dependencies)

a control owner and review cadence

records of negotiation outcomes, deviations, and approved exceptions

Where the contract does not meet your exit assumptions, your institution may need a remediation plan, compensating controls, or a defined exception process that is approved and documented. The exact approach could vary based on entity type, criticality, and your competent authority’s expectations.

This content is for informational purposes only and does not constitute legal advice. Financial institutions should seek qualified regulatory counsel for institution-specific DORA compliance guidance.

What “good” vendor termination planning looks like (operationally)

A defensible vendor termination plan under DORA is usually less about producing a long narrative and more about ensuring you can answer structured questions quickly, with evidence.

Minimum building blocks that make exit plans executable

Service scope clarity: which ICT service is being provided, to which legal entity, for which business process, and whether it supports a critical or important function.

Dependency mapping: key technical components, data flows, identity and access dependencies, and sub-outsourcing layers relevant to continuity and exit.

Termination mechanics: contractual notice periods, assistance obligations, step-in rights (if applicable), and deliverables for transition support.

Data exit and portability: format, timelines, responsibilities, and validation steps to confirm completeness and integrity after migration.

Transition path: alternate provider, internalization option, or phased migration plan including controls and testing.

Risk and control alignment: which controls must remain effective during transition (security monitoring, incident response, access management, logging, BCM/DR coverage).

Governance: named owners, approvers, and review cycle, including how exceptions are approved and recorded.

Common failure modes (worth addressing early)

Exit plan without an inventory: you cannot terminate what you cannot uniquely identify across entities, contracts, and services.

Rights without feasibility: contracts may include termination language, but data extraction, migration testing, or operational capacity is not planned.

Single point assumptions: plans assume a replacement provider exists, but procurement lead times, integration work, and security onboarding are not accounted for.

Static documents: exit strategies are written once, then diverge from reality as the vendor changes platform components or sub-outsourcing.

If your institution is still aligning the fundamentals, review dora regulation explained and the broader digital operational resilience act dora

Exit strategy design under concentration risk and critical ICT third-party oversight

Exit strategy work becomes materially more complex when concentration risk is present. DORA expects you to manage ICT third-party risk with a risk-based approach, and concentration risk is often one of the clearest reasons supervisors will challenge “we can just switch providers” assumptions.

Now, when it comes to critical ICT third-party service providers, DORA’s oversight framework gives the European Supervisory Authorities, EBA, EIOPA, and ESMA, a direct role in the oversight of designated critical ICT providers. That does not remove your exit obligations as a financial entity. In most cases, it raises the standard of evidence your institution will want to maintain for key dependencies, including realistic exit options.

How concentration risk changes exit planning assumptions

Market substitutability may be limited, particularly for hyperscale cloud, core banking platforms, or specialized market infrastructure services.

Interoperability and portability constraints can increase transition timelines, increasing the need for staged exits, dual-running, or hybrid operating periods.

Multi-entity group dependencies can create hidden coupling, where one exit decision affects multiple regulated entities and shared services.

Sub-outsourcing chains can create practical exit blockers if subcontractor visibility and cooperation are weak.

What a defensible approach can look like

For high-concentration dependencies, a defensible DORA-aligned approach often includes:

Explicitly documenting constraints and assumptions, rather than implying unlimited substitutability.

Defining realistic transition pathways, which could include internalization for limited functions, or modular replacement rather than full provider replacement.

Maintaining governance evidence that senior management understands the trade-offs, including where exit feasibility is constrained by market reality.

Aligning exit strategy depth with the criticality of the function and the institution’s impact tolerance for disruption.

Supervisory expectations and enforcement focus can vary by competent authority and entity type. You typically want legal, compliance, and operational resilience stakeholders aligned on what your institution can credibly commit to, and how that commitment is evidenced.

This content is for informational purposes only and does not constitute legal advice. Financial institutions should seek qualified regulatory counsel for institution-specific DORA compliance guidance.

Product evaluation: what to look for in a DORA exit strategy workflow

Exit strategy DORA work typically becomes operationally heavy due to scale: many ICT services, many contracts, many internal stakeholders, and frequent changes. Tooling is not mandatory under DORA, but for most financial entities, it becomes difficult to evidence consistency, review cadence, and audit trails with spreadsheets alone.

When evaluating tooling or workflow support for vendor termination planning, focus on five practical capabilities:

Data model fit for DORA: can you separate ICT providers, services, contracts, and financial entities, while keeping traceability and ownership?

Governed execution: can you run controlled workflows (intake, review, approval, rework, closure) with role-based permissions and sign-off?

Evidence and auditability: can you demonstrate who decided what, when, and based on which inputs?

Reporting readiness: can you produce consistent outputs for management and supervisors, and keep them current?

Scalability: can the approach handle annual review cycles and ad-hoc exit triggers without collapsing into email threads?

A DORA exit plan is also tightly linked to the DORA Register of Information (RoI). If your RoI reporting and taxonomy alignment are weak, your exit strategy evidence can become fragmented. For context on structured reporting and formats, see xbrl.

How Dorapp can support vendor termination planning (verified capabilities)

Dorapp is positioned as a DORA-focused platform with modular coverage across DORA pillars. Based on currently available product documentation, the strongest direct support for vendor termination planning typically comes from capabilities that structure ICT third-party records, enforce governance workflows, and maintain evidence.

Capabilities that matter for termination planning

DORApp ROI (Register of Information): a dashboard-driven way to manage ICT third-party service data across objects such as ICT Third-Party Software Providers, Contracts, and Financial Entities, supporting RoI completeness that exit planning depends on.

Automatic LEI validation and enrichment: helps normalize legal entity data and reduce inconsistencies that can break termination planning (for example misaligned entity identifiers across contracts and provider records).

Execution Governance Engine: supports controlled, auditable workflows with configurable review gates, role-based permissions, and single- or multi-user sign-off. For termination planning, this is relevant for enforcing review cadence, approvals, and exception handling.

Data import and export: import from Excel/CSV with field mapping and validation; exports can generate DORA-compliant reports as XBRL ZIP files aligned to ESA technical requirements (where configured and based on validated data).

TPRM module (Third-Party Risk Management and Questionnaire Automation): supports continuous oversight via questionnaire campaigns, review routing, risk scoring, and reporting connected to RoI records. This can support exit triggers and periodic reassessment, which are commonly inputs to termination decisions.

What this means in practice for an exit strategy workflow

In a typical operating model, you could use the RoI records as the system-of-record for “what exists” (provider, service, contract, entity), then use governed workflows and TPRM evidence as “why it is acceptable” (or why it is not). Termination planning becomes easier to maintain when the underlying service and contract inventory is kept current, approvals are traceable, and reviews happen on a schedule.

Important limitation to recognize: exit feasibility still depends on your institution’s technical architecture, procurement capacity, and contractual negotiations. Software can structure, evidence, and operationalize the work, but it does not replace legal review, supplier negotiation, or engineering execution.

To explore Dorapp directly, you can review DORApp Modules, see DORApp Functions, or discuss your termination planning workflow via Book a Demo.

Strengths and Challenges

Strengths

DORA-aligned data foundation: RoI-focused records (providers, contracts, financial entities) support the inventory discipline that termination planning requires.

Governed execution over email coordination: controlled workflows with review gates and sign-off help demonstrate accountability and reduce “who approved this?” gaps.

Audit trail support: workflow transitions and decision history can help produce defensible evidence for internal audit and supervisory review.

Data quality improvements via LEI enrichment: automatic LEI validation can reduce errors in entity identification, which often cause inconsistencies across contracts and registers.

Reporting and structured export options: XBRL ZIP export aligned to ESA taxonomy requirements can support RoI reporting readiness, which indirectly strengthens exit strategy evidence.

Implementation Considerations

Exit planning still needs institution-specific engineering input: no tool can “auto-generate” a feasible migration plan; it must be validated against your architecture, data, and operational constraints.

Process design is required: to benefit from workflow controls, you still need to define stages, roles, and approval logic that match your governance and three lines of defense model.

Data migration and normalization effort: importing legacy vendor and contract lists typically requires cleanup, deduplication, and mapping decisions to avoid perpetuating inconsistent records.

Module availability timing: some Dorapp modules are described as roadmap items (for example RMG planned Q4 2026; IM planned Q2 2026; IIS planned Q4 2026). You should validate what is available for your use case at the time of purchase.

Who this approach is for

This exit strategy DORA approach is most relevant for financial entities with material dependence on ICT TPPs, especially where services support critical or important functions and where supplier changes are plausible (cloud migrations, platform consolidations, outsourcing restructures).

Roles that typically benefit most include:

Compliance officers building evidence for DORA Article 28 and DORA Article 30 expectations

ICT third-party risk managers operationalizing periodic review cycles and exit triggers

CISOs and operational resilience leaders who need visibility into feasibility constraints and transition risks

Procurement and vendor management teams who must keep contracts, notices, and assistance obligations consistent

The approach can be applied proportionately. Smaller institutions may focus on a narrower set of critical vendors, while larger groups may require more structured governance, reporting, and segregation of duties.

Selection guide: how to evaluate your options

Choosing how to operationalize DORA termination planning is usually a decision between (1) spreadsheets and document repositories, (2) a general-purpose GRC platform configured for DORA, or (3) a DORA-focused platform. The “right” choice depends on your scale, governance complexity, and how often your third-party landscape changes.

1) Regulatory alignment and evidence defensibility

Exit strategy DORA is rarely tested as a standalone artifact. It is evaluated as part of your third-party risk governance, contract management, and resilience controls. Look for whether your approach can:

link exit plans to the underlying ICT service and contract records

show approvals, exceptions, and periodic review history

produce consistent evidence for audit and supervisory requests

2) Ability to maintain an accurate RoI-driven inventory

Termination planning depends on “what exists” being correct. If provider identities and legal entities are inconsistent, exit plans can be tied to the wrong contract or the wrong regulated entity. Evaluate:

how provider, contract, and financial entity records are modeled

data validation support, including normalization and unique identifiers (such as LEI)

how changes are governed and logged

3) Workflow controls: approvals, review gates, and accountability

DORA supervisors commonly expect clear ownership and governance. If exit plans can be updated without review or approval, evidence can be challenged. Evaluate whether you can enforce:

role-based permissions and segregation of duties

mandatory fields and evidence checks before sign-off

single- or multi-approver sign-off aligned to your governance model

4) Operational scalability across many ICT TPPs

Exit planning is continuous work. Vendor landscapes shift, sub-outsourcing changes, and risk signals emerge. Evaluate how you will run periodic reassessments and keep termination readiness current:

annual or periodic review cycles with reminders and escalations

ability to attach assessments and questionnaires to the same provider record

reporting that can identify “high risk with weak exit feasibility” cases

5) Reporting outputs for management and supervisors

Exit strategy maturity is often reported upward. You may need consistent KPIs (coverage, overdue reviews, unresolved exit blockers) and regulator-ready outputs. Consider:

board-level reporting templates and recurring reporting cadence

ability to export structured data (for example RoI outputs in XBRL ZIP format, where applicable)

traceability from summary reporting down to evidence points

Dorapp fit (practitioner view)

If your primary pain is RoI data quality and governance around ICT third-party records, Dorapp’s RoI module and LEI enrichment can be a practical foundation. If your pain is cross-functional execution, the Execution Governance Engine’s review gates and sign-off can help you evidence termination planning governance. For a consultative walkthrough focused on termination planning workflows, consider Book a Demo or start with a limited-scope rollout and expand by module as your program matures.

Frequently Asked Questions

What does “exit strategy DORA” mean in simple operational terms?

It typically means being able to end or transition an ICT third-party arrangement without unacceptable disruption, especially for services supporting critical or important functions. This goes beyond having termination clauses. You generally need an executable plan, defined triggers, named owners, governance approvals, and evidence that the plan is current and feasible for your technical and operational reality.

Are exit plans explicitly mandatory under DORA?

DORA’s ICT third-party risk management and contractual requirements (notably DORA Article 28 and DORA Article 30) drive expectations that financial entities can exit arrangements safely and in a controlled way. Whether your competent authority expects a formal “exit plan document” for every vendor may depend on proportionality, criticality, and risk. Legal counsel can help interpret requirements for your entity.

How do DORA termination rights relate to exit feasibility?

Termination rights are necessary but not sufficient. You might have a contractual right to terminate, but still be unable to migrate data, replace a service within realistic timelines, or maintain controls during transition. DORA-aligned termination planning usually connects legal rights to operational steps, including data return, cooperation obligations, transition assistance, and internal capability to execute.

Which vendors should have the most detailed exit planning?

In most cases, the most detailed planning is expected for ICT services that support critical or important functions, or where concentration risk, complexity, or substitutability concerns are elevated. Financial entities often tier vendors and services, then apply proportionate exit planning depth. The tiering logic and evidence should be consistent with your DORA third-party risk framework.

How often should vendor exit strategies be reviewed?

DORA does not prescribe one universal cadence. A common approach is periodic review aligned to vendor criticality, contract renewal cycles, and risk signals (for example material incidents, changes in sub-outsourcing, or persistent SLA failures). What matters most is that your review approach is risk-based, documented, and evidenced through completed reviews and approvals.

What evidence should we retain to prove termination readiness?

Typically useful evidence includes: service and contract scope records, exit triggers, approvals and sign-offs, risk assessments that reference exit feasibility, documented transition steps, data portability requirements and tests (where applicable), and records of vendor cooperation commitments. Auditability is often strengthened when evidence is linked to the underlying provider and contract records.

How does the DORA Register of Information affect exit strategies?

The RoI is not an exit plan, but it is often the backbone for proving what ICT services exist, which entities are impacted, and which contracts govern them. If RoI data is incomplete or inconsistent, exit planning becomes hard to operationalize and hard to defend. Structured RoI outputs (often aligned to ESA formats) can support supervisory interactions when exit readiness is questioned.

Can Dorapp replace legal review of termination clauses?

No. Tooling can help structure vendor and contract records, run governance workflows, and maintain evidence, but it does not replace legal analysis of contractual enforceability or negotiation strategy. Financial entities typically still need qualified legal counsel to confirm that termination rights, assistance obligations, audit rights, and other clauses meet DORA expectations and local supervisory practice.

Does Dorapp support XBRL reporting for the RoI?

Based on available product documentation, Dorapp can generate DORA-compliant reports and export them as XBRL ZIP files aligned with European Supervisory Authorities (EBA, ESMA, and EIOPA) technical requirements, assuming your underlying data is validated and mapped correctly. You should verify the exact scope of taxonomy support and reporting outputs during product evaluation.

What is a realistic starting point if our exit planning is immature?

A pragmatic start is usually: (1) clean up and stabilize your inventory of ICT providers, services, contracts, and regulated entities, (2) tier services by criticality and substitutability, (3) define a standard exit plan template with required fields, (4) implement a controlled review and approval workflow, and (5) run a pilot on a small set of critical ICT services before scaling.

What are the key phases of a DORA-aligned ICT exit plan?

Many institutions structure exit planning into phases such as: (1) scope and dependency confirmation, (2) trigger definition and decision governance, (3) transition design (replacement, internalization, or staged migration), (4) data portability and security control continuity planning, (5) execution and dual-running (where required), and (6) closure evidence (data deletion confirmation, access revocation, and post-exit review). The exact phase model may vary, but supervisors typically want to see that planning is actionable, owned, and connected to contract rights and technical feasibility.

How should we define exit triggers under DORA?

Exit triggers are typically defined as events or risk conditions that could justify termination or a forced transition, such as persistent material SLA failures, material breaches, unacceptable risk reassessments, critical changes in sub-outsourcing, insolvency signals, or repeated major incidents. Under a DORA operating model, triggers are usually documented, tied to monitoring, and connected to governance approvals. The appropriate trigger set can vary by institution, service criticality, and supervisory expectations.

Do we need to test exit strategies annually under DORA?

DORA does not set a single universal requirement that every exit strategy must be tested annually. Still, competent authorities may expect periodic testing or validation for arrangements supporting critical or important functions, subject to proportionality. Testing can be tabletop, data portability drills, partial migrations, or other evidence-backed validations that demonstrate feasibility without necessarily executing a full termination.

How do exit strategies apply to intra-group outsourcing?

DORA’s ICT third-party risk requirements can apply to intra-group arrangements where an ICT service supports critical or important functions. In those cases, exit planning may still be expected, but it often looks different. For example, the “exit” could be shifting to an alternative group provider, internalizing the service, or restructuring shared services. The defensibility usually depends on documented governance, feasibility evidence, and contractual or documented arrangements that support cooperation and continuity.

Key Takeaways

DORA exit strategy expectations usually require operational feasibility, not only contractual wording.

Termination planning becomes defensible when it is tied to accurate provider, service, contract, and entity records.

Governance controls (review gates, approvals, audit trails) are often the difference between a “plan” and evidence of resilience.

Risk-based proportionality matters: focus depth on ICT services supporting critical or important functions.

Tooling can reduce manual overhead, but it does not replace legal review or technical migration capability.

Conclusion

Vendor termination planning under DORA is best treated as a maintained operational capability: accurate inventories, realistic transition steps, clear triggers, and consistent governance evidence. For most financial entities, the main risk is not that termination language is missing, but that exit plans cannot be executed or evidenced under pressure, after vendor change, incident stress, or supervisory challenge.

If you are looking to operationalize exit strategy workflows with stronger data quality and governance controls, you can explore Why DORApp and the platform’s module options at DORApp Modules. For a practical discussion focused on your third-party landscape and exit planning priorities, use Book a Demo to speak with the Dorapp team.

Disclaimer: This article is intended for informational purposes only and does not constitute legal advice. DORA compliance obligations vary depending on the classification and size of your financial institution. Consult qualified legal or regulatory counsel to assess your specific obligations under the Digital Operational Resilience Act and applicable regulatory technical standards.