01Technical questions
Your team can direct questions about the agreed application scope to the named contact.
Service scope
Choose the right support for your application
Support refers to the agreed system configuration. We establish which application and connections are supported and who coordinates on your side.
02Defect handling
Reported defects are investigated using the affected steps and their impact.
03Maintenance
Changes and updates are prepared and coordinated within the agreed scope.
04Operational handover
Documentation and training support the people responsible for looking after the application.
Responsibilities
Clear contacts and processes for support
Incident handling needs a clear reporting channel, named contacts and an understandable account of the impact. Before service begins, we define who receives a report, who leads the technical analysis and when other responsible parties are involved. The workflow distinguishes a user question, a software defect and an interruption to operation.
A report needs a responsible recipient.
Response time, recovery target, status communication and escalation are described separately. Prompt acknowledgement is not a commitment to resolve an incident by the same deadline.
Support agreement
Put the scope in writing
The agreement describes the specific services. It also defines which tasks remain with your team or an infrastructure operator.
| Item | Agreement |
|---|---|
| Supported system | Application, version and included connections |
| Availability | Contact channel and agreed service hours |
| Prioritisation | Classification by operational impact |
| Response targets | Targets and when measurement starts for each agreed category |
| Changes | Maintenance scope and approval of additional work |
The service scope refers to the agreed system.
Changes to connections or additional modules are discussed before they are added to the support scope.
Change coordination
Incident handling
Bring the necessary information together early
Initial technical information identifies the affected system, start time, known impact and current response status. Investigation adds a timeline, log extracts, workarounds, recovery status and root-cause findings. This supports the institution’s internal decisions and, where applicable, DORA incident reporting. We agree the information route and responsible recipients before operation.
| Step | Your institution | T-NEX |
|---|---|---|
| Report | Describe the affected workflow and time | Receive the report through the agreed channel |
| Investigate | Provide required information and access | Investigate the cause within the supported scope |
| Check the change | Assess the result in the affected workflow | Document the fix and technical checks |
| Close | Record internal decisions | Report the outcome and remaining tasks |
Institutional decisions
Your institution decides the business impact of an incident and which internal or external reports follow.
Monitoring
Agree monitoring for specific needs
Monitoring can be part of an operating engagement. The monitored components and handling of alerts are defined for that scope. A technical alert leads to action only when a supported handling process has been agreed.
Service hours
Plan availability around the operation
Service hours and response targets are agreed for your application. We consider when it is used and which workflows depend on it.
Service boundary
New features and changes to third-party systems are included in support only when explicitly agreed.
Related services
Coordinate application support and hosting
Support concerns the supported application. Hosting covers the agreed technical operation; different parties may hold these responsibilities.
| Area | Support | Hosting |
|---|---|---|
| Focus | Application questions and defect handling | Infrastructure and agreed operating tasks |
| Basis | Supported system scope and service agreement | Operating model and infrastructure agreement |
Plan operationsSecure Hosting
About support
Frequently asked questions
Plan support for your application
Tell us which application you use and its main operating hours. We will discuss the required support scope.
Discuss supportContact arrangements and services are recorded for the specific operation.
Sources & further reading
In-depth articles
- DORA for financial entities: duties and implementation
DORA since 17 January 2025: scope, ICT risk, incident reporting and third parties, with primary sources and implementation checks.
- DORA register of information: content and submission
The DORA register of information: record contracts, identifiers and supply chains using the EU templates and BaFin requirements.
- Ninth MaRisk amendment: changes and implementation
The ninth MaRisk amendment has applied since 30 June 2026. Changes from the previous version and implementation checks for institutions.
- NIS2 vs DORA: what applies to banks and their IT?
NIS2 and DORA for banks: compare scope, BSI registration, reporting deadlines and ICT providers, with references to Germany’s BSIG.