DORA Subcontracting Requirements (2026 Guide)

You have your ICT provider inventory in place, your core contracts mapped, and your Register of Information is finally starting to look usable. Then legal asks a simple question: who is your provider actually relying on underneath? For many compliance teams, that is the moment DORA subcontracting requirements stop feeling theoretical. The issue is not just whether a vendor uses subcontractors. It is whether you can identify them, assess the operational impact, and show that your governance extends beyond the first contract in the chain.

That matters more in 2026 because supervisors are moving from initial readiness to proof of compliance. Under DORA, third-party oversight is not limited to your direct ICT provider. It also includes how critical or important functions may depend on subcontracting chains, including cloud, hosting, support, security, and data-processing dependencies. If you need a broader foundation first, it helps to review what is dora and how the digital operational resilience act dora frames third-party risk as part of operational resilience, not just procurement paperwork.

DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, helping teams turn complex obligations into structured workflows and technically acceptable reporting outputs.

What subcontracting means under DORA

Why chain management matters more than many teams expect

What the rules focus on in practice

DORA RTS subcontracting: what the final draft means operationally

How to assess subcontracting chains without getting lost

Subcontractor selection criteria: setting defensible, risk-based thresholds

Register and reporting impact

Common mistakes that create avoidable risk

What changed in 2026

Frequently Asked Questions

Key Takeaways

Conclusion

What subcontracting means under DORA

At a practical level, subcontracting under DORA refers to situations where your ICT third-party service provider relies on another party to perform parts of the service it delivers to you. That can include infrastructure hosting, software development, support operations, managed security, data storage, incident response, or downstream cloud services.

Here’s the thing: a dora subcontractor is not automatically a problem. Most institutions depend on layered service models. The real question is whether that subcontracting affects the continuity, availability, security, or recoverability of an ICT service that supports your business, especially a critical or important function.

If you are mapping this topic for the first time, it helps to pair it with your broader understanding of dora third party risk and the role of the dora ict service provider in the wider control chain.

It is about operational dependency, not just legal terminology

Many contracts use different language, such as sub-processor, subservice organization, affiliate provider, outsourced support partner, or cloud infrastructure partner. From a regulatory standpoint, naming differences do not remove the underlying dependency. If the downstream party materially supports the service you rely on, your institution may still need visibility and governance over that relationship.

That is why DORA chain management is more than contract review. It sits at the intersection of legal, procurement, ICT, security, continuity, and compliance.

Common subcontracting models you will see in ICT (and how oversight differs)

Most subcontracting discussions become easier once you categorize what you are actually looking at. In ICT delivery, subcontracting typically shows up in a few repeatable models, and each one tends to drive different resilience questions and different evidence.

From a practical standpoint, you will often see these three patterns:

Infrastructure hosting and platform dependencies: where your provider relies on hosting, cloud infrastructure, content delivery, DNS, or core platform services to run what you bought.

Data processing subchains: where your provider uses downstream parties to store, process, analyze, transmit, or otherwise handle data related to the service.

Specialized operational support: where your provider uses expert third parties for functions like security operations, incident response support, penetration testing support, specialized development or maintenance, observability, or 24/7 support coverage.

Now, when it comes to oversight, the difference often comes down to the type of risk that is most likely to impact you.

Infrastructure hosting and platform dependencies tend to raise availability, location, and concentration questions. If a hosting layer fails or a region is impacted, the upstream provider might be unable to deliver. Oversight artifacts that are often useful here include clarity on where the service is hosted, how failover works in practice, what recovery objectives the service is designed to meet, and what happens when the underlying platform changes.

Data processing subchains tend to raise confidentiality, integrity, and access-control questions. In these arrangements, your main concern is often who can access sensitive data, how processing is controlled, and what the downstream security posture implies for your own obligations. Useful artifacts often include data flow descriptions, access governance, and practical controls for monitoring and incident handling, rather than just naming a downstream party in an annex.

Specialized operational support tends to raise integrity, response-time, and control-of-controls questions. If a provider is outsourcing security monitoring or incident response support, you typically care about escalation paths, handoffs, coverage gaps, and whether evidence of monitoring exists. The most useful artifacts are often runbooks, escalation matrices, and proof that people actually follow a defined process during events.

