Last updated: 2026-11-06
The obligations that apply to all groups under the simplified framework, with an evidence matrix for each article, are set out on our page on DORA Article 16. This page covers what factoring and finance leasing firms, as part of the institutions under Section 1a(2a) of the German Banking Act (KWG) (here: KWG group), actually have to decide. All examples refer to the fictitious “Muster-Factoring GmbH”, whose classification record is on the page on DORA applicability. For a leasing firm the same pattern applies, with functions such as contract conclusion, contract administration and collection of lease payments.
1. Why does DORA affect factoring and leasing firms, and which framework applies?
Because the German Financial Market Digitalisation Act (FinmadiG) extended the scope nationally: under Section 1a(2a) KWG, DORA and the Level 2 acts apply to all institutions not already covered by Article 2 DORA as if they were CRR credit institutions. BaFin expressly names factoring and finance leasing firms. The legal position of the group in detail is set out on the page on DORA Article 16.
| When | What applies | Provision |
|---|---|---|
| since 17 January 2025 | handling, classification and reporting of ICT-related incidents (Chapter III DORA), the only DORA obligations until 2027 | Section 65a(3) sentence 2 KWG, BaFin FAQ 13 |
| until 31 December 2026 | BAIT in full, including the information security officer and IT emergency management | BaFin news of 9 January 2025 |
| from 1 January 2027 | simplified framework under Article 16 and Title III of RTS (EU) 2024/1774, plus Articles 28 to 30 (not for microenterprises of the group) and, on our reading, the testing programme under Articles 24 and 25 | Section 1a(2a) in conjunction with Section 65a(3) KWG |
| never | full framework, Articles 5 to 15, threat-led penetration testing (TLPT) | Section 1a(2a) sentence 2 nos. 1, 2 KWG |
We classify the testing programme under Articles 24 and 25 as our reading and recommend planning for it as a precaution. The reasoning and the counter-argument are on the page on DORA Article 16. In addition, MaRisk (BaFin’s Minimum Requirements for Risk Management) applies, to financial services institutions only as far as warranted by their size and business, in particular AT 3, AT 5, AT 7 (with emergency management under AT 7.3) and AT 9. A firm that also takes deposits and grants loans is a CRR credit institution and has been under the full framework since 2025.

2. Are we a microenterprise, and do Articles 28 to 30 apply then?
For most factoring and leasing firms, no, and Articles 28 to 30 then apply in principle in full. Under Section 1a(2a) sentence 2 no. 3 KWG they do not apply only to microenterprises of the group. A microenterprise employs fewer than ten persons and has an annual turnover and/or annual balance sheet total not exceeding EUR 2 million. In our assessment, a firm with a sizeable receivables or leasing portfolio is as a rule well above that in total assets. Never assume the status: how to check it with figures, and what remains open in the borderline case of “and/or” (German text: “bzw.”), is shown on the page on DORA applicability.
If you are a microenterprise, DORA no longer requires the register, the assessment before entering into a contract, exit strategies, concentration risk and mandatory contract terms. You still have to identify dependencies on providers and cushion them in business continuity (Article 16(1)(e), RTS Article 30(2), Article 39(2)), and for ICT third-party sourcing AT 9 MaRisk remains applicable, as we derive from the wording.
If you are not a microenterprise, Articles 28 to 30 apply without the strategy under Article 28(2) and without the policy under RTS 2024/1773. Do not plan on being exempt from aggregating recurring incidents under Article 8(2) of RTS 2024/1772. Whether the KWG group, which is covered only under national law, falls under the exemption there is not settled in any source we have read.
Sample case: from function to evidence
Fictitious example, not a client. Muster-Factoring GmbH buys receivables from mid-sized clients, pays advances on them and handles debtor management. It has 23 employees and total assets of EUR 61 million, so it is not a microenterprise. It uses its core system as software as a service from a software vendor that runs it in a subcontractor’s data centre. Payments are processed through banking software. A managed service provider (MSP) looks after workstations, user administration and file servers. In October 2026 the management classified five functions as critical or important. The full list of functions with reasons is on the page on classifying critical or important functions. For two of these functions, and for the building blocks that support all functions, the table shows the full chain that the simplified framework requires.
| Function (classification) | Application | Provider | Risk | Measure (provision) | Owner | Evidence |
|---|---|---|---|---|---|---|
| Receivables purchasing with purchase and limit checks (critical or important: no new business without purchasing) | factoring core system with client portal, interface to a credit agency | software vendor (direct provider), data centre operator (subcontractor), credit agency | outage of more than 8 hours, loss of purchasing data, failure of the credit agency interface | recovery objective 8 hours, maximum data loss 1 hour, recovery in the alternate data centre. Contract with mandatory terms for critical or important functions, subcontracting approved, exit strategy. Fallback if the credit agency fails: queries through its web portal up to a limit, above it the management decides (RTS Article 39(2)(d), (g), (h), Article 28(8), Article 30(3) DORA) | Head of Operations, approval by the management | contract with DORA annex, register entry with subcontractor, record of the recovery exercise, section in the business continuity plan |
| Payouts to factoring clients and payments (critical or important: an outage is felt within hours) | banking software on workstations, bank connection via EBICS | MSP (operates the workstations), house bank (whether its access is an ICT service needs to be checked case by case) | manipulated payment files, compromised accounts | strong authentication, four-eyes approval, rights on a need-to-use basis, logging of approvals (RTS Article 33, Article 34(f)) | Head of Finance | list of rights with recertification, approval logs |
| Workstations, email, user administration (ICT assets supporting all functions) | clients, directory service, cloud office software | MSP, cloud provider | malware via phishing, misuse of the MSP’s administrator accounts | automated vulnerability scanning and patching, administrator access only ad hoc and logged, backups kept separate from the network (RTS Article 33, Article 34(d), (f)) | information security officer (internal) | scan reports, patch status, monthly review of privileged access |
| Handling and reporting of ICT-related incidents (process, mandatory since 17 January 2025) | ticket system, BaFin’s reporting and publishing platform (MVP) | software vendor and MSP supply incident information | reporting deadline missed because information is missing or nobody can be reached | on-call cover, classification sheet, two people with MVP access, providers’ duty to supply incident information in the contract (Articles 17 to 19 DORA) | management | record of the reporting exercise, incident log |
The classification “critical or important” follows Article 3(22) DORA and is not the same as the materiality of an outsourcing arrangement. The method is on the page on classifying critical or important functions. The recovery objectives are sample values: the RTS requires defined recovery levels and timeframes and a BIA approved by the management body, but sets no figures.
3. What happens to our BAIT documents?
Hardly any document disappears without replacement: most of the content moves into the structure of the RTS. The main documents replaced are the protection needs assessment and the backup concept, whose content goes into the classification and the business continuity plan. The authorisation concept is rebuilt as the access control procedure, the IT emergency concept as the business continuity plan, and MaRisk AT 7.3 still requires an emergency concept. Document by document this is shown in the list for rebuilding BAIT documents, BAIT paragraph by paragraph in the mapping on the same page. The BAIT continue to apply until 31 December 2026, so do not repeal any BAIT rule early.
4. Who takes on security, control and internal audit tasks?
The management holds overall responsibility and allocates the other tasks itself, but control and internal audit must be segregated and independent. The simplified framework does not prescribe an information security officer or an ICT risk control function. The tasks remain. The rules in detail are on the page on DORA Article 16. In the sample case the allocation looks like this:
| Task | In the sample case | Must not be combined with |
|---|---|---|
| overall responsibility, approval of classification, main risks, BIA and business continuity plan, budget, reporting (RTS Article 28(2)) | management (two managing directors) | - |
| maintaining the policy, steering measures, assessing incidents, planning tests, reporting to the management | information security officer (internal), with a contact person in the management | internal audit, and in our recommendation not IT operations either |
| IT operations, patches, user administration | MSP, steered by the Head of Operations | control of its own work |
| internal audit of the framework (RTS Article 28(5), (6)) | internal audit according to the audit plan, with independent auditors with ICT expertise | information security and IT operations |
5. What must software vendors, MSPs and data centres deliver?
Contracts with the mandatory terms under Article 30 DORA and, in day-to-day operation, the evidence you cannot produce yourself. DORA affects the providers only indirectly through these contracts. They have no reporting obligation under DORA (their own obligations, for example under NIS2 or German telecoms law, may apply), and only the ICT third-party service providers designated as critical by the European Supervisory Authorities are directly overseen. If an incident at the provider causes a major incident at your firm, you report it.
| Provider | In the contract (Article 30 DORA, RTS 2025/532) | In operation (RTS Title III) | For the register (ITS 2024/2956) |
|---|---|---|---|
| core system software vendor (supports a critical or important function) | all terms under paragraph 2, plus under paragraph 3: precise performance targets, reporting duties, contingency plans and their testing, security measures, rights of access, inspection and audit, exit assistance with a transition period. Rules on subcontracting with a duty to inform about material changes | disruption and incident notices with the details you need for classification, participation in the recovery exercise, audit reports, advance notice of changes | LEI or EUID, subcontractors that effectively support the critical or important function |
| managed service provider (workstations, servers, user administration) | all terms under paragraph 2, for example service description, locations, access to data on insolvency and termination, assistance with incidents, termination rights. Paragraph 3 if the service supports a critical or important function | results of automated vulnerability scanning and patch status, logs of privileged access, backup and restore evidence, change log, personal accounts for every technician | LEI or EUID |
| data centre (contracted directly or as a subcontractor) | locations, security measures, for critical or important functions audit rights | evidence of physical access protection and protection against environmental hazards (RTS Article 32), for example audit reports | as a subcontractor in the service chain |
The European Supervisory Authorities have not published standard contractual clauses so far, and there is no extended transition period for existing contracts either. Plan the renegotiations early. Microenterprises of the group need the deliveries listed under “In operation” even without Article 30, because the measures under RTS Article 29(2) include those implemented by the provider.
6. What has to be in place and evidenced by 1 January 2027?
Everything the simplified framework and Articles 28 to 30 require applies from that day without any further transition period, and incident reporting already applies. The list shows which evidence should be available on the reference date:
| Obligation | Provision | Evidence on 1 January 2027 |
|---|---|---|
| incident handling, classification, reporting (applies since 17 January 2025) | Articles 17 to 19 DORA, RTS 2024/1772, 2025/301 | process description, classification sheet, MVP accounts, incident log |
| documented framework and information security policy | Article 16(1)(a) DORA, RTS Article 29 | framework document, policy, catalogue of measures |
| responsibilities, objectives, budget, reporting | RTS Article 28(2) | minutes of the management decision |
| classification, main risks, BIA | RTS Article 28(2)(d), Articles 30, 31 | list of functions, asset and dependency overview, risk register, approved BIA |
| business continuity plan with recovery objectives and backup | RTS Article 39 | approved plan |
| access control, operational security, logging, data security | RTS Articles 32 to 35 | access control procedure, logging rules, scan and patch evidence |
| testing plan and, on our reading, testing programme | RTS Article 36, Articles 24, 25 DORA | testing plan 2027 |
| project and change procedures | RTS Articles 37, 38 | procedure descriptions |
| contracts with mandatory terms, exit strategies, register (not for microenterprises) | Articles 28 to 30 DORA | contract overview with renegotiation status, exit strategies for critical or important services, register |
| training for staff and management | Article 16(1)(h) DORA | training plan 2027 |
| internal audit of the framework | RTS Article 28(5) | ICT audit area in the 2027 audit plan |
Whether the weekend relief for initial and intermediate reports applies to factoring and leasing firms is open, so we plan without it. Deadlines and reasoning are on the page on deadlines and procedure of the DORA reporting obligation. When the group first submits a register of information is not settled in any source we have read. Keep it ready for submission from January 2027.
Short record of a recovery exercise (example)
Fictitious example for Muster-Factoring GmbH. The firm tested its new plan in October 2026, still under BAIT, so that deficiencies are fixed before the switch.
| Exercise | recovery of the receivables purchasing function |
|---|---|
| Date, duration | 22 October 2026, 07:30-16:00 |
| Basis | business continuity plan section 3, until 31 December 2026 BAIT chapter 10, from 2027 RTS Article 40 |
| Scenario | Malware encrypts the core system database at the software vendor. Recovery from the backup in the alternate data centre. |
| Targets in the plan | function usable again within 8 hours at most, maximum data loss 1 hour |
| Sequence | 07:30 scenario triggered 07:55 vendor reached (25 minutes late, phone list out of date) 08:20 decision to use the alternate data centre 13:05 database restored 14:20 core system released for case handling 15:40 client portal available again |
| Result | Core system usable after 6 hours 50 minutes, last data state 40 minutes before the scenario started: targets met. Client portal only after 8 hours 10 minutes: target narrowly missed. |
| Deficiencies | 1. Vendor contact list out of date. 2. The portal certificate first had to be installed in the alternate data centre. 3. In emergency operation it was unclear who approves purchases under the four-eyes principle. |
| Actions | On 1: check the list in the plan quarterly, Head of Operations, by 30 November 2026. On 2: vendor keeps the certificate on file, contract annex supplemented, by 15 December 2026. On 3: approval rule for emergency operation added to the plan, Head of Risk Management, by 30 November 2026. |
| Report to the management | 29 October 2026, deficiencies and actions noted (mandatory from 2027 under RTS Article 40(3)) |
Result of a reporting exercise (example)
Fictitious example for Muster-Factoring GmbH. Tabletop exercise on Friday, 30 October 2026: the core system fails at the vendor, awareness at 15:10, classified as major at 17:40, so the initial notification is due by 21:40 (the thresholds are on the classification sheet for the reporting obligation). The main finding concerned the core system vendor: it reported the outage as a disruption without details of cause, expected duration and affected clients, and supplied them only after a second request at 20:15. Only then could the details of the affected factoring clients be added to the form. The form was ready at 21:05, so the deadline would just have been met. The actions:
- contract annex with report content and delivery times for the vendor, for example cause, expected duration and affected clients within one hour (Head of Operations, by 31 December 2026),
- contact person at the vendor with a deputy in the emergency manual, a second person for the MVP (management, by 30 November 2026),
- add the number of clients per service to the classification sheet (information security officer, by 15 November 2026).
7. How much effort is it, and how much of our own time do we need?
That depends less on the size of the firm than on the state of the BAIT documents and the number of ICT providers. If many contracts need renegotiating, what you need most is time that is not in your own hands. Our assessment:
| Work package | Who is involved internally | What increases the effort |
|---|---|---|
| classification and microenterprise check | management, accounting | borderline case on the financial figures |
| list of functions, assets, dependencies, BIA | heads of business units in workshops, Head of Operations | no current overview of applications and providers |
| rebuilding the document set | information security, with input from business units | outdated or incomplete BAIT documents |
| contracts and register | Head of Operations, procurement or legal counsel | many providers, standard contracts of large vendors, long subcontracting chains |
| management decisions and training | management | few meeting dates before year end |
| recovery and reporting exercise | Head of Operations, providers, management | providers without an exercise date in the contract |
| operation in the first year | information security, business units, internal audit | missing delivery duties of providers |
Most of the management’s time goes into the decisions under RTS Article 28(2), so these dates should be in the calendar now. A reliable picture of your effort comes from the DORA gap analysis with action plan. Our transition from BAIT to Article 16 carries out the rebuild with a fixed base scope, and the Article 16 gap analysis is credited against it, with details in the proposal. Scope and prices are on these two pages.
Three typical gaps at factoring and leasing firms
| Gap | Cause | Effect | Remedy |
|---|---|---|---|
| Transition planned only for 2027 | the BAIT apply until 31 December 2026, so the project is moved into the new year | on 1 January 2027 the list of functions and BIA approved by the management body and other decisions under RTS Article 28(2) are missing, and there is no further transition period | set the management’s meeting dates now: adopt roles, policy, list of functions and BIA in December 2026, the business continuity plan by January 2027, recovery and reporting exercise in the first quarter of 2027, or already in 2026 if you can |
| Credit agency, bank access and dealer portals missing from the dependency overview | only the core system vendor and the MSP count as ICT providers, interfaces and, in leasing, the portals of manufacturers and dealers are left out | dependencies under Article 16(1)(e) incomplete, no fallback procedure for credit checks, payments or contract origination | classify every interface under RTS Article 30, check case by case whether it is an ICT service, set fallback procedures under RTS Article 39(2)(h) |
| Providers deliver no evidence | contracts from the BAIT era without mandatory terms under Article 30, reports never requested | recoverability, patch status and logging cannot be evidenced | negotiate a contract annex under Article 30, request deliveries with dates in the annual calendar |
Gaps and remedies are our professional assessment based on the wording of DORA, the RTS and the supervisory notice. The sample case on this page is entirely fictitious. This assessment is general information and is not legal advice for an individual case. Whether you are a microenterprise you can check with the figures on the page on DORA applicability.
Frequently asked questions
What changes for factoring and leasing firms on 1 January 2027?+
Do all contracts with ICT providers have to be amended by 1 January 2027?+
Our IT is run entirely by a provider. What do we still have to do ourselves?+
Is a recovery exercise still worthwhile under BAIT?+
Read more
- DORA Article 16: the simplified ICT risk management framework
- DORA Article 16 transition: moving from BAIT to the simplified framework
- BAIT and DORA: repeal, transition and the mapping as Excel
- DORA incident reporting: classifying and reporting ICT-related incidents
- Classifying critical or important functions under DORA
- DORA scope: who does DORA apply to, and which framework?
- DORA gap analysis: quick check, Article 16 and full framework
Sources
- Regulation (EU) 2022/2554 (DORA), Article 3(22) and (60), Articles 16, 17-19, 24-30 (retrieved 2026-11-06)
- Delegated Regulation (EU) 2024/1774 (RTS on ICT risk management), Title III Articles 28-41 (retrieved 2026-11-06)
- Delegated Regulation (EU) 2024/1772 (classification of incidents), Articles 6, 8, 9 (retrieved 2026-11-06)
- Delegated Regulation (EU) 2025/301 (content and time limits of incident reports), Article 5 (retrieved 2026-11-06)
- Delegated Regulation (EU) 2025/532 (subcontracting) (retrieved 2026-11-06)
- German Banking Act (KWG), Section 1a (unofficial version, in German) (retrieved 2026-11-06)
- German Banking Act (KWG), Section 65a (unofficial version, in German) (retrieved 2026-11-06)
- BaFin: DORA FAQ 13, transition for institutions under Section 1a(2a) KWG, in German (retrieved 2026-11-06)
- BaFin: supervisory notice of 21 August 2025 on the simplified ICT risk management framework (Article 16 DORA), in German (retrieved 2026-11-06)
- BaFin: news of 9 January 2025 on changes to IT requirements under DORA, in German (retrieved 2026-11-06)
- BaFin: DORA FAQs (scope, third parties, reporting, register of information), in German (retrieved 2026-11-06)
- BaFin: Circular 06/2026 (BA) MaRisk, as of 30 June 2026, AT 2.1, AT 7.3, AT 9, in German (retrieved 2026-11-06)
This content provides general technical and organisational information and does not constitute legal advice (no legal services within the meaning of the German RDG).
