Article 28(3) is one line in the regulation and a quarter of the implementation effort in practice. It requires a register of information of all your ICT third-party arrangements. ITS 2024/2956 turns that line into a structured, machine-readable filing with a fixed template set. Today, what the register is and why it consumed so many teams in 2025.
BaFin's own numbers said it: roughly half of major ICT incidents in 2025 originated at third parties. Chapter V is DORA's answer. Articles 28 to 30 make third-party ICT risk an explicit, contractual, documented discipline. Today, the principles, the register, and the contract clauses DORA now requires you to have in writing.
Chapter IV is where DORA asks you to attack yourself. Articles 24 to 27 build a testing programme, and at the top sits threat-led penetration testing, TLPT, which is a different animal from the annual pen test most firms already buy. Today, the testing programme and who has to do the hard version.
This is the chapter that changed daily life for financial entities. Articles 17 to 23 turn "we had an outage" into a regulated reporting process with statutory deadlines. Miss the classification in post 5 and you miss the clock here. Today, incident management and the reporting cascade, with the exact hours from the RTS.
So far this series has walked the full ICT risk management framework, Articles 5 to 15. Article 16 is for the entities that do not have to do all of that. It is proportionality written into the regulation. It is also widely misread as an exemption, which it is not. Today, who qualifies for the simplified framework, and what they still have to do.
Most of DORA is about preventing and surviving incidents. Articles 13 and 14 are about what happens afterwards: do you learn, and do you communicate. They are easy to skim past because they do not come with hard thresholds. They are also, in my experience, where the difference between a mature function and a box-ticking one actually shows. Today, learning and communication.
Most DORA readiness work starts from the regulation and tries to guess what a supervisor will ask for. You do not have to guess. BaFin published the list.
The awkward part is what happens when you lay your existing policy stack next to it.
Detection tells you something broke. Articles 11 and 12 are about getting back up. This is the part of DORA that auditors love, because continuity and backup are testable in a way that policies are not: either you restored within your stated objective or you did not. Today, business continuity and backup, and the RTS that says testing them once is not enough.
Article 9 was about keeping attackers out. Article 10 accepts that some get in, and asks whether you would notice. It is short, but it connects to the most consequential numbers in the whole regulation: the thresholds in RTS 2024/1772 that decide when an incident stops being an internal matter and becomes something you must report to your supervisor. Today, detection and classification.
An AI system that processes personal data lands on your desk. Two obligations attach to it, from two regulations, answerable to two different authorities.
Almost everyone runs them as two projects. The legal text does not ask for that, and the second risk register is where the trouble starts.