One point that many institutions miss early on is terminology consistency. “Subcontractor” is often used as an umbrella term. “Sub-processor” is commonly used where data processing is in scope. “Affiliate” can describe a legal relationship but still represent a separate operational risk. DORA expectations are usually driven by operational dependency, so it helps to normalize these labels internally so your chain governance is consistent across legal, ICT, and security teams.

Why chain management matters more than many teams expect

A direct vendor can look well controlled on paper while still carrying concentration, resilience, or location risk further down the chain. In practice, many outages and service disruptions are caused not by the primary vendor itself, but by a hidden dependency in its own supply structure.

Consider this: your institution contracts with a SaaS provider for a customer onboarding tool. That provider may rely on a cloud host, an identity verification engine, a support center, a content delivery network, and an observability platform. If one of those fails, your critical process may fail too. DORA expects institutions to think through that dependency chain.

This is one reason the regulation is better understood through a broader lens of dora regulation explained, rather than treating subcontracting as an isolated procurement clause.

Critical and important functions raise the stakes

The level of scrutiny usually increases when the outsourced ICT service supports a critical or important function. In those cases, subcontracting controls, approval rights, notification rights, exit planning, and concentration analysis tend to matter much more. You do not need perfect visibility into every low-impact supplier in the chain, but you typically do need enough information to assess where operational resilience could realistically be compromised.

What the rules focus on in practice

When compliance teams talk about dora subcontracting requirements, they are usually dealing with a mix of contractual controls, governance expectations, and reporting implications. The exact interpretation may vary by institution type and national supervisory expectations, but several themes are consistent.

1. Visibility into material subcontracting

You generally need to know whether your provider uses subcontractors that materially support the ICT service. This often means identifying the subcontracted activity, the party involved, the country or region of delivery, and the relevance to service continuity or security.

2. Risk assessment before and during the relationship

Subcontracting should feed into your pre-contract due diligence and your ongoing monitoring. The reality is that many institutions do initial onboarding reasonably well, then struggle to keep change data current. Under DORA, change management is part of resilience.

3. Contractual rights and notification logic

Contracts for relevant ICT services may need to address whether subcontracting is permitted, under what conditions, what notifications are required, and whether you can object to material changes. This is where teams often look to the evolving expectations around dora rts subcontracting and related delegated standards. Based on the current 2026 framework, Delegated Regulation (EU) 2025/532 has increased attention on deeper subcontracting risk and oversight of material downstream arrangements.

4. Exit and continuity planning

If a key subcontractor fails, is replaced, or becomes unavailable, can the service still operate within your resilience tolerances? Under DORA, this means subcontracting cannot be viewed separately from continuity planning, concentration risk, and substitution strategies.

DORA RTS subcontracting: what the final draft means operationally

Many sources summarize subcontracting expectations as “have the right clauses” and “keep a list.” That is a start, but it is rarely what causes friction in supervisory discussions. In practice, the DORA RTS framing pushes institutions toward showing how subcontracting is assessed early, governed through the lifecycle, and evidenced in a way that can be reviewed.

Precontractual risk assessment needs to explicitly cover subcontracting

Here’s the thing: subcontracting risk is easiest to manage before you sign. Operationally, this typically means your due diligence should not stop at “does the provider use subcontractors.” It should also cover what is subcontracted, what the conditions are, and what the downstream dependency implies for resilience, especially where the service supports a critical or important function.

For most small business owners and entrepreneurs, vendor assessment can already feel heavy. For a regulated financial institution, the expectation is usually that the process is documented and repeatable. This often includes evidence that subcontracting is part of the precontractual assessment, not a detail discovered after onboarding when change becomes harder and more expensive.

“Entire ICT subcontracting chain” oversight is about meaningful visibility, not infinite mapping

Competitor-style checklist content often emphasizes the “entire chain,” and that phrase can sound unrealistic. The practical interpretation is usually about being able to identify and assess relevant downstream arrangements, including fourth parties where that depth is operationally relevant.

What many people overlook is that chain depth is not an academic exercise. If a provider subcontracts a material part of the service, and that subcontractor itself relies on another party for a material component, you may need visibility far enough down to understand where resilience could realistically break. In many cases, “material parts” tends to mean the components that would meaningfully affect confidentiality, integrity, availability, recoverability, incident response, or continuity if disrupted.

In other words, you are not trying to map the whole internet. You are trying to avoid blind spots where a critical dependency sits outside your governance model.

