DORA policy template: copy-paste skeleton¶

Use this skeleton as the starting point for any DORA-required policy or procedure in your register. Every section is named, the article references are pre-filled, and the body text is a fill-in-the-blanks version of a real working policy. Replace the bracketed placeholders [like this] with the content for your entity, and the document is ready for legal review.

The template pairs with the clauses corner index. For each row in the table, duplicate this file, give it the document name as the title, and edit sections 1, 2, 3 and 6 to match the scope of that document.

How to use the template¶

Copy the file to a new name that matches the document, for example 01_information_security_policy.md or 12_backup_procedures.md.
Edit section 1 (Document control) with your entity name, document owner, approver, version and review cadence.
Edit section 2 (Purpose and scope) in plain English. Two short paragraphs. The first says what the document exists to do. The second says who and what it covers, and what it does not cover.
Edit section 3 (Regulatory references). The placeholders already cite the right DORA articles. Keep them. Add the row from the clauses corner index for the document you are writing.
Edit section 4 (Definitions). Only define terms you actually use in the body. The minimum set is shown.
Write section 5 (Policy statements). The template ships with five empty statement slots. Add or remove statements to match the policy. Each statement should be one rule, one subject, one verb.
Edit section 6 (Roles and responsibilities) with the three lines of defence (operational, risk, internal audit) plus the management body where the regulation requires it.
Edit section 7 (Exceptions and deviations). Keep this short. One paragraph. The default is "no exceptions without written approval".
Edit section 8 (Review and evidence). The template ships with three evidence rows. Add rows for anything you need to be able to produce on request from the competent authority.

Style and tone

Plain language. Active voice. No em dashes. No "ensure that" filler. State the rule, the trigger, the action, and the record. If a sentence does not change a decision, delete it. The point of the policy is to be read by an operator in a hurry and produce a defensible action, not to be admired.

Template¶

---
title: "[Document name]"
owner: "[Role title, e.g. Chief Information Security Officer]"
approver: "[Role title, e.g. Management Body]"
version: "1.0"
effective_date: "YYYY-MM-DD"
next_review: "YYYY-MM-DD"
classification: "[Public | Internal | Confidential]"
---

# [Document name]

**One-line statement.** [What this document does, in a single sentence. The reader should know in five seconds whether this is the document they are looking for.]

## 1. Document control

| Field | Value |
|---|---|
| Document owner | [Role title] |
| Approver | [Role title] |
| Version | 1.0 |
| Effective date | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | Public / Internal / Confidential |
| Change log | Initial release |

## 2. Purpose and scope

**Purpose.** [One short paragraph. What the document exists to do, and the obligation it discharges. Reference the DORA article or RTS article that drives the requirement.]

**Scope.** [One short paragraph. Who is in scope (roles, business units, third parties), what is in scope (systems, processes, locations), and what is explicitly out of scope. State the boundary in plain words.]

## 3. Regulatory references

The document supports compliance with the following provisions. The article numbers are taken from the BaFin overview *Documentation requirements for financial entities according to DORA* and the EUR-Lex Level 1 text. Always verify against the current consolidated text before relying on the references in a filing.

| Source | Article | What it requires |
|---|---|---|
| Regulation (EU) 2022/2554 (DORA) | [Art. X(Y) DORA] | [Short plain-English summary of the obligation] |
| Commission Delegated Regulation [reference] (RTS RMF / RTS TPPol / RTS CCI / RTS CTIR) | [Art. X RTS] | [Short plain-English summary] |
| Commission Implementing Regulation [reference] (ITS RoI / ITS TIR) | [Art. X ITS] | [Short plain-English summary] |

The full table of DORA documentation requirements is in the [clauses corner index](clauses-corner.md).

## 4. Definitions

The terms below are used in this document. They are quoted or paraphrased from DORA Article 3 where the regulation defines them.

| Term | Definition |
|---|---|
| **ICT risk** | [DORA Art. 3(13) or your own definition if the term is not regulated] |
| **[Term 2]** | [Definition] |
| **[Term 3]** | [Definition] |

Add definitions only for terms you use in the body. If you use a term once, write it in plain words instead.

## 5. Policy statements

The numbered statements below are the binding rules of this document. Every statement is one rule, one subject, one verb. Operators read this section first; everything else is context.

1. **[Subject, verb, condition, record.]** [Statement 1.]
2. **[Subject, verb, condition, record.]** [Statement 2.]
3. **[Subject, verb, condition, record.]** [Statement 3.]
4. **[Subject, verb, condition, record.]** [Statement 4.]
5. **[Subject, verb, condition, record.]** [Statement 5.]

[Add or remove statements to match the policy. Five is a working minimum for a single-page policy; ten is a working maximum for a single-page policy. If you need more than ten, split the document.]

## 6. Roles and responsibilities

The three lines of defence model applies. Each role owns the actions in section 5 that fall within its mandate.

| Line of defence | Role | Owner of |
|---|---|---|
| First line | [Head of business unit / process owner] | Operating the controls in section 5 |
| Second line | [Chief Information Security Officer / Chief Risk Officer / Head of ICT risk] | Setting the policy, monitoring, exception handling |
| Third line | [Head of Internal Audit] | Independent assurance over the design and operation of the controls |

Where the regulation requires the management body to approve, retain or oversee the matter, the relevant body is the **[Management Body / Board / Local Process Owner Committee]**, with the **[relevant committee, e.g. Risk Committee, Audit Committee]** advising.

## 7. Exceptions and deviations

No exception to the policy is valid without prior written approval from the document owner and the second line of defence. Exceptions are recorded in the exceptions register, time-bound (maximum twelve months), and reviewed at the next scheduled review of the policy. Repeated exceptions are a signal that the policy needs to be redrafted, not that the rule should be abandoned.

## 8. Review and evidence

The document is reviewed at least annually, or sooner if a material change occurs in the underlying regulation, the entity's ICT risk profile, or the regulatory expectations of the competent authority. The table below lists the evidence the document owner must be able to produce on request.

| Evidence | Where it lives | Retention |
|---|---|---|
| [Evidence 1, e.g. signed policy acknowledgement per staff member] | [System / repository] | [Retention period] |
| [Evidence 2, e.g. annual review minutes] | [System / repository] | [Retention period] |
| [Evidence 3, e.g. exception register entries] | [System / repository] | [Retention period] |

## 9. Related documents

- [Link to the related policy, e.g. ICT risk management framework]
- [Link to the related procedure, e.g. backup procedure]
- [Link to the related register, e.g. register of information]
- [Link to the underlying regulation, e.g. EUR-Lex CELEX:32022R2554]

---

**Approval.**

| Role | Name | Date | Signature |
|---|---|---|---|
| Document owner |  |  |  |
| Second line approver |  |  |  |
| Management body (where required) |  |  |  |

Worked fill-in: information security policy¶

Below is a worked example for the Information security policy row of the clauses corner. The article references are the ones BaFin cites for that document. Replace the bracketed placeholders with your own entity's content.

---
title: "Information security policy"
owner: "Chief Information Security Officer"
approver: "Management Body"
version: "1.0"
effective_date: "2026-09-01"
next_review: "2027-09-01"
classification: "Internal"
---

# Information security policy

**One-line statement.** Sets the binding information security rules for all staff and third parties handling the entity's ICT systems and data, and discharges the obligation under DORA Article 9(4)(a).

## 1. Document control

| Field | Value |
|---|---|
| Document owner | Chief Information Security Officer |
| Approver | Management Body |
| Version | 1.0 |
| Effective date | 2026-09-01 |
| Next review | 2027-09-01 |
| Classification | Internal |
| Change log | Initial release |

## 2. Purpose and scope

**Purpose.** This document defines the binding information security rules that protect the confidentiality, integrity and availability of the entity's ICT systems and the data they process, in support of DORA Article 9(4)(a).

**Scope.** The policy applies to all employees, contractors and third parties of [Entity name] with access to ICT systems, regardless of location or device. It covers all ICT systems, whether operated by the entity or by an ICT third-party service provider. It does not cover physical security, which is governed by the physical and environmental security policy.

## 3. Regulatory references

| Source | Article | What it requires |
|---|---|---|
| DORA | Art. 9(4)(a) | Develop and document an information security policy defining the rules to protect the availability, authenticity, integrity and confidentiality of data and ICT assets |
| DORA | Art. 9(2) | Implement protection and prevention controls |
| DORA | Art. 9(4)(e) | Implement policies for ICT change management |
| DORA | Art. 9(4)(c) | Implement control of access management rights |
| RTS 2024/1774 (RTS RMF) | Section 2 (access control) | Detailed access control requirements |

## 4. Definitions

| Term | Definition |
|---|---|
| **ICT system** | A system as defined in DORA Art. 3(7) |
| **Access right** | A permission to use an ICT system, granted and revoked in line with the least-privilege principle |
| **Information security event** | An identified occurrence indicating a possible breach of information security policy or failure of controls |

## 5. Policy statements

1. All staff and third parties acknowledge this policy in writing before being granted access to any ICT system, and re-acknowledge after every material change.
2. Access rights are granted on a least-privilege basis, reviewed at least quarterly, and revoked within 24 hours of a change of role or termination.
3. All ICT systems are classified by confidentiality and integrity impact, and the access controls applied are proportionate to that classification.
4. Information security events are logged, classified and responded to under the ICT-related incident management process, with records retained for at least five years.
5. Exceptions to the policy are recorded in the exceptions register and approved in writing by the CISO and the CRO before they take effect.

## 6. Roles and responsibilities

| Line of defence | Role | Owner of |
|---|---|---|
| First line | Business unit heads | Operating the access controls and event response in their unit |
| Second line | CISO | Maintaining the policy, monitoring compliance, approving exceptions |
| Third line | Head of Internal Audit | Independent assurance over the design and operation of the controls |

The Management Body approves the policy and reviews compliance at least annually.

## 7. Exceptions and deviations

No exception to this policy is valid without prior written approval from the CISO and the CRO. Exceptions are time-bound, recorded in the exceptions register, and reviewed at the next scheduled policy review. Repeated exceptions are a signal that the policy needs to be redrafted, not that the rule should be abandoned.

## 8. Review and evidence

| Evidence | Where it lives | Retention |
|---|---|---|
| Signed policy acknowledgement per staff member | HR system, linked to user record | Duration of employment plus 2 years |
| Quarterly access review records | Identity governance system | 5 years |
| Exception register entries | Risk register | 5 years from closure |
| Information security event records | SIEM | 5 years |

## 9. Related documents

- [Link to ICT risk management framework policy]
- [Link to ICT-related incident management policy]
- [Link to identity management procedures]
- [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554)

---

**Approval.**

| Role | Name | Date | Signature |
|---|---|---|---|
| Document owner | [CISO name] |  |  |
| Second line approver (CRO) | [CRO name] |  |  |
| Management body chair | [Chair name] |  |  |

Note. The worked example is for one row of the clauses corner index. To produce a complete policy stack, duplicate the template for each row, change the article references in section 3, and rewrite sections 2, 4 and 5 to match the document. A team of two can usually draft the full stack in two working days once the article references are pre-filled.