IT and AI consulting
T-NEX advises banks and insurers on software projects and GRC processes, with functional specifications, technical planning and an agreed implementation scope.
Explore serviceFor 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.
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.
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.
| Question | MaRisk AT 9 | DORA Articles 28–30 |
|---|---|---|
| Basis of assessment | Transfer of institution-related activities or processes within AT 9 scope | Contractual use of ICT services by an in-scope financial entity |
| Risk classification | Material or non-material outsourcing | Support for a critical or important function |
| Contract requirements | Particular requirements for material outsourcing | Baseline ICT clauses plus additional clauses for critical or important functions |
| Common error | Assessing materiality solely by contract value | Examining only services already classified as material outsourcing |
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.
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.
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.
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 step | Question | Evidence |
|---|---|---|
| Trigger and decision | Who can initiate the switch, and by when? | Record of the escalation exercise |
| Data export | Are data, history and required configurations complete? | Reconciliation of record counts, totals and versions |
| Target operation | Can the alternative environment produce an agreed report? | Reproducible output and business acceptance |
| Transition and closure | Do access, switching and withdrawal of old permissions work? | Execution log, outstanding issues and closure decision |
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.
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.
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.
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.
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.
No. Responsibility for proper organisation and risk management remains with the institution. Any relief needs to be established under the framework that actually applies.
T-NEX advises banks and insurers on software projects and GRC processes, with functional specifications, technical planning and an agreed implementation scope.
Explore service
From uploading a regulation to issuing an audit report: T-NEX Compliance connects requirements, assessment, remediation and progress monitoring.
Learn more
Connect approvals and recurring tasks in one application. T-NEX develops workflow solutions using existing platform components.
Explore serviceEntities, international team locations, data access and operational responsibilities: concrete topics for assessing a proposed engagement with T-NEX.
Learn more