Controls matter, but evidence is what supervisors can test

Another pattern in 2026 is that supervisors may ask for evidence that your subcontracting controls are not just written, they are operating. That does not mean you need a perfect system, but you typically need a trail that shows decisions and monitoring actually happened.

From a practical standpoint, institutions often align controls to evidence in a few concrete areas:

Documented subcontracting conditions: a clear statement of what the provider can subcontract, what requires notice, and what triggers objection or approval paths. Evidence could be contract language, annexes, and the internal approval memo that references them.

Monitoring cadence: a defined frequency for reviewing subcontracting changes for higher-risk arrangements. Evidence could be review meeting notes, completed questionnaires, periodic attestations, or ticketed reviews with timestamps.

Change controls: a practical way to capture subcontractor changes, assess impact, and decide what to do. Evidence could be change notifications, your assessment record, and whether the Register of Information was updated.

Escalation paths: clarity on who is notified when a downstream change affects resilience, and how you escalate internally. Evidence could be an escalation matrix, incident playbooks, and proof that owners were engaged when needed.

This is also where governance becomes cross-functional. Legal may own the clause library, but ICT, security, and continuity teams often own the facts that make those clauses meaningful. If your institution operates across multiple jurisdictions, it is also worth remembering that supervisory expectations may vary, so it is sensible to validate interpretations with qualified legal and compliance advisors.

How to assess subcontracting chains without getting lost

One of the biggest mistakes institutions make is trying to document every downstream dependency at the same depth. That usually creates a lot of noise and very little usable control. A better approach is to apply a layered, risk-based review.

Start with service criticality

Ask which ICT services support critical or important functions. Those services deserve the deepest chain analysis. Lower-risk services may still need oversight, but usually not with the same granularity.

Then identify material dependencies

Focus on subcontractors that could affect confidentiality, integrity, availability, operational continuity, testing, recovery, or incident response. Think of it this way: if this downstream provider had a serious disruption, would your institution care operationally, not just contractually?

Use a practical review checklist

What part of the ICT service is subcontracted?

Does the subcontractor support a critical or important function?

Where is the service delivered and where is data processed or stored?

What notification and approval rights exist for changes?

Could the subcontracting arrangement increase concentration risk?

What happens if the subcontractor fails or is replaced?

Is there sufficient auditability and evidence of oversight?

Platforms like DORApp can streamline Register of Information work through structured imports, enrichment, validation, and compliant report generation, which may help when subcontracting data needs to be maintained over time instead of recreated before deadlines.

From a practical standpoint, DORApp’s modular setup is especially relevant here. Its ROI module, TPRM module, audit trail, automated workflows, configurable reports and analytics, and automatic LEI validation and enrichment are all confirmed parts of the platform data available today. That may help institutions turn subcontracting oversight into a repeatable operating process rather than a one-time spreadsheet exercise.

Subcontractor selection criteria: setting defensible, risk-based thresholds

Many teams have a high-level definition of “material subcontractor,” but struggle to apply it consistently. The result is usually either over-control, where everything becomes “material,” or under-control, where real dependencies are missed because the criteria are vague.

A more defensible approach is to define selection and classification criteria that are tied to operational impact. Then apply them consistently during due diligence and whenever subcontracting changes.

What makes a subcontractor “material” in a DORA context

Materiality is often less about the subcontractor’s size and more about what the subcontractor does in your service chain. In most cases, the decision comes down to a handful of drivers:

Service criticality: whether the subcontracted component supports an ICT service linked to a critical or important function.

Data sensitivity and access: whether the subcontractor processes sensitive data, has privileged access, or could affect confidentiality or integrity.

Availability impact: whether the subcontractor’s failure could cause an outage, major degradation, or breach of resilience tolerances.

Substitutability: how difficult it would be to replace the subcontractor or reroute the dependency within acceptable timelines.

Concentration and systemic dependency: whether multiple critical services depend on the same downstream party, region, or technology layer.

Location and delivery footprint: where the service is delivered, where data is processed or stored, and whether cross-border complexity increases oversight needs.

These criteria can be defined without turning your process into legal advice or an exhaustive compliance checklist. The goal is internal consistency, so different teams do not make different calls on the same pattern.

A simple tiering approach that teams can actually run

