DORA Article 9: protection and prevention, where the RTS stops being polite¶
Articles 7 and 8 made you write down what you run. Article 9 is where DORA tells you to defend it, and where the RTS drops the high-level language and starts naming specific controls: encryption, patching, logging, network segmentation. Today, protection and prevention, and the exact technical standards behind each word.
Article 9, in four moves¶
Article 9 has four paragraphs and they build on each other. Paragraph 1 sets the goal: financial entities "shall continuously monitor and control the security and functioning of ICT systems and tools" and minimise the impact of ICT risk. Paragraph 2 wants ICT security policies that maintain "high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit". That last phrase matters, because the RTS turns it into an encryption requirement covering all three states.
Paragraph 3 lists what the ICT solutions must do: secure the means of data transfer, minimise corruption and unauthorised access, prevent availability and integrity failures, and protect data from human error. Paragraph 4 is the operational heart, points (a) to (f): an information security policy, network and infrastructure management including "automated mechanisms to isolate affected information assets in the event of cyber-attacks", access limitation, "strong authentication mechanisms" with cryptographic key protection, change management, and "appropriate and comprehensive documented policies for patches and updates".
Read 9(4)(b) again. Automated isolation of affected assets during an attack is written as a requirement, not a nice-to-have. If your answer to transverse movement is a human on a phone bridge at 3am, that is a gap.
Where the RTS names names¶
DORA Article 9 stays at the level of "implement policies". RTS 2024/1774 Title II, Chapter I says exactly what those policies contain. Here is the corrected mapping, verified against the Official Journal text, because the article numbering trips people up.
Article 6 is encryption and cryptographic controls. It requires a documented encryption policy built on your data classification, with rules for "the encryption of data at rest and in transit", "the encryption of data in use, where necessary", and encryption of internal network connections and external traffic. Data in use is the hard one, and the RTS knows it, which is why it adds "where necessary" rather than pretending it is always feasible.
Article 7 is cryptographic key management, and it wants requirements "for managing cryptographic keys through their whole lifecycle, including generating, renewing, storing, backing up, archiving, retrieving, transmitting, retiring, revoking, and destroying". If you encrypt but cannot describe how a key is retired, you have done half the job.
Article 10 is vulnerability and patch management: "develop, document, and implement vulnerability management procedures", including automated scanning whose frequency scales with the asset's classification, and checks that your ICT third parties handle and report their own vulnerabilities. This is where Article 8's classification pays off, because it decides how often each asset gets scanned.
Article 11 is data and system security. Article 12 is logging, framed explicitly "as part of the safeguards against intrusions and data misuse". Article 13 is network security management, which spells out "the segregation and segmentation of ICT systems and networks". Segmentation is now a named regulatory control, not just good hygiene.
The artefact: Article 9 to RTS control map¶
The policy set DORA Article 9 expects, each line traceable to the RTS article that defines its content.
| Article 9 duty | RTS 2024/1774 article |
|---|---|
| Data protected at rest, in use, in transit (9(2)) | Art. 6 Encryption and cryptographic controls |
| Key protection behind strong authentication (9(4)(d)) | Art. 7 Cryptographic key management |
| Patch and update policies (9(4)(f)) | Art. 10 Vulnerability and patch management |
| Data and system protection (9(3)) | Art. 11 Data and system security |
| Monitoring and control (9(1)) | Art. 12 Logging |
| Network management and isolation (9(4)(b)) | Art. 13 Network security management |
If each row has a real, approved policy behind it, Article 9 is covered. If encryption of data in use is blank, that is a defensible gap you should document rather than hide, because the RTS itself qualifies it with "where necessary".
The full official text set, including RTS 2024/1774, sits in the DORA branch of the resource library.
Next in this series: Article 10, detection, and the RTS criteria that decide when an anomaly becomes an incident you have to report.