DORA ICT Risk Management Framework: the Pillar 1 operating manual
Articles 5–16. The full Pillar 1 operating manual: control catalogue, sample policy library, KRIs, second-line testing patterns and board-reporting templates. Includes the simplified regime for smaller entities.
What this solves
Articles 5 to 16 are where most DORA programmes stall. The text tells you an ICT risk management framework must exist, be documented, be reviewed at least yearly and be owned by the management body — but it does not tell you what the framework looks like on a Monday morning, which controls belong in it, or what evidence a supervisor will ask to see.
The result is usually a policy that reads well and proves nothing. This playbook takes the opposite route: it starts from the control catalogue and the evidence each control produces, then works back to the policy wording that describes it.
What is inside
- 40+ controls mapped to Articles 5–16
- Sample policy library (GOV / ID / PR / DT / RR / LE)
- 25 KRIs with target ranges and trigger logic
- Second-line testing patterns and assurance cycle
- Board-reporting templates (quarterly + annual)
- Simplified regime adaptation (Art. 16)
- Roles & responsibilities matrix (RACI)
What it covers in the regulation
- Articles 5–16 — ICT risk management framework
- Article 6 — framework content and yearly review
- Articles 8–10 — identification, protection, detection
- Articles 11–12 — response, recovery and backup
- Articles 13–14 — learning, evolving and crisis communication
- RTS (EU) 2024/1774 — ICT risk management tools
- Article 16 — the simplified regime for smaller entities
Who uses it, and when
ICT risk officers and CISOs building the framework for the first time, second-line risk functions that must challenge it, and consultants who need a defensible structure to start from rather than a blank page. It is used at the beginning of a programme — before the gap analysis, because it defines what you are measuring against.
How to work through it
- Map your existing controls onto the catalogue and mark what genuinely exists.
- Adopt the sample policy wording for the controls you keep, editing the document-control table as you go.
- Set the KRIs so the framework produces numbers rather than assertions.
- Run the second-line testing patterns to prove the controls work, not just that they are written down.
- Take the board-reporting template to your management body — Article 5 makes that body accountable.