Last updated: 2026-11-06
This page explains what the simplified ICT risk management framework under Article 16 DORA requires and how to evidence implementation. It applies to all groups that use this framework in Germany. Whether your firm falls under Article 16 at all is covered on the page on DORA applicability.
The legal basis is Article 16 of Regulation (EU) 2022/2554 (DORA), Title III of Commission Delegated Regulation (EU) 2024/1774 (the RTS on ICT risk management, “RTS” below) with Articles 28 to 41, and the BaFin supervisory notice of 21 August 2025 on Article 16 (“BaFin notice” below, in German only). By its own account, the BaFin notice is not a binding interpretation. One section covers scope, eight further sections compare the German IT circulars BAIT and VAIT with the new requirements.
Who applies the simplified framework in Germany?
Only a few clearly defined groups. Directly under DORA, these are small and non-interconnected investment firms and small institutions for occupational retirement provision (IORPs). German law (the FinmadiG act) adds insurance holding companies and all institutions under the German Banking Act (KWG) that are not already in scope under Article 2 DORA. We refer to these institutions under Section 1a(2a) KWG as the KWG group. Article 16 is therefore not a general relief for small firms: payment and e-money institutions are not covered in Germany, because Germany did not use the exemptions of the Payment Services and E-Money Directives.
| Group | Legal basis | Framework | Applies from |
|---|---|---|---|
| small and non-interconnected investment firms (conditions of Article 12(1) IFR) | Article 16(1) with Article 3(34) DORA | Article 16 | 17 January 2025 |
| small IORPs: 16-99 members in total (German text: 15-99, see below) | Article 16(1) with Article 3(53) DORA | Article 16 | 17 January 2025 |
| insurance holding companies (Section 7 no. 31 VAG) and undertakings under Section 293(4) VAG | Section 293(5) German Insurance Supervision Act (VAG) | Article 16 | no transition period stated in the VAG |
| institutions under Section 1(1b) KWG not already covered by Article 2 DORA, according to BaFin in particular guarantee banks, financial services institutions (e.g. finance leasing and factoring firms, crypto securities registrars), housing companies with savings schemes and third-country branches under Section 53 KWG | Section 1a(2a) with Section 65a(3) KWG | Article 16, no TLPT microenterprises of this group without Articles 28 to 30 | 1 January 2027, incident reporting under Chapter III since 17 January 2025, BAIT apply until 31 December 2026 |
| IORPs with no more than 15 members (German text: fewer than 15) | Article 2(3)(c) DORA | DORA does not apply | - |
| IORPs with 100 or more members, payment and e-money institutions, management companies, CRR credit institutions | Article 2 DORA | full framework, Articles 5 to 15 | 17 January 2025 |
| KfW and regional development banks | KfW via the FinmadiG under the KfW Regulation, regional development banks under Section 1a(2) KWG | full framework | - |
| financial holding companies | BaFin FAQ 13 | BAIT until 31 December 2026, what applies afterwards is not stated in any source we have read | open |
The table follows Table 1 of the BaFin notice and adds thresholds and dates from DORA and the KWG. The IORP scale (up to 15, 16-99, 100 or more members) follows from Article 2(3)(c), Article 3(53) and Article 16(1) DORA read together. At exactly 15 members the language versions differ: the English text of point (c) exempts IORPs with “not more than 15 members”, the German text only those with fewer than 15. Our DORA applicability page covers this borderline case. Firms that take deposits and grant credit are CRR credit institutions and have been under the full framework since 17 January 2025.
What does Article 16 itself require?
Article 16(1), second subparagraph, sets out eight obligations in points (a) to (h):
- (a) a sound and documented framework, including protection of physical components,
- (b) continuous monitoring of all ICT systems,
- (c) resilient, up-to-date systems that protect the availability, authenticity, integrity and confidentiality of data,
- (d) prompt detection of anomalies and handling of incidents,
- (e) identification of key dependencies on ICT third-party service providers,
- (f) continuity of critical or important functions through business continuity plans, at least with backup and restoration,
- (g) regular testing of these plans and of the controls,
- (h) lessons learned, and awareness and training for staff and management.
Under Article 16(2), the framework is documented and reviewed periodically and after major ICT-related incidents, and continuously improved. A review report is submitted to the authority on request. Unlike the full framework (Article 6(5)), Article 16 sets no annual cycle.
Evidence matrix: RTS Title III article by article
Title III of the RTS has 14 articles in four chapters. Chapter I covers governance, policy, classification, risk management and physical security (Articles 28 to 32), Chapter II the further protective measures from access control to change management (Articles 33 to 38), Chapter III the business continuity plan and its testing (Articles 39, 40), and Chapter IV the review report (Article 41). The second column summarises the legal text, the third suggests documents that evidence implementation, the fourth names the gap we most often expect when moving from BAIT structures. Columns three and four are our professional assessment, not legal text.
| Provision | Core requirement | Suitable evidence | Typical gap from the BAIT era |
|---|---|---|---|
| Article 16(1)(a), (2) DORA | documented framework, reviewed periodically and after major incidents | framework document with scope and document map, review report under RTS Article 41 | framework spread across IT strategy, policies and concepts without a common structure |
| Article 16(1)(b)-(d) DORA | continuous monitoring, current systems, prompt detection and incident handling | monitoring requirements, alert rules, incident log | monitoring runs at the provider, alert routes into the firm are not agreed |
| Article 16(1)(e) DORA | identify key dependencies on ICT third-party service providers | dependency overview from classification and provider list | list covers outsourcing only, other ICT services missing |
| Article 16(1)(h) DORA | lessons learned, awareness and training for staff and management | training plan, attendance records including management | management not included |
| RTS Article 28(1), (2) | governance and control framework management body with overall responsibility, clear roles, information security objectives approves classification, main risks, business impact analysis (BIA) and continuity plans budget reviewed at least annually reporting lines to the management body | board minutes, responsibility matrix, budget decision, reporting rules (frequency, form, content) | BIA only in the emergency concept and not approved by management |
| RTS Article 28(3)-(6) | compliance review may be outsourced, responsibility remains segregation and independence of control and internal audit functions internal audit by independent auditors with ICT expertise timely follow-up of critical findings | audit plan with ICT topics, auditor qualifications, finding tracker | one person advises, controls and audits no ICT auditor |
| RTS Article 29 | information security policy covering confidentiality, integrity, availability and authenticity measures based on it, including those implemented by providers, covering all measures of Articles 30 to 38 | policy, catalogue of measures mapped to Articles 30 to 38 with owners | measures spread across many guidelines, provider measures not captured |
| RTS Article 30 | identify, classify and document critical or important functions, supporting assets and their interdependencies identify functions supported by providers | list of functions with reasons, asset inventory linked to functions and providers | protection needs assessed per system, not per business function |
| RTS Article 31 | risk tolerance thresholds identification, assessment, mitigation, monitoring of effectiveness risks from changes, tests and incidents regular documented assessment continuous threat and vulnerability monitoring alert thresholds | risk register with tolerance threshold, assessment records, alert criteria | tolerance threshold never explicitly set |
| RTS Article 32 | physical and environmental security based on current threats and classification | access rules for premises, data centre evidence | data centre evidence missing or outdated |
| RTS Article 33 | access control on need-to-know, need-to-use and least privilege, including remote and emergency access accountability account management including generic admin accounts appropriate authentication regular review of rights privileged access on a need-to-use or ad hoc basis and logged strong authentication for remote, privileged and critical-function access | documented access control procedure, recertification records, list of privileged accounts, log extracts, multi-factor configuration | standing admin rights at the provider, need-to-use not implemented |
| RTS Article 34 | asset lifecycle provider support capacity automated vulnerability scanning and patching legacy systems logging relating to access control, ICT operations and change management (point (f)) anomaly monitoring threat intelligence detection of data leaks and malicious code | lifecycle records, scan reports, patch evidence, logging rules, monitoring reports | vulnerabilities only found through an annual penetration test, no automated scanning |
| RTS Article 35 | protection of data in use, in transit and at rest devices and media network security secure deletion and disposal remote work and private devices | network diagram, encryption rules, deletion and disposal records, remote work policy | protection of data in use never considered (new according to BaFin) |
| RTS Article 36 | ICT security testing plan for Articles 33 to 35, 37 and 38 fix findings on critical-function systems without undue delay | test plan, test reports, action list with deadlines | tests not linked to the risk register |
| RTS Article 37 | where appropriate: risk-based procedure for acquisition, development and maintenance requirements approved before acquisition testing and approval before first use and production changes protection against tampering | procurement procedure, approved requirements, acceptance records | security requirements for standard software not formally approved |
| RTS Article 38 | project management procedure across all phases change procedure for all changes: recorded, tested, assessed, approved, implemented, verified | procedures, change log | only material changes covered, provider changes missing |
| RTS Article 39 | continuity plans based on risk and impact analysis including a cyber-attack scenario, approved by the management body, accessible, resourced, planned recovery levels and timeframes, dependencies including providers, activation, backup with scope and minimum frequency, alternatives, communication and escalation plans, updates, mitigation of critical provider failures | approved plan, recovery targets per function, backup rules, escalation plan | no cyber-attack scenario, recovery targets per system only |
| RTS Article 40 | test at least annually for backup and restoration or after major plan changes show continuity document results analyse, fix and report deficiencies to the management body | test record, list of deficiencies, report to the board | restore of single files tested instead of recovery of a function |
| RTS Article 41 | review report in a searchable electronic format with context, approval date, reason, period, responsible person, findings, remediation with dates, conclusions | report structured along Article 41 | security officer report without the required content |
Two points are often underestimated. The simplified framework also requires a BIA approved by the management body (RTS Article 28(2)(d)) and planned recovery levels and timeframes per function (RTS Article 39(2)(d)), which in our assessment match the recovery objectives of the full framework in substance. And backup scope and minimum frequency belong in the continuity plan, since a separate backup concept is no longer required.
Logging under the simplified framework
Section 8.2 of the BaFin notice sets out no detailed logging rules of its own like those of RTS Article 12 for the full framework. RTS Articles 33 and 34(f) nevertheless require logging under the simplified framework. Article 33 requires privileged, emergency and administrator access to be recorded in a log. Article 34(f) requires logging of events relating to access control, ICT operations including system and network traffic, and change management, with a level of detail suited to the purpose. The German text of point (f) reads “Vorfälle” (incidents), which reads more narrowly than “events”. The BaFin notice itself cites Article 34(f) in section 9. Retention periods and other details are for you to set, with reasons.
Which full-framework requirements do not apply under Article 16, and what remains?
“No longer required” always means there is no explicit requirement any more. It does not mean that a role, document or safeguard should be removed. The table lists the requirements of DORA and the RTS for the full framework first, then the BAIT requirements that have no counterpart in the simplified framework. According to BaFin, the simplified framework asks for less than BAIT/VAIT, while differences in third-party risk management are small.
| No explicit requirement any more | Task that remains |
|---|---|
| From the full framework (Articles 5 to 15 DORA, RTS Title II) | |
| enhanced board knowledge duties (Article 5(4)) and communication (Article 14) | adequate ICT competence, training for management (Article 16(1)(h)), communication and escalation in the continuity plan |
| ICT risk control function (Article 6(4)) | segregation and independence of control and internal audit (RTS Article 28(4)) |
| digital operational resilience strategy (Article 6(8)) | the framework must enable the business strategy in line with risk appetite (RTS Article 28(2)(a)) |
| annual risk assessment of legacy systems (Article 8(7)) | manage risks from outdated or unsupported assets (RTS Article 34(e)) |
| ICT business continuity policy, response and recovery plans, crisis management function (Article 11(1), (3), (7)) | continuity plans under RTS Article 39 with escalation plans |
| reporting of aggregated annual costs and losses (Article 11(10)) | reporting of major incidents under Chapter III |
| key management under RTS Article 7 | protection of data in use, in transit and at rest (RTS Article 35(a)) |
| explicit identity management requirements | access control procedure with accountability and account management (RTS Article 33) |
| third-party risk strategy (Article 28(2)) and the policy under RTS 2024/1773 | all other obligations under Articles 28 to 30, sector outsourcing rules apply in parallel |
| From BAIT, without a counterpart in the simplified framework | |
| IT strategy | BaFin considers keeping an IT strategy advisable |
| information security officer | clear roles for all ICT functions, policy and measures, reporting to the management body (RTS Article 28(2)(b), (i), Article 29) |
| detailed security guidelines, board approval of the security policy | define and implement measures under Articles 30 to 38, the management body sets security objectives |
| protection needs assessment and configuration database | classification of functions and assets (RTS Article 30) |
| backup concept as a document | backup with scope and minimum frequency, annual tests (RTS Articles 39(2)(g), 40) |
| emergency concept and test concept | continuity plans under RTS Article 39, sector rules continue to apply, e.g. MaRisk AT 7.3 for institutions under the KWG |
| authorisation concepts and their review | access control procedure with need-to-use and recertification (RTS Article 33) |
Until 31 December 2026, the KWG group must still comply with BAIT in full, including the security officer and emergency management. Build the new structure in parallel and switch on 1 January 2027.
What applies in addition?
Article 16 only replaces Articles 5 to 15. Chapter III (incident management, classification and reporting) applies in full, for the KWG group since 17 January 2025. Whether the weekend relief applies to initial and intermediate reports of the KWG group is open, so we plan without it. Deadlines, classification and the reasoning are covered on our German-language page on the DORA reporting obligation.
Articles 28 to 30 on third-party risk apply in principle, except the strategy under Article 28(2). For microenterprises of the KWG group, Section 1a(2a) sentence 2 no. 3 KWG disapplies Articles 28 to 30, including the register of information. This rule is national and does not cover all DORA microenterprises. When a firm counts as a microenterprise, and why the status must never be assumed, is explained on the DORA applicability page. When the KWG group first submits a register is not settled in the sources we have read. We recommend keeping it ready for submission from January 2027.
Articles 24 and 25 DORA (testing programme) contain no exemption for Article 16 entities, and BaFin lists them for the simplified framework together with RTS Article 36. On our reading they therefore apply here as well. The counter-argument is that Article 24(1) describes the testing programme as part of the framework under Article 6, which Article 16 entities do not apply. Whether Article 24(6) (annual testing of all systems supporting critical or important functions) also applies is not stated explicitly, and its wording only exempts microenterprises. We recommend planning for the testing programme, including the annual tests, as a precaution until clarified. TLPT under Articles 26 and 27 does not apply.
Which documents does the RTS require?
Fewer than BAIT, but named precisely:
- the framework document (Article 16(1)(a), (2)),
- roles, security objectives, budget and board reporting (RTS Article 28(2)),
- the information security policy and catalogue of measures (Article 29),
- classification, main risks and BIA (Articles 28(2)(d), 30),
- risk assessment with thresholds (Article 31),
- the access control procedure (Article 33),
- deletion and disposal procedures (Article 35(e), (f)),
- the security testing plan (Article 36),
- acquisition and development procedures where appropriate (Article 37),
- project and change management procedures (Article 38),
- the continuity plan (Article 39) and its test records (Article 40(3)),
- the review report (Article 41),
- incident handling and reporting (Articles 17 to 19 DORA),
- outside the KWG microenterprise exception: the register, contracts with mandatory content and exit strategies (Articles 28 and 30 DORA).
Additional documentation is allowed, it is simply no longer required.
Who holds which role?
Management body. Under RTS Article 28(2), the management body holds overall responsibility, sets clear roles for all ICT functions, sets security objectives, approves and reviews classification, main risks, BIA and continuity plans, allocates and at least annually reviews the budget, sets policies and measures, ensures staff knowledge and defines its own reporting lines. The enhanced training duty of Article 5(4) does not apply, but BaFin expects adequate ICT competence, and Article 16(1)(h) names training for management.
Control and internal audit. No separate ICT risk control function is required. RTS Article 28(4) requires appropriate segregation and independence of control and internal audit functions, and Article 28(5) requires an internal audit of the framework by independent auditors with ICT expertise in line with the audit plan.
The security officer. According to BaFin, the BAIT information security officer has no direct counterpart. The tasks remain: maintaining the policy, steering measures, assessing incidents, planning tests, reporting to the board. We recommend keeping the role, redefining its tasks under RTS Article 28(2)(b) and keeping it separate from internal audit.
Common misconceptions
- “Article 16 applies to all small financial entities.” Only to the groups listed above. A small payment institution in Germany uses the full framework.
- “Logging is not required.” The BaFin notice lists no logging rules like those of RTS Article 12, but the RTS still requires logging (Articles 33, 34(f)).
- “Incident reporting starts in 2027.” For the KWG group, it has applied since 17 January 2025.
- “We are small, so Articles 28 to 30 do not apply.” Only microenterprises of the KWG group are exempt, and that status must be checked.
Three typical gaps
| Gap | Cause | Effect | Remedy |
|---|---|---|---|
| BAIT documents merely relabelled | new cover pages, RTS structure not followed | requirements without a BAIT precedent are missing (need-to-use, data in use, escalation plans) | complete the evidence matrix and map each document to an RTS article |
| Orphaned tasks | security officer and emergency roles deleted as “no longer required” | nobody reports to the board, tests and recertifications lapse | assign roles under RTS Article 28(2)(b), decide on reporting under point (i) |
| No review after major incidents | the Article 16 framework schedules the review only as an annual date and provides no trigger after major incidents | after a major incident the framework stays unchanged, and the incident-driven review report is missing, which under RTS Article 41(2)(c)(ii) lists the incidents with root cause analysis | make the review under Article 16(2) a fixed step of the incident process, with trigger, owner and report to the management body |
Plan to 1 January 2027 and the first year
For the KWG group, the simplified framework and Articles 28 to 30 apply from 1 January 2027 without a further transition period. Our suggested order from November 2026:
- by mid-November 2026: confirm the classification, including the microenterprise check,
- November 2026: record critical or important functions, assets and providers and update the BIA,
- November to December 2026: rebuild the document set from BAIT documents,
- December 2026: review ICT contracts against Article 30 and set up the register,
- December 2026: obtain management body decisions on roles, objectives, classification with the list of functions, BIA, budget and reporting,
- keep complying with BAIT until 31 December 2026,
- by January 2027: have the management body approve the business continuity plan,
- first quarter of 2027: run a recovery exercise and an incident reporting exercise under the new framework (if you can, hold a first round in 2026).
In the first year, the RTS sets fixed minimum cycles only for the budget review and the continuity plan test (both annually), and the register is submitted annually. A practical calendar, with the month allocation as our suggestion: risk assessment in February, access recertification in March, the incident reporting exercise and the continuity test by March, security tests in May, provider reviews in July, training in September, an internal audit of ICT in October, budget and BIA review in November, and the framework review with the Article 41 report in December.
How we can help
Our DORA gap analysis maps your current documents against the evidence matrix and delivers an action plan. Christian Gebhardt, founder and managing director of Blackfort Technology, is the responsible consultant. This page provides general information and is not legal advice for an individual case.
Frequently asked questions
Does the management body have to approve the security policy?+
How often must the simplified framework be reviewed?+
Does TLPT apply under the simplified framework?+
Is working through the BaFin notice of 21 August 2025 enough?+
Read more
- DORA for factoring and leasing: obligations and evidence from 2027
- DORA Article 16 transition: moving from BAIT to the simplified framework
- DORA scope: who does DORA apply to, and which 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 gap analysis: quick check, Article 16 and full framework
Sources
- Regulation (EU) 2022/2554 (DORA), Articles 2, 3, 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) 2025/301 (content and time limits of incident reports), Article 5 (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: DORA FAQ 13, transition under Section 1a(2a) with Section 65a(3) KWG, 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)
- 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)
- German Insurance Supervision Act (VAG), Section 293 (unofficial version, in German) (retrieved 2026-11-06)
- BaFin: register of information and notification duties, in German (retrieved 2026-11-06)
- BaFin: Circular 06/2026 (BA) MaRisk, as of 30 June 2026, 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).