The DORA ICT third-party register

DORA Article 28(3) requires a financial entity to maintain a register of information about every contractual arrangement for the use of ICT services, and to report it to its competent authority. It is the single most concrete deliverable in the regulation: an auditor can ask to see it, read it in five minutes and tell whether you have been keeping it.

Qorionix holds that register. This article covers what a row records, what the two status fields mean, how the concentration view is meant to be read, and — at some length, because it is the part that decides whether the page is useful or misleading — what the register cannot tell you about your own compliance.

Where it is, and who can use it

In the console under Govern → DORA, headed ICT third-party register. Reading it needs the compliance:frameworks permission with the read action; adding or updating a provider needs the same resource with write. If the Add provider button is missing, that is the permission to ask your administrator for — see Who can see and do what.

What a row records

Provider

The name of the third party. Required; everything else can be filled in later.

Function

What the arrangement supports — cloud hosting, payroll, core banking, managed IT. Free text. Shown as Function not stated when empty, deliberately rather than blank.

Country

A two-letter ISO 3166-1 code. Anything longer is refused with a message rather than trimmed to fit: a column that quietly turned Netherlands into Ne would put a wrong country in a regulator-facing register.

Critical or important

Whether the arrangement supports a critical or important function. Almost every other obligation in DORA keys off this flag, so it is the field to get right first. The platform does not decide it for you.

What it processes

What the provider actually handles on your behalf. The register of information asks for it, and it is what makes the concentration view mean anything: three providers in one country matter far more when all three hold customer records.

Contract status

One of six values, described below.

Exit plan status

One of four values, described below.

Exit strategy

Free text: how you would actually leave. Distinct from the status field on purpose — prose in this box is not the same claim as an exercised exit.

Contract start and end

Start defaults to today if you do not supply one. End is optional, for an open-ended arrangement.

The two status fields, and why they start badly

Both status fields default to their worst honest value when you do not state one. A provider added without a contract position is unknown, not neutral; one added without an exit plan is none, not blank. That is a deliberate design decision: a register that improved the moment a row was added to it would be worse than no register, because it would produce a page of green badges describing arrangements nobody has looked at.

A critical arrangement whose exit plan is anything other than tested is flagged on the page with the note Art. 28(8) expects a tested exit plan for a critical arrangement. That flag is the most useful thing on the screen, and it is the one most likely to be uncomfortable the first time you fill the register in honestly.

The four numbers at the top

• Providers — how many rows are in the register.
• Critical — how many support a critical or important function.
• Untested exits — critical arrangements whose exit plan is not tested. This is your Article 28(8) gap list, as a number.
• Contract gaps — critical arrangements not marked dora_aligned. This is your Article 30 gap list.
• Countries — how many distinct countries your providers sit in.

Every one of those is arithmetic over what you typed. None of them is verified against anything. A register with one row and no gaps reports zero gaps, and means nothing.

The concentration view is a count, not a verdict

Below the register, arrangements are grouped by function and country, with a total and a count of the critical ones. That is the whole calculation.

Six duties this register cannot measure

The register is one artefact DORA asks for. Most of the regulation is about your own testing, contracts and governance, which the platform has no visibility of. These are listed on the page itself with their reasons, rather than scored as though they had been checked.

That last row deserves emphasis because it is an obligation with a deadline attached. Nothing in Qorionix files your register. There is also no CSV or supervisor-format export button today: the routes out are the JSON list endpoint above and the DORA section of an evidence bundle, both of which are structured records you convert into whatever template your authority publishes. If your authority requires a specific spreadsheet, producing it is manual work.

Filling it in for the first time

1. 1

   List every third party you could not operate without for a week

   Cloud and hosting, payroll, email, your core banking or practice system, your managed IT provider, and anything holding customer records. Start there rather than trying to be exhaustive — an accurate short register beats a long one full of unknown.

2. 2

   Mark the critical or important ones honestly

   This flag drives the exit-plan and contract-clause expectations. Over-marking creates work you do not owe; under-marking is the finding an auditor is looking for.

3. 3

   Record what each one processes

   In plain words. Customer names, addresses and payment details is more useful in a filing than data.

4. 4

   Set the contract status from the contract, not from memory

   signed unless you have actually confirmed the Article 30 clauses are in it. Most pre-2025 contracts are signed, not dora_aligned, and saying so is the point of having the two values.

5. 5

   Set the exit plan status from what has happened, not what is written

   documented means reviewed and approved. tested means somebody exercised it. If the plan is a paragraph nobody has read since it was written, it is drafted.

6. 6

   Generate an evidence bundle once the register is populated

   The bundle carries the register and the concentration view under an integrity hash, which is what turns we keep a register into here is the register as it stood on this date. See The evidence bundle.

What to read next

1. How findings map to DORA and ISO 27001 — the other half of the DORA surface, where posture findings cite the articles they support.
2. The evidence bundle — how the register leaves the platform in a form an auditor can check.
3. Reporting an incident under NIS2 — the neighbouring regime, with a clock on it.