# DORA Register of Information — Full Documentation

> Browser-based tool for preparing, validating and exporting the DORA Register of Information required under EU Regulation 2022/2554 (DORA) and Commission Implementing Regulation (EU) 2024/2956 (ITS).

Built by [FromCISO](https://fromciso.com). Available at [roi.fromciso.com](https://roi.fromciso.com).

---

## Overview

DORA RoI is a browser-based tool for preparing the Register of Information required under the Digital Operational Resilience Act (DORA — EU Regulation 2022/2554) and its Implementing Technical Standard (ITS — EU Commission Implementing Regulation 2024/2956).

Financial entities within the EU must maintain and submit a register documenting all contractual arrangements with ICT third-party service providers. The register reference date is 31 December 2025. Financial entities submit to their competent authority according to local deadlines; from 2026, competent authorities report to the ESAs by 31 March annually.

### What This Tool Does

DORA RoI helps you fill out, validate, and export the 15 register templates laid down in Commission Implementing Regulation (EU) 2024/2956. You can enter data manually template by template, or import from Excel. The tool guides you through entity information, contractual arrangements, signatories, service usage, ICT providers, function mapping, and risk assessments. When you are ready, it exports a compliant xBRL-CSV package for submission to your competent authority.

### Privacy by Design

This tool runs entirely in your browser. Your data is stored in localStorage and never leaves your device. No data is sent to any server. You can verify this by inspecting network traffic — there are no API calls after the initial page load.

## Key Dates

| Milestone | Date |
|-----------|------|
| DORA entry into force | 16 January 2023 |
| DORA application date | 17 January 2025 |
| ITS published in Official Journal | 20 November 2024 |
| ITS entry into force | 10 December 2024 |
| Register reference date | 31 December 2025 |
| CA-to-ESA reporting deadline | 31 March annually (from 2026) |

## Regulatory Background

DORA (Regulation (EU) 2022/2554) establishes a comprehensive framework for digital operational resilience in the EU financial sector. Article 28 requires financial entities to maintain a register of information on all contractual arrangements with ICT third-party service providers.

The ITS (Commission Implementing Regulation (EU) 2024/2956) specifies the exact format and content of this register, defining 15 templates organized into 8 groups: entity information, contractual arrangements, signatories, service usage, ICT providers, functions, assessments, and definitions.

The register must be reported to competent authorities such as the ECB, EBA, EIOPA, or national financial supervisory bodies. The reporting format is xBRL-CSV, following the EBA Taxonomy 4.0.

---

## Getting Started

### Step 1: Configure Settings

Start on the Settings page. You need to configure:

- **LEI** — The Legal Entity Identifier (20 alphanumeric characters) of the entity maintaining the register.
- **Entity name** — The legal name of the financial entity.
- **Country** — The ISO 3166-1 alpha-2 country code (e.g., LV, DE).
- **Reporting type** — IND (individual) or CON (consolidated).
- **Reference date** — Typically 2025-12-31 for the first submission.
- **Reporting currency** — The base currency for monetary values (e.g., EUR).
- **Competent authority** — The national supervisory authority (e.g., FKTK, BaFin).

### Step 2: Fill Entity Information

1. **B_01.01** — Entity maintaining the register (exactly 1 row for IND reporting)
2. **B_01.02** — Entities in consolidation (only for CON reporting)
3. **B_01.03** — Branches located outside the home country

### Step 3: Register Contracts

1. **B_02.01** — Contractual arrangements (general): one row per arrangement with unique reference number
2. **B_02.02** — Contractual arrangements (specific): detailed info including provider, function, ICT service type, dates

### Step 4: Add Signatories

1. **B_03.01** — Entity signatories (links arrangement to signing financial entity)
2. **B_03.02** — Provider signatories (links arrangement to signing ICT provider)
3. **B_03.03** — Financial entity ICT providers (for intra-group arrangements)

### Step 5: Map Service Usage

1. **B_04.01** — Entities making use of ICT services

### Step 6: Register Providers

1. **B_05.01** — ICT third-party service providers (comprehensive identification and details)
2. **B_05.02** — ICT service supply chain (subcontracting relationships)

### Step 7: Define Functions

1. **B_06.01** — Functions identification (taxonomy of entity functions supported by ICT services)

### Step 8: Complete Assessments

1. **B_07.01** — Assessments of ICT services supporting critical or important functions

### Step 9: Add Definitions (Optional)

1. **B_99.01** — Entity definitions (custom internal definitions for closed-list field values)

### Step 10: Validate and Export

Run validation (four layers: technical, DPM, business logic, EBA rules), fix all errors, then export as xBRL-CSV ZIP.

### Recommended Fill Order

1. Settings → 2. B_01.01 → 3. B_01.02 (if CON) → 4. B_01.03 → 5. B_05.01 → 6. B_06.01 → 7. B_02.01 → 8. B_02.02 → 9. B_03.01, B_03.02, B_03.03 → 10. B_04.01 → 11. B_05.02 → 12. B_07.01 → 13. B_99.01

---

## Template Reference

The DORA Register consists of 15 templates organized into 8 groups:

| Template | Name | Group |
|----------|------|-------|
| B_01.01 | Entity maintaining the register | Entity Information |
| B_01.02 | List of entities within the scope of consolidation | Entity Information |
| B_01.03 | List of branches | Entity Information |
| B_02.01 | Contractual arrangements — General information | Contractual Arrangements |
| B_02.02 | Contractual arrangements — Specific information | Contractual Arrangements |
| B_02.03 | Intra-group contractual arrangements | Signatories |
| B_03.01 | Entities signing contractual arrangements | Signatories |
| B_03.02 | ICT third-party service providers signing contracts | Signatories |
| B_03.03 | Financial entities providing ICT services | Signatories |
| B_04.01 | Entities making use of ICT services | Service Usage |
| B_05.01 | ICT third-party service providers | ICT Providers |
| B_05.02 | ICT service supply chain | ICT Providers |
| B_06.01 | Functions identification | Functions |
| B_07.01 | Assessments of ICT services supporting critical or important functions | Assessments |
| B_99.01 | Entity definitions | Definitions |

Templates are interconnected through foreign-key relationships — a value entered in one template often references a record in another.

---

## Import Guide

DORA RoI supports importing register data from Excel (.xlsx) files. Excel files are parsed entirely in the browser — no upload to any server occurs.

### Supported Format

The import expects an Excel workbook with one sheet per DORA template. Each sheet must be named exactly as the template code (e.g., B_01.01, B_02.01).

### Header Row

The parser recognizes headers in two formats:
- **DPM column codes** (preferred) — e.g., c0010, c0020, c0030
- **Human-readable labels** — e.g., "LEI of the entity". The parser performs fuzzy matching.

### Auto-Extracted Settings

When importing, the tool automatically extracts settings from B_01.01:
- LEI (c0010), Entity name (c0020), Country (c0030), Reference date (c0060)

### Date Handling

Excel serial date numbers, ISO strings, formatted dates, and DateTime values are all supported and converted to yyyy-mm-dd format.

---

## Validation Guide

Before exporting, the register is validated by a four-layer engine:

### Layer 1: Technical Validation

- Mandatory fields must have non-empty values
- LEI: exactly 20 alphanumeric characters per ISO 17442
- Dates: yyyy-mm-dd format; 9999-12-31 for open-ended
- Country codes: ISO 3166-1 alpha-2
- Currency codes: ISO 4217
- Monetary values: plain numbers, no symbols
- Text length constraints

### Layer 2: DPM Validation

- Closed-list enforcement (select fields only accept predefined values)
- Referential integrity (foreign key checks between templates)
- Key uniqueness (e.g., LEIs in B_01.02 must be unique)

### Layer 3: Business Logic Validation

- CA_3 (subsequent) arrangements must reference an overarching arrangement
- Start date must be on or before end date
- Branch nature (NE_2) requires branch identification code
- Supply chain rank must be at least 1

### Layer 4: EBA Validation Rules

- Existence rules (e-series): required fields when template row exists
- Conditional mandatory rules (v-series): fields mandatory based on other field values
- Cross-field consistency rules

### Cross-Template Validation

- All arrangement refs must correspond to entries in B_02.01
- All provider codes must exist in B_05.01
- All function IDs must exist in B_06.01
- Arrangements should have signatory entries in B_03.01/B_03.02

---

## Export Guide

### xBRL-CSV Format

xBRL-CSV is a tabular reporting format defined by XBRL International. It represents structured financial and regulatory data as CSV files within a ZIP package, accompanied by JSON metadata. The EBA has adopted xBRL-CSV for DORA reporting using the EBA Taxonomy 4.0.

### ZIP Package Structure

```
{package-name}/
  META-INF/
    reportPackage.json          # Package manifest
  reports/
    report.json                 # xBRL-CSV report metadata (EBA Taxonomy 4.0)
    parameters.csv              # Entity identifier, reference date, currency
    FilingIndicators.csv        # 15 templates, all reported = true
    b_01.01.csv                 # Template data files
    b_01.02.csv
    ... (all 15 template CSVs)
    b_99.01.csv
```

### report.json

```json
{
  "documentInfo": {
    "documentType": "https://xbrl.org/2021/xbrl-csv",
    "extends": [
      "http://www.eba.europa.eu/eu/fr/xbrl/crr/fws/dora/4.0/mod/dora.json"
    ]
  }
}
```

### parameters.csv

```
name,value
entity,rs:{LEI}.{IND|CON}
refDate,2025-12-31
baseCurrency,iso4217:EUR
```

### FilingIndicators.csv

```
templateID,reported
B_01.01,true
B_01.02,true
...
B_99.01,true
```

### Filename Convention

```
{LEI}.{IND|CON}_{COUNTRY}_DORA010100_DORA_{REFDATE}_{TIMESTAMP}.zip
```

### CSV Encoding

- Character encoding: UTF-8 (no BOM)
- Delimiter: Comma
- Line ending: CRLF
- Text qualifier: Values containing commas or newlines are quoted

---

## Security & Privacy

### Zero-Trust Data Architecture

DORA RoI is built on a client-only architecture. All data processing, validation, and export happen exclusively in the browser. No register data is ever transmitted to, processed by, or stored on any server.

### Data Storage

| Storage | What Is Stored | Lifetime |
|---------|---------------|----------|
| localStorage (Register) | All 15 template datasets | Until manually cleared |
| localStorage (Settings) | LEI, entity name, country, reporting type | Until manually cleared |
| localStorage (Auth) | Email address for access gate | Until sign-out |
| In-memory only | Validation results, import data, UI state | Lost on page refresh |

### Network Security

After initial page load, DORA RoI makes zero network requests with register data. The only server endpoints are:
- POST /api/gate — Email verification (email only, no register data)
- POST /api/gate/logout — Sign out

### Client-Side Processing

- Validation Engine: four-layer engine runs in browser
- Export Engine: xBRL-CSV ZIP generated client-side via fflate
- Import Parser: Excel files parsed via xlsx library in-browser
- Access Gate: Email-based allowlist, session cookie carries zero register data

### Threat Model

| Threat | Mitigation | Risk |
|--------|-----------|------|
| Server-side data breach | No register data stored server-side | Eliminated |
| Man-in-the-middle | HTTPS; no register data in transit | Minimal |
| XSS | React auto-escaping; CSP headers | Low |
| CSRF | No state-changing server endpoints for register data | Eliminated |
| Physical device access | Access gate; browser profile isolation | Medium |
| Malicious browser extension | Origin isolation | Medium |
| Supply chain attack | Minimal dependency footprint | Low |
| Accidental data loss | JSON backup + Excel re-import | Low |

### Security Recommendations

**For Organizations:**
1. Use a dedicated browser profile
2. Enable full-disk encryption (BitLocker/FileVault/LUKS)
3. Regular JSON backups stored in encrypted locations
4. Audit browser extensions
5. Lock device when stepping away
6. Clear browser data between reporting periods
7. Treat ZIP and JSON exports as confidential
8. The app works on restricted networks (no data transmitted)

**For IT Security Teams:**
1. Verify zero-transmission with web proxy / DLP
2. Review CSP headers
3. Ensure EDR/XDR coverage for extension monitoring
4. Classify DORA register exports as Confidential/Internal

### GDPR

Register data (ICT contracts, provider details) is processed and stored entirely in the browser. For register data, DORA RoI does not act as data processor or controller.

Access data (email address) is collected for the access gate and stored in HubSpot. For this data, FromCISO acts as the data controller.

---

## Links

- Homepage: https://roi.fromciso.com
- Documentation: https://roi.fromciso.com/docs
- Getting Started: https://roi.fromciso.com/docs/getting-started
- Import Guide: https://roi.fromciso.com/docs/import-guide
- Template Reference: https://roi.fromciso.com/docs/templates
- Validation Guide: https://roi.fromciso.com/docs/validation
- Export Guide: https://roi.fromciso.com/docs/export
- Security & Privacy: https://roi.fromciso.com/docs/security
- Privacy Policy: https://roi.fromciso.com/privacy
- Terms of Service: https://roi.fromciso.com/terms
- DORA Regulation: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- ITS Regulation: https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj
- EBA Taxonomy 4.0: https://www.eba.europa.eu/risk-and-data-analysis/reporting/reporting-frameworks/reporting-framework-40