Outsourcing and ICT third parties · Reviewed 11 September 2026

MaRisk AT 9 and DORA in third-party management

For every externally sourced service, an institution needs to establish what it actually receives and which framework applies. Classification as outsourcing under MaRisk differs from classification as an ICT service under DORA. That distinction determines the risk assessment, contractual requirements, registers and exit arrangements.

T-NEX GmbHFirst version: Updated: Editorial policy
In daily work

What changed with the ninth MaRisk amendment?

For outsourcing management, procurement, information security, legal teams and business departments of credit institutions in Germany.

The MaRisk version published on 30 June 2026 excludes a defined category of ICT services from AT 9. The explanatory note to paragraph 1 covers ICT services under Article 3(21) DORA that are subject to ICT third-party risk management under Articles 28 to 30 DORA. This is a specific scope exception, not a blanket exemption of every IT contract from organisational obligations.

The institution's status also matters. The current MaRisk generally addresses institutions under national supervision; significant institutions directly supervised by the ECB are excluded under AT 2.1. DORA has its own scope. For German banks, statutory obligations, particularly Section 25b KWG for outsourcing, require separate consideration where applicable. An exception in a supervisory circular does not by itself repeal statutory requirements.

Overview

Classify the service before assessing materiality

For AT 9, determine whether another undertaking performs activities or processes that the institution would otherwise perform itself. The risk assessment then establishes whether the outsourcing is material. A contract labelled support or consulting does not settle the question.

DORA covers digital and data services delivered on an ongoing basis within its ICT definition. A service previously treated as other external procurement can therefore still fall within DORA. The next question is whether it supports a critical or important function. A mixed contract may contain several services requiring separate classification.

QuestionMaRisk AT 9DORA Articles 28–30
Basis of assessmentTransfer of institution-related activities or processes within AT 9 scopeContractual use of ICT services by an in-scope financial entity
Risk classificationMaterial or non-material outsourcingSupport for a critical or important function
Contract requirementsParticular requirements for material outsourcingBaseline ICT clauses plus additional clauses for critical or important functions
Common errorAssessing materiality solely by contract valueExamining only services already classified as material outsourcing
Overview

What a useful risk assessment covers

The assessment should connect the supported business process, potential disruptions, affected data, legal risks and realistic options available to the institution. An expensive but easily replaceable service can present a different risk from a low-cost service without a short-term alternative. The impact on the institution matters.

For ICT services, DORA requires pre-contractual assessment, due diligence and consideration of concentration risk. The direct contractual provider is only part of that picture. Several applications may depend on the same cloud provider or subcontractor. Delegated Regulation 2025/532 further specifies subcontracting arrangements for services supporting critical or important functions.

A traceable decision records the available evidence, uncertain assumptions and the person accepting residual risk. Disruption assumptions should align with the business impact assessment and continuity planning. Relevant service or supply-chain changes require the assessment to be revisited.

Overview

Maintain contracts and registers from shared records

Article 30 DORA distinguishes baseline contractual provisions from additional requirements for ICT services supporting critical or important functions. Relevant subjects include service scope, service and data locations, incident assistance, cooperation with authorities and termination. Critical or important functions also require precise service targets, audit rights and transition arrangements.

The DORA register of information under Article 28(3) generally covers contractual arrangements for ICT services; its scope is not limited to critical functions. The outsourcing register under Section 25b KWG has a different legal basis and covers material and non-material outsourcing within its applicable scope. The requirements need separate analysis, but do not require isolated technical databases.

A shared contract reference can connect the service, provider, using entity, supported function, assessment, term and supply chain. Different register views can be derived from those records. The applicable official templates and reporting instructions determine which fields and supply-chain entries are required for a particular submission.

Overview

An exit strategy needs a workable alternative

For ICT services supporting critical or important functions, Article 28(8) DORA requires documented and sufficiently tested exit plans. The strategy must allow an exit without unacceptable disruption to business activities or failure to meet regulatory obligations. Contractual arrangements under Article 30(3) must support an appropriate transition.

An exit plan identifies triggers such as prolonged disruption, serious performance problems or unexpected termination. It also defines the target alternative, required data, rights to configurations, resources, cost assumptions, timetable and decision-makers. Restoring operations with the existing provider is a different case from moving to an independent solution.

For material non-ICT outsourcing, the relevant MaRisk provisions on options and exit strategies need to be considered. Any group-related relief under AT 9 must not be transferred automatically to DORA contracts. Group membership does not remove a technical dependency.

Overview

What proportionate exit testing can look like

The fictional example below concerns a reporting service supporting a critical or important function. It describes possible test steps rather than a universal prescribed test method. Scope and depth should reflect criticality, substitutability and the potential interruption period. A tabletop exercise alone does not demonstrate that data migration works.

Tests need measurable acceptance criteria. These can include complete business data, functioning permissions and the ability to produce an agreed report from exported data in the target environment. Where steps were only simulated, that limitation should be recorded. Gaps need an owner, a remediation deadline and a subsequent demonstration that they have been resolved.

Test stepQuestionEvidence
Trigger and decisionWho can initiate the switch, and by when?Record of the escalation exercise
Data exportAre data, history and required configurations complete?Reconciliation of record counts, totals and versions
Target operationCan the alternative environment produce an agreed report?Reproducible output and business acceptance
Transition and closureDo access, switching and withdrawal of old permissions work?Execution log, outstanding issues and closure decision
Overview

Monitoring should reveal changes

Contracts change during their life. A new data location, additional subcontractor, changed service hours or unsuccessful exit test may require a new assessment. The responsible teams therefore need clear notification routes and a connection between contract changes, risk assessments, registers and corrective actions.

Management reporting should show dependencies that require decisions: services that are difficult to replace, recurring disruptions, concentrations and overdue remediation. A provider certificate does not automatically answer every question about the actual service purchased. European designation of a provider as a critical ICT third party also does not replace the institution's own risk management.

Overview

Where T-NEX can support the workflow

A practical starting point is to connect the contract inventory, services, risk assessments and open actions. T-NEX can work with your institution to structure responsibilities and approvals and implement the required data flows and reports. The intended business case determines whether existing components fit or an extension is required.

For register preparation or an exit workflow, the engagement explicitly defines data scope, technical handovers and acceptance criteria. This does not imply that a DORA submission export or regulatory approval is already available. The supplier must also provide the information your institution needs for its own third-party assessment.

FAQ

Frequently asked questions

Is material outsourcing the same as a critical or important function?

No. The terms belong to different frameworks and assessment methods. An existing MaRisk assessment is useful input, but does not replace classification of the function and its ICT support under DORA.

Does the register of information include only critical ICT services?

No. Article 28(3) DORA generally covers contractual arrangements for the use of ICT services. Services supporting critical or important functions attract additional information and requirements.

Must exit testing shut down production?

DORA does not prescribe a universal full production switch for every test. Testing should provide appropriate evidence that the plan is executable. Technical component tests, migration exercises and organisational exercises should be combined according to the actual risk.

Does using an intra-group provider remove the institution's responsibility?

No. Responsibility for proper organisation and risk management remains with the institution. Any relief needs to be established under the framework that actually applies.

Related options

You may also be interested in these.

T-NEX Compliance: Assess gaps

T-NEX Compliance

From uploading a regulation to issuing an audit report: T-NEX Compliance connects requirements, assessment, remediation and progress monitoring.

Learn more