DORA Register of Information: Template Spec + Mandatory Fields (Article 28)

The Digital Operational Resilience Act (DORA) transforms ICT third-party risk from a best practice into a supervisory reporting obligation. Article 28 requires every financial entity to maintain a "register of information" on all ICT third-party service providers—whether critical or not. This register is not a static spreadsheet; it is a living document that feeds into concentration-risk dashboards, exit-planning exercises, and annual supervisory filings. Below, we break down the exact field-level specification, update cadence, and common audit pitfalls.

---

1. Article 28 Register Obligation: Who Maintains It, Who Audits It

1.1 Maintenance responsibility

DORA Article 28(1) places the obligation squarely on the financial entity’s management body. In practice, the register is compiled by the second line (Risk or Compliance) and owned by the first line (business units that contract the services). The Chief Information Security Officer (CISO) or Chief Risk Officer (CRO) must sign off on completeness and accuracy before each supervisory submission.

1.2 Audit and supervisory access

The register is subject to:

• Internal audit (at least annually, per DORA Article 26(2))
• External audit (included in the statutory audit of the financial statements, per the relevant provision of the Audit Directive)
• Direct supervisory inspection by the competent authority (DORA Article 35).

Competent authorities may request the register within 24 hours (EBA RTS on ICT risk management, Article 3(3)).

---

2. EBA RTS Mandatory Fields: Table with Field Name, Format, Example

The EBA final draft RTS on ICT risk management (EUR-Lex Regulation 2024/1455) specifies 22 mandatory fields. We map them below in a practical Excel/CSV column layout.

Notes on format:

• Use UTF-8 encoding for CSV to handle special characters in provider names.
• Boolean fields should be TRUE/FALSE (uppercase) for machine readability.
• Repeating fields (e.g., data location) should be pipe-delimited: DE|FR|US.

---

3. Concentration Risk Metrics: Top-N Provider Exposure Tracking

3.1 Quantitative thresholds

DORA does not prescribe hard concentration limits, but the EBA RTS requires entities to calculate:

• Spend ratio: Annual ICT spend with a single provider divided by total ICT spend (cap at 25% for critical providers).
• Data ratio: Volume of restricted data stored with a single provider divided by total restricted data (cap at 30%).
• Service dependency: Number of critical business processes relying on a single provider (cap at 40%).

3.2 Top-N dashboard

Maintain a separate worksheet or BI view that:

1. 1Ranks providers by spend ratio (descending).
2. 2Flags any provider exceeding 15% spend ratio with a red indicator.
3. 3Displays a 12-month trend line for each top-5 provider.

Example Excel formula for spend ratio:

=SUMIFS(Spend_Column, Provider_ID_Column, Current_Provider_ID) / SUM(Spend_Column)

---

4. Substitutability Assessment: How to Score Each Provider

4.1 Scoring methodology

The EBA RTS mandates a substitutability score (1–5) for every provider, where:

• 1: No viable alternative exists (e.g., core banking system with 10-year lock-in).
• 3: Alternative exists but requires 6–12 months migration.
• 5: Multiple alternatives available with <3 months migration.

4.2 Assessment criteria

Example calculation:

Market (4) × 0.30 = 1.20
Contract (2) × 0.25 = 0.50
Data (3) × 0.20 = 0.60
Tech (1) × 0.15 = 0.15
Reg (5) × 0.10 = 0.50
Total = 2.95 → Round to 3

---

5. Annual Update Cadence + Supervisory Submission Timeline

5.1 Update triggers

• Quarterly: Performance metrics, incident history, subcontracting depth.
• Semi-annually: Concentration risk scores, substitutability scores.
• Annually (by 31 March): Full register, including contractual clauses and exit strategies.
• Ad-hoc: Within 30 days of any material change (