Consider this: you do not need a perfect scoring model to be consistent. Many institutions use a tiering approach that is simple enough to operate and clear enough to defend.

One common structure is:

Tier 1 (high impact): subcontractors supporting critical or important functions, or handling sensitive data, or creating high availability impact. These often justify stronger contractual controls, stronger change management, and enhanced monitoring cadence.

Tier 2 (moderate impact): subcontractors that are operationally relevant but have lower criticality or easier substitution. These often justify notification requirements and periodic review, without the same depth of control.

Tier 3 (low impact): subcontractors with limited operational impact and low data exposure. These are often tracked for completeness but governed with lighter-touch oversight.

What changes by tier is typically not just “how much you document,” but what rights and processes you expect to work in practice, such as notification timing, objection logic, auditability, and review cadence. Institutions should calibrate this to their risk appetite and supervisory context, and validate the final approach with their internal compliance and legal teams.

Align criteria with internal ownership, or the model will fail

Selection criteria often look good on paper, then break down because no one owns the operating steps. The reality is that subcontractor classification is rarely only a legal review.

For most institutions, it works better when ownership is explicit across functions:

Procurement typically owns vendor onboarding gates and ensures required inputs are collected.

ICT and architecture often understand real dependency and substitutability, including technical choke points.

Security often owns access risk, monitoring expectations, and incident-handling requirements.

Continuity and resilience often owns tolerance alignment, exit feasibility, and recovery assumptions.

Compliance and legal typically own policy alignment, contractual enforceability, and evidence expectations.

If those owners are not mapped, the institution may still collect subcontractor names, but it will struggle to demonstrate governance. A good sign of maturity is when the institution can explain who decides materiality, who reviews changes, and how those decisions feed into the Register of Information and ongoing monitoring.

Register and reporting impact

Subcontracting chain management affects more than vendor governance. It also affects data quality in your Register of Information and the accuracy of supervisory reporting. The first DORA Register of Information submission deadline was 30 April 2025, and in 2026 many institutions are dealing with the next-stage challenge: proving that the register is complete, current, and governable.

What many people overlook is that reporting quality depends on source data discipline. If your primary provider record is clean but downstream chain data is vague, inconsistent, or buried in annexes, your reporting and risk analysis may still be weak. This matters even more where submission logic touches structured formats such as xbrl.

DORApp uses a proprietary relationship-based data model and supports DORA reporting exports, which is relevant for institutions that need to translate operational vendor data into regulator-friendly structures. That is different from saying the regulation requires a specific platform. It does not. But it does require institutions to maintain reliable information about ICT third-party arrangements, including relevant dependencies.

If you want more context on the broader topic categories, Dorapp’s DORA Fundamentals section and related coverage of DORA Pillars Explained: Complete Breakdown (2026) can help frame subcontracting inside the wider DORA operating model.

Common mistakes that create avoidable risk

Subcontracting oversight tends to break down in familiar ways. Usually, the issue is not lack of effort. It is fragmented ownership and inconsistent data.

Assuming the primary vendor owns all the risk

Your provider may manage its vendors, but your institution still needs enough visibility to assess resilience exposure. You cannot fully outsource accountability.

Treating subcontracting as a legal annex only

Legal clauses matter, but they are only one part of the picture. Security, architecture, continuity, and operational teams often hold the information that makes those clauses meaningful.

Capturing chain data once and never revisiting it

Subcontracting changes over time. Cloud regions change, support providers change, and acquisitions create hidden shifts in service delivery. In practice, this means annual refresh alone may not be enough for higher-risk arrangements.

Not linking chain data to board-level decisions

Supervisors increasingly care about whether institutions can evidence governance, not just collect records. Audit trails, review gates, and documented decision rationale matter more in 2026 than they did during early implementation.

With features such as automated workflows, audit trail visibility, reports and analytics, and configurable review processes across modules, DORApp is designed to help teams work with imperfect real-world data while improving control over time.

What changed in 2026

The shift in 2026 is not that subcontracting suddenly became important. It is that supervisors are now better equipped to test whether institutions can actually evidence chain oversight. ESA work on cross-referenced ICT registers, the designation of Critical Third-Party Providers in November 2025, and broader supervisory attention on concentration and downstream dependencies have all raised the bar.

Under DORA, this means your institution may need to show not only that it has a policy on subcontracting, but also that it can identify material downstream dependencies, assess their impact, and maintain current records. That is a different standard from simply having contract language on file.

For teams still building maturity, a practical next step is to prioritize the top tier of ICT services that support critical or important functions, review material subcontracting exposures there first, and then expand the control model outward. If you want more regulatory context, Dorapp readers may also find DORA European Commission Timeline and History (2026) useful for understanding how the framework has developed.

Explore how DORApp can support your DORA compliance journey with a 14-day free trial, or book a personalized walkthrough at https://dorapp.eu/book-demo/ if you want to see how modular workflows can support chain management in practice.

Disclaimer: The information in this article is intended for general informational and educational purposes only. It does not constitute professional technical, legal, financial, or regulatory advice. Website performance outcomes, platform capabilities, and business results will vary depending on your specific circumstances, goals, and implementation. Always evaluate tools and platforms based on your own needs and, where relevant, seek professional guidance.

This article is for informational purposes only and does not constitute financial, legal, or regulatory advice. DORA compliance requirements may vary based on your institution type, size, and national regulatory framework. Content referencing regulated industries is provided for general context only and should not be interpreted as legal, regulatory, compliance, or financial advice. If you operate in a regulated sector, always consult qualified financial, legal, and compliance professionals for guidance specific to your situation.

Frequently Asked Questions

What are DORA subcontracting requirements in simple terms?

In simple terms, DORA subcontracting requirements are about making sure you understand and control important downstream providers used by your ICT vendors. If a direct provider relies on other parties to deliver services that affect your institution, especially services supporting critical or important functions, you may need visibility into those arrangements. The focus is usually on risk, continuity, security, governance, and contractual control, not just keeping a list of names. Institutions should assess which subcontracting arrangements are material and how they affect operational resilience.

Does DORA require full visibility into every subcontractor in the chain?

Usually not at the same depth for every case. A risk-based approach is more realistic and more defensible. You will typically need stronger visibility where the subcontractor materially supports the ICT service, handles sensitive data, affects resilience, or supports a critical or important function. Lower-impact arrangements may require lighter oversight. The goal is not infinite mapping. The goal is enough visibility to understand material dependencies, concentration issues, and service continuity implications. Institutions should define clear criteria for what counts as a material subcontracting arrangement.

What is the difference between a provider and a DORA subcontractor?

Your direct provider is the company your institution contracts with for an ICT service. A DORA subcontractor is a downstream party that your provider uses to perform part of that service. In practice, this could include hosting providers, managed support providers, software development teams, sub-processors, or security operations partners. The distinction matters because your contractual relationship is with the provider, but your operational risk may sit deeper in the chain. That is why institutions often need subcontracting clauses, notification rights, and oversight procedures that reach beyond the first layer.

How does subcontracting affect the Register of Information?

Subcontracting can affect the completeness and usefulness of your Register of Information because it adds dependency context to your direct ICT service records. If you only document the immediate provider and ignore material downstream support, your institution may miss concentration risks, location issues, or resilience weaknesses. The exact reporting treatment depends on current guidance and your institution’s scope, but from a governance standpoint, subcontracting information often improves the quality of assessments and supervisory readiness. Good register maintenance is not just about submission format. It is about whether the data reflects real operational dependency.

Are subcontracting clauses enough to satisfy DORA expectations?

No, not by themselves. Contract clauses are important, but supervisors will usually expect institutions to connect them to actual governance and monitoring. That means due diligence, change tracking, risk assessment, continuity thinking, and internal ownership. A clause that says the provider will notify you of subcontractor changes is useful, but it does not help much if no one reviews the notice or updates the underlying records. Stronger programs combine legal wording with practical operational controls, clear accountability, and evidence that decisions were reviewed and documented.

What does DORA RTS subcontracting usually refer to?

The phrase DORA RTS subcontracting usually refers to regulatory technical standards and delegated rules that clarify how institutions should manage ICT third-party and subcontracting risks in more detail. Teams often use the phrase broadly, so it is worth checking exactly which standard or delegated act is being discussed. In 2026, one relevant development is Delegated Regulation (EU) 2025/532, which increases attention on deeper subcontracting risk requirements. Because standards evolve and supervisory interpretation may differ, institutions should validate current requirements with legal and compliance advisors.

How should institutions prioritize subcontracting reviews?

A practical starting point is to rank ICT services by criticality. Review the services supporting critical or important functions first, then identify the subcontractors most likely to affect availability, data protection, recoverability, incident response, or concentration risk. After that, look at geography, substitution difficulty, and contractual control points such as notification and objection rights. This approach helps teams spend time where the resilience impact is highest. Trying to map every downstream dependency in equal detail usually slows progress and makes the control framework harder to maintain.

How can software support subcontracting chain management under DORA?

Software can help by centralizing provider data, documenting relationships, validating records, and creating workflows for review and change management. For institutions dealing with recurring register updates and cross-functional ownership, that can reduce manual effort and improve traceability. DORApp, for example, offers a modular DORA-focused environment with ROI, TPRM, audit trail, automatic LEI enrichment, and reporting capabilities confirmed in its current documentation. That does not replace legal interpretation or risk judgment, but it may support more consistent execution and better evidence across the lifecycle.

Why is subcontracting getting more attention in 2026?

Because the conversation has shifted from initial compliance to evidence of ongoing control. Regulators now have more structured reporting, better cross-checking capability, and stronger expectations around operational resilience. The designation of Critical Third-Party Providers in late 2025 and the wider focus on proof of compliance mean institutions may face more scrutiny on hidden dependencies and concentration exposure. In other words, it is no longer enough to say subcontracting is covered somewhere in policy. Teams increasingly need to show where the dependencies are and how they are governed in practice.

What is subcontracting under DORA?

Subcontracting under DORA is when an ICT provider you contract with relies on another party to deliver parts of the ICT service. The key point is operational dependency. If the downstream party materially supports the service you rely on, the subcontracting arrangement may affect your institution’s operational resilience. This can include hosting and cloud layers, support operations, security services, and data processing dependencies.

What are the requirements of a subcontractor?

In most cases, DORA does not impose requirements on subcontractors in isolation. The institution’s obligations are typically implemented through the contractual and governance framework with the direct ICT provider, including subcontracting conditions, notification logic, and oversight expectations. Operationally, institutions often expect subcontractors involved in material parts of the service to be governed through clear controls around security, continuity, incident handling, and change management. The exact requirements and how they are enforced can vary by jurisdiction and supervisory expectations, so institutions should confirm details with their legal and compliance advisors.

What are the three types of subcontracts?

In ICT service delivery, subcontracting often falls into three common types: infrastructure hosting and platform dependencies, data processing subchains (often described as sub-processors in data contexts), and specialized operational support such as security operations, incident response support, or development and maintenance. Each type tends to create different resilience risks, so it is usually helpful to categorize the subcontract early and tailor oversight to the likely impact.

What are the criteria for subcontractor selection?

A defensible, risk-based set of selection criteria typically focuses on operational impact rather than labels. Common criteria include whether the subcontractor supports a critical or important function, whether it processes sensitive data or has privileged access, the potential availability impact if it fails, how substitutable it is, whether it increases concentration risk, and where the service and data are delivered. Many institutions apply these criteria through a simple tiering model that determines when stronger controls are needed, such as enhanced monitoring cadence or stronger change notification and objection rights.

Key Takeaways

DORA subcontracting requirements are mainly about understanding and governing material downstream ICT dependencies.

The highest priority is usually subcontracting linked to services that support critical or important functions.

Good chain management combines contracts, risk assessment, operational ownership, and current Register of Information data.

In 2026, supervisors are increasingly focused on proof of compliance and evidence of real oversight, not just policy wording.

A modular platform such as DORApp may help structure data, workflows, and reporting, but institutions still need institution-specific legal and compliance judgment.

Conclusion

Subcontracting under DORA is really about visibility, judgment, and control. You do not need to map every corner of the ICT universe, but you do need a credible way to identify the downstream relationships that could affect your institution’s resilience. That means linking contract terms to actual operating processes, keeping records current, and focusing effort where service criticality and dependency risk are highest.

The institutions making the most progress are usually not the ones with the largest spreadsheets. They are the ones with a practical review model, shared ownership across teams, and enough system support to keep chain data usable over time. If you are refining your subcontracting approach, Dorapp’s DORA content is worth exploring, especially if you want a clearer path from regulation to execution. You can also explore how DORApp approaches structured Register of Information and third-party risk workflows through the platform at dorapp.eu.