DORA mapping
How every module in tprm.mlab.sh maps to its DORA article and EBA ITS template - so you can trace each compliance obligation to where it lives in the product.
Scope
tprm.mlab.sh implements DORA Pillar IV - ICT third-party risk (Chapter V of Regulation (EU) 2022/2554). It covers the governance lifecycle (due diligence, contracts, audits, exit, incidents) and the production of the register of information required by Article 28(3): the 15 EBA ITS templates with controlled codes, integrity validation and the deposit-ready xBRL-CSV package.
Module -> DORA article -> EBA template
| Module | Route | DORA article | EBA template(s) |
|---|---|---|---|
| Reporting entity | /ei/ | Art. 28(3) | B_01.01 |
| Scope entities | /se/ | Art. 28(3) | B_01.02 |
| Branches | /br/ | Art. 28(3) | B_01.03 |
| Contracts - general | /ct/ | Art. 28(3), Art. 30 | B_02.01 |
| Contracts - specific | /ct/ | Art. 30(2)/(3) | B_02.02 |
| Intra-group links | /ig/ | Art. 28(3) | B_02.03 |
| Signing entities (receiving) | /ct/ | Art. 28(3) | B_03.01 |
| ICT TPPs signing | /tp/ | Art. 28(3) | B_03.02 |
| Signing entities (providing, intra-scope) | /ct/ | Art. 28(3) | B_03.03 |
| Entities using the services | /ct/ | Art. 28(3) | B_04.01 |
| Providers | /tp/ | Art. 28(1)-(3) | B_05.01 |
| Supply chains (subcontracting) | /sc/ | Art. 28(3), Art. 30(2)(a) | B_05.02 |
| Business functions | /fn/ | Art. 28(3) | B_06.01 |
| Risk assessments | /ra/ | Art. 28(3), Art. 28(4) | B_07.01 |
| Register definitions | /def/ | Art. 28(3) | B_99.01 |
| Due diligence | /dd/ | Art. 28(4) | - (feeds B_07.01) |
| Audit tracking | /al/ | Art. 28(5)-(6) | - |
| Article 30 checklist | /a30/ | Art. 30(2)/(3) | - (drives B_02.02) |
| Exit strategies | /ex/ | Art. 28(8), Art. 30(3)(f) | - (derives plan existence) |
| Concentration risk | /ri/ | Art. 29 | - |
| DORA register | /reg/ | Art. 28(3) | aggregate view |
| EBA export | /eba/ | Art. 28(3) ITS | all 15 |
| Outsourcing register | /or/ | Art. 28(3) (ICT part) | feeds B_02.02 / B_07.01 |
| Proportionality register | /pr/ | Art. 4 | - |
| Provider reviews | /rv/ | Art. 28(1)(b) | - |
| Third-party incidents | /ti/ | Art. 28(3) | - |
| Analytics | /an/ | - | register readiness |
ICT and non-ICT arrangements
The outsourcing register (/or/) spans every third-party arrangement, not only
the ICT ones. Each arrangement carries its services, and each service declares a
nature: ict, non_ict or other.
Only ICT services feed the register of information. Non-ICT outsourcing stays in the outsourcing register and never reaches the EBA templates. This matters for entities whose national regime keeps non-ICT outsourcing under its own rules, and it is enforced at export time rather than left to discipline: an arrangement with no service at all blocks the export until it is classified.
Third-country branches
A branch established in a Member State whose head office sits outside the Union is not a legal entity of its own. Under Q&A DORA102 (ID 3097), DORA applies to such a branch where its head office would qualify as an entity listed in Article 2(1) had it been established in the Union. The branch then has to maintain and file its own register of information.
Declare it on the Entity Information page (/ei/) by answering the branch
question, then run the applicability test. The product records the head office
alongside the branch and maps them as follows:
| What you record | Where it goes |
|---|---|
| Branch LEI, or the head office LEI when GLEIF has issued none | B_01.01 c0010 |
| Branch name | B_01.01 c0020 |
| Branch country | B_01.01 c0030 |
| Head office equivalent entity type (the "would qualify" answer) | B_01.01 c0040 |
| Branch identification code | B_01.03 c0010, and B_04.01 c0040 |
| Head office LEI | B_01.03 c0020, and B_04.01 c0020 |
| Branch name and country | B_01.03 c0030 and c0040 |
Two consequences worth stating plainly:
- The head office is never reported as an entity in scope. It sits outside the Union and is not itself subject to DORA, so it does not appear in B_01.02. Listing it there raises a warning in the validation report.
- The country reported is the branch's, never the third country. The head office country is recorded separately and is used for concentration analysis.
Arrangements used by the branch default to eba_ZZ:x838 (branch of a financial
entity) in B_04.01, carrying the branch code and the head office LEI, which is how
B_01.03 keys a branch.
Scope of the applicability test
The list of Article 2(1) entity types is shown in full, whatever your authority. Where a competent authority publishes a narrower remit, choosing a type outside it raises a non-blocking warning, and the reminder about the national regime for non-ICT outsourcing is shown with its sources. An authority the product has no entry for behaves generically: the full list, and no warning.
For branches supervised by the CSSF, this follows Circular 26/915, which applies with immediate effect from 27 August 2026 with no transitional period. It covers Article 2(1) points (a) to (i), (k) to (m), (p), (r) and (s), and keeps non-ICT outsourcing under Circular 22/806, Part I.
Article 28 - general principles
- 28(3) Register of information. The whole product feeds it; build and export it from
/reg/and/eba/. - 28(4) Pre-contractual due diligence. The due-diligence checklist (
/dd/) records criticality support, supervisory conditions, concentration, conflicts, suitability, information security, continuity and exit strategy, with a decision. - 28(5)-(6) Audit & access rights. Track audit type, scope, findings (with severity) and corrective actions in
/al/. - 28(8) Exit strategies. Documented, versioned and tested exit plans in
/ex/.
Article 29 - concentration risk
The concentration module (/ri/) analyses dependency concentration by category and geography, with explicit risk thresholds, to support the assessment of concentration risk at entity level. For a third-country branch the head office country is a dimension of its own, separate from the branch country, so a concentration of critical providers in the head office's jurisdiction shows up as third-country concentration.
Article 30 - key contractual provisions
The Article 30 checklist (/a30/) verifies the mandatory clauses:
- 30(2) - all contracts: service description, subcontracting conditions, data location, data protection, data access & recovery, incident support, cooperation with authorities, termination rights, security training.
- 30(3) - critical/important functions: business continuity, participation in TLPT, audit rights, exit strategy.
The contract record itself carries the 30(2)/(3) specific fields (notice periods, applicable-law country, data storage & locations, data sensitivity, dependency level, termination reason) that populate template B_02.02.
Controlled vocabularies
Every typed register field uses a DORA 4.0 controlled vocabulary so the export carries regulator-recognised codes:
| Vocabulary | Used for |
|---|---|
eba_CT | Entity type (CT6 / CT61) - credit institution, investment firm, CASP, etc. |
eba_TA | ICT service type (TA4, codes S01-S19) and licensed activity (TA5) |
eba_qCO | Identification code type (LEI / EUID / CRN / VAT / Passport) |
eba_GA | Country (ISO 3166-1 alpha-2) |
eba_CU | Currency |
eba_CO | Type of contractual arrangement (CO1) and termination reason (CO2) |
eba_RP | Group hierarchy (RP8) |
eba_BT | Boolean / yes-no indicators (e.g. criticality BT14, alternatives BT13) |
eba_ZZ | Register-specific scales (sensitivity ZZ92, dependency ZZ91, substitutability, discontinuity impact, etc.) |
Next: see EBA export for how these modules aggregate into the 15 templates and the deposit-ready package.