The question "which policies does DORA require" has a defined answer, and it is not "the ICT security policy and some others". Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA), names its policies by article. A competent authority or an internal auditor opening your policy register works backwards from those articles: a policy whose article number does not appear in the register is a policy that is not written down. This article is the enumeration. For each policy the regulation names, you get the article that imposes it, who has to approve it, the minimum content the regulation itself calls for, and the review cadence.
How the policy set is organised
DORA layers the policy set in three tiers, and keeping them apart is the first fix most registers need. At the top sits the ICT risk management framework and, beside it, the digital operational resilience strategy. Below those, a documented information security policy and the sub-policies the regulation names inside Articles 9 to 14. Alongside the top-of-the-house layer, a separate policy on the use of ICT services provided by ICT third-party service providers governs the fourth pillar.
Treat the framework document as a container that references the policies, not as a long policy itself. Reviewers follow the references down, and a policy that is only mentioned in the framework document but never written as a standalone artefact fails the chain at the second step. Our guide to building the ICT risk management framework covers the container; this article covers what has to live inside it.
The top-of-the-house policies
Three artefacts sit above the rest. All three are approved by the management body, and the approvals have to be dated and recorded in board minutes.
| Artefact | Legal basis | Approver | Review cadence |
|---|---|---|---|
| ICT risk management framework | Art. 5(2), Art. 6(1) | Management body | At least yearly, and after any major ICT-related incident (Art. 6(5)) |
| Digital operational resilience strategy | Art. 6(8) | Management body | Set out as part of the framework, same cadence |
| Documented information security policy | Art. 9(4) | Management body (as part of the framework it sits inside) | Reviewed by regular internal ICT audit (Art. 6(6)) |
The strategy is the item most often missing. Article 6(8) lists what it has to set out, including how the framework supports the business strategy and objectives, risk tolerance for ICT risk, clear information security objectives, the ICT reference architecture, and the mechanisms to detect, protect against and prevent impacts from ICT-related incidents. A strategy that is not traceable back to the framework fails the Article 6(8) chain, and a framework without a strategy fails Article 6(8) by omission.
The ICT security sub-policies named in Article 9
Article 9(4) is drafted as a list of what the ICT security policy, procedures, protocols and tools shall do. Delegated Regulation (EU) 2024/1774, the Regulatory Technical Standards (RTS) on ICT risk management tools, methods, processes and policies, develops that list into the specific policies the entity has to maintain. The RTS is where you look for the content of each sub-policy, not DORA itself.
| Sub-policy | Legal basis | Core content the regulation calls for |
|---|---|---|
| Information security policy | Art. 9(4), RTS Art. 2 | Objectives, principles, roles and responsibilities for information security |
| Human resources policy with ICT security elements | Art. 9(4), RTS Art. 19 | Security requirements through hire, change of role and exit, including return of assets |
| Access control policy | Art. 9(4)(e), RTS Art. 20 and 21 | Need-to-know, least privilege, segregation of duties, recertification cadence, privileged access controls |
| Cryptographic controls and key management policy | Art. 9(2), RTS Art. 6 and 7 | Approved algorithms, key lifecycle, custody and renewal, exceptions log |
| ICT change management policy | Art. 9(4)(f), RTS Art. 17 and 18 | Assessment, approval, testing and release of changes to ICT systems and software |
| Patch and update management policy | Art. 9(4)(g), RTS Art. 10 | Classification, target windows and exception records where the window is missed |
| Vulnerability management policy | Art. 9(4)(c), RTS Art. 10 | Discovery, assessment, prioritisation, remediation and reporting of ICT vulnerabilities |
| Logical and physical security policy | Art. 9(4)(d), RTS Art. 12 and 13 | Perimeter, workstation, server, network segmentation and physical access to ICT premises |
| Capacity and performance management policy | Art. 9(2), RTS Art. 9 | Forecasting, monitoring and prevention of capacity shortages for ICT resources |
| Logging policy | Art. 9(2), Art. 10, RTS Art. 12 | Events to be logged, retention periods, protection of logs against tampering |
The access control policy and the change management policy generate the most findings, because both leave dated trails that either exist or do not. The recertification cadence set in the access policy has to match what the privileged access inventory can show, and the change policy has to match what the ticketing system records.
The business continuity, backup and communication policies
Articles 11, 12 and 14 name three further policies that sit on their own, outside the Article 9 security sub-policy set.
| Policy | Legal basis | Approver | Review cadence |
|---|---|---|---|
| ICT business continuity policy | Art. 11(1) | Management body (Art. 11(1), through its oversight of the framework) | At least yearly, with the framework (Art. 6(5)) |
| ICT response and recovery plans | Art. 11(3) | Owner designated in the framework, approved under the framework governance | Tested at least yearly on scenarios of the kind listed at Art. 11(6) |
| Backup policy and procedures | Art. 12(1) | Owner designated in the framework | Reviewed on the cadence set in the framework |
| Restoration and recovery procedures | Art. 12(2) | Owner designated in the framework | Tested, with the restoration tests feeding the review |
| Crisis communication plan | Art. 14(2) | Set out in the framework, approved under its governance | Reviewed yearly |
Two notes on this layer. First, Article 12(2) is about procedures, not just a policy: the restoration test on a system supporting a critical or important function is the evidence that closes it, not a backup job log. Second, Article 14 is about communication to clients, counterparties and the public in a crisis, and the plan has to disclose at least a single point of contact.
The incident policy and the third-party policy
Two further policies sit on their own, one per pillar.
| Policy | Legal basis | Approver | What it has to contain |
|---|---|---|---|
| ICT-related incident management process | Art. 17(1), Art. 17(3) | Owner designated in the framework | Procedures to identify, track, log, categorise, classify, respond, communicate and conclude incidents, consistent with Article 18 classification |
| Policy on the use of ICT services provided by ICT third-party service providers | Art. 28(2), Delegated Regulation (EU) 2024/1773 | Management body (Art. 28(2)) | Pre-contractual, contractual and ongoing arrangements, including subcontracting conditions, exit arrangements, concentration monitoring |
Article 28(2) is explicit on who signs: the management body shall approve, review and update the policy, and the review has to happen regularly and at least yearly. Delegated Regulation (EU) 2024/1773 details the content, and a policy that does not reference the delegated regulation by name is a policy that has not been checked against it.
The policies the regulation does not name
A policy register that only contains what DORA names is likely too short. A register that pads itself with policies DORA does not name, and labels them "required by DORA", is a register that fails the chain in the other direction. Two examples recur:
- A standalone "DORA compliance policy". DORA imposes no such policy. The framework is the compliance artefact. Writing a parallel policy on top of it creates two sources of truth and keeps neither of them current.
- A standalone "cloud policy" presented as a DORA requirement. DORA does not name a cloud policy. Cloud services fall under Article 28 and the related delegated regulations like any other ICT third-party service, and your third-party policy covers them. A separate cloud standard is a reasonable internal choice, but citing DORA as its legal basis is a misstatement.
The reverse of the two is also useful. An internal policy you keep because operational experience showed it was needed, such as a dedicated API security standard or a cloud configuration baseline, does not have to pretend to a DORA basis to be worth maintaining. Writing "internal good practice" where there is no DORA article to cite is more honest, and it survives a reviewer who checks the citation.
What to do next
Open your policy register and run the article column against the tables above. Four questions settle most gaps: is the policy present, is its approver recorded, is the last review date within cadence, and does the policy reference the article that imposes it. A policy that answers all four is a policy a reviewer can read in context. Our interactive DORA compliance checklist pairs each pillar with the artefact that closes it, and the RTS reference links the Article 9 sub-policies back to Delegated Regulation (EU) 2024/1774 clause by clause.
Two expectations before you start. The sub-policy set inside Article 9 is where most registers come up short, because it is spread across the RTS rather than inside DORA itself. And the Article 28(2) policy is the one most often held at departmental level when it is a board-approved document: moving it up to the management body with a dated minute is usually the fastest audit fix in the whole register.
