DORA Articles 13 and 14: the quiet articles that decide if you improve¶
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.
Article 13: learning and evolving¶
Article 13 requires "capabilities and staff to gather information on vulnerabilities and cyber threats, ICT-related incidents, in particular cyber-attacks", and to analyse their likely impact. Then the part that bites: after a major incident, entities must run "post ICT-related incident reviews" analysing the causes and improving the ICT operations. Not a blameless retro because it is nice. A required review because the regulation says the point of an incident is to change something.
Article 13 also loops back to the board. Remember Article 5(2)(g), the budget for "ICT security awareness programmes and digital operational resilience training"? Article 13(6) is where that training obligation lives in detail: staff, up to and including management, kept current on ICT risk proportionate to their role. Training logs are not paperwork here, they are the evidence that Article 13 and Article 5(4) are both satisfied.
The honest reading of Article 13 is that DORA wants a feedback loop: threat intelligence in, incidents analysed, lessons pushed back into controls and training. If your post-incident reviews produce a document nobody reads, you have the form without the function.
Article 14: communication, before you need it¶
Article 14 requires crisis communication plans "enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts as well as to the public, as appropriate". The phrase "responsible disclosure" is doing work: DORA wants you to have decided, in calm conditions, who says what to whom when things break. The worst time to design your external messaging is during the incident.
It also asks for a designated approach so that communication is coherent, with at least one person responsible for implementing the strategy with the public and media. This connects to the incident reporting duties in Chapter III, but it is distinct: reporting is to your supervisor, communication is to everyone else. Both have clocks. Only one has statutory deadlines, which is exactly why the other gets forgotten.
The artefact: learning and communication checklist¶
The evidence that Articles 13 and 14 are operating.
| Requirement | Evidence |
|---|---|
| Threat and vulnerability intelligence (Art. 13(1)) | Named capability, feeds, analysis output |
| Post-incident reviews (Art. 13(2)) | Review records for every major incident, with actions |
| Lessons feeding controls | Traceable changes from reviews into policy or config |
| Training by role (Art. 13(6), Art. 5(4)) | Training plan and attendance, including the board |
| Crisis communication plan (Art. 14) | Approved plan: audiences, spokespeople, triggers |
| Responsible disclosure approach | Documented who-says-what-when for major incidents |
The row people fail is "lessons feeding controls". Reviews that do not change anything are theatre. The DORA resource library has the official text.
Next in this series: Article 16 and the simplified regime, for the smaller entities that get a lighter framework but not a free pass.