The eleven expected deliverables
The list, in production order
| # | Deliverable | Article | Depends on |
|---|---|---|---|
| 1 | Scope and proportionality note | 2, 4, 16 | — |
| 2 | Approved ICT risk management framework | 5, 6 | 1 |
| 3 | Digital operational resilience strategy | 6 | 2 |
| 4 | Function / asset / third-party mapping | 8 | 1 |
| 5 | ICT business continuity policy | 11 | 4 |
| 6 | Backup and restoration policy | 12 | 4 |
| 7 | Incident management and classification procedure | 17, 18 | 4 |
| 8 | Notification procedure and report templates | 19 | 7 |
| 9 | Multi-year testing programme | 24, 25 | 4 |
| 10 | Register of information | 28 | 4 |
| 11 | ICT contract clause set | 30 | 10 |
Why this order
Deliverable 4 — the mapping — appears early and conditions five others. An organisation that starts with the register of information without having identified its critical functions fills the "function supported" field by guesswork, and will have to redo it all.
The duplication trap
Many organisations already hold an ISO/IEC 27001 ISMS, an ISO 22301 BCMS or arrangements aligned with the EBA guidelines. The reflex is to write brand-new DORA documents alongside the existing ones.
That is an expensive and detectable error: the supervisor finds two backup policies that diverge, two risk registers, two testing programmes. The right approach is to enrich the existing documents and produce a mapping note stating, article by article, where the DORA requirement is met.
What the supervisor looks at first
In the order observed: the board resolution approving the framework (Article 5), the register of information (Article 28), the year's test reports (Article 25), and the record of the last major incident notification (Article 19).
All four are dated, signed documents. None can be improvised the day before a review.
Key takeaways
- Eleven deliverables cover the bulk of the regulation
- The Article 8 mapping conditions four other deliverables
- The register of information is built last but planned first