Fill the DORA register — the register of information

If you’re a regulated financial entity, DORA requires a Register of Information about your ICT third-party providers and the contracts behind them — 15 fixed tables. Regixo drafts the two tables it can trace from your data map and marks the rest — contract and vendor facts a scanner can’t know — as yours to supply. This page walks you through the whole register table by table, decision by decision, so you finish with a register your engineer can seal and file.

Land here from: Fill the RoPA (the GDPR record’s legal calls are done). DORA applies only to regulated financial entities; if that is not you, skip to Unlock, sign & maintain.

Walk one provider all the way through (the worked example)

Before the reference, take one provider end to end so the loop is concrete. Regixo traced a Stripe integration from your data map and seeded it as a candidate in table B_05.01. Here is Stripe through every step:

Every provider and every contract is that same loop. The reference below is what you use inside steps 3, 4 and 5 to make each call with confidence.

Step 1 · Confirm DORA scope is on

The register only exists when your configuration declares you a financial entity. Declare it when you scan (or turn it on later):

$ regixo start --dora

This sets dora: true in regixo.yml and drafts the register alongside the RoPA. It is the engineer’s one-time setup — you don’t run it. To check it’s on, the register is present on the portal’s DORA tab and regixo dora status (next step) returns the 15 tables. Re-draft any time with regixo report --dora, which writes the register beside your other records as DORA_DRAFT.json and the readable DORA_DRAFT.html.

Step 2 · See which tables auto-filled and which need you

Read the register once before you fill anything. From the terminal, regixo dora status is the whole picture — what’s filled, what still needs you, and which scope rulings are open:

$ regixo dora status

DORA register — 15 tables (Reg. (EU) 2024/2956):
  0 complete · 2 partly auto-filled · 13 need you entirely
  entries: 10 filled in for you + 0 you added · 75 still need you
  columns: all 100 principal regulation columns are modelled.
Tables still needing input (15):
  B_01.01  Entity maintaining the register of information  [needs-you]
  …
  B_05.01  ICT third-party service providers  [partial]
  …
  B_07.01  Assessment of the ICT services  [partial]
  B_99.01  Definitions from entities making use of the ICT services  [needs-you]
Scope rulings open (2): is each B_05.01 provider in DORA scope? — snowflake-dwh, stripe.
Fill them:  regixo dora import <tableCode> <file.csv>   ·   regixo dora set <tableCode> <rowKey> <field> <value>
Export (paid):  regixo dora export   →  validates the register against Reg. (EU) 2024/2956 and writes the xBRL-CSV files. The EBA submission package is not available yet.

Out of the box, exactly two tables are partly auto from your map — B_05.01 (candidate ICT providers) and B_07.01 (the same services, to assess). The other thirteen are needs you: they hold contract, entity, function and definition facts a scanner cannot see. This is honest — the map fills about two of fifteen tables, never “DORA done”.

The 15 tables, in four plain-English groups

The register groups into four parts — A · Your company, B · Your contracts, C · Your IT suppliers, D · Your functions — the same grouping the portal’s DORA page uses. Here is every table, its exact name, and who fills it:

B_99.01 is not auto-filled. It holds your firm’s definitions behind the closed-set answers — never regulation paraphrases filed as your content — so it starts needs you like the rest of the human tables.

The engineer sees this same register on the free portal before it is ever forwarded. It ends on a Two ways forward annex — your compliance team fills the gaps in the handed-over record, or the engineer imports what the company already holds with regixo dora import. Signed out, reading needs no account: a cell you would fill reads sign in to fill, a call only an approver may make reads sign in to rule, and an empty table reads No rows yet — sign in to add.

Step 3 · Rule each provider in or out of scope — the decision walk

Whether a provider is an “ICT third-party service provider” under DORA (Art. 3(21)) is a legal judgment, so the B_05.01 rows Regixo seeds from your map begin as candidates. You rule on each one. Ask these questions in order:

Rule each row from the terminal (in the portal, the approver presses confirm or exclude on the row):

$ regixo dora set B_05.01 <rowKey> inScope confirmed
$ regixo dora set B_05.01 <rowKey> inScope excluded --because "a database we host on our own servers, not a third-party ICT service"

Set B_05.01 · stripe · inScope = "confirmed".  See: regixo dora status
Set B_05.01 · snowflake-dwh · inScope = "confirmed" (a managed warehouse is a third-party service).  See: regixo dora status

The DORA input could not be applied. (excluding a provider from DORA scope needs a recorded
ground — the ruling stays on record even though the row is not filed (ESAs FAQ Q69). Re-run with:
regixo dora set B_05.01 <rowKey> inScope excluded --because "<one line: why it is not in DORA scope>")
  (reference code: DORA_INPUT_INVALID)

A candidate you haven’t ruled on is flagged in regixo dora status (“Scope rulings open”) and again at export — you can still forward and seal with candidates open; they’re listed, never hidden. Excluded rows are left out of the filing.

Step 4 · Fill each table — inline or by CSV import

Three surfaces fill the register — pick whichever fits the row:

$ regixo dora import B_02.01 contracts.csv

Imported 2 rows into B_02.01 (row key = ref; the same key updates its row in place). See: regixo dora status

Here is the portal register surface itself — B_05.01 mid-fill. The cells Regixo filled carry quiet auto markers, and a cell a person filled says who — you for this machine, team for an answer your compliance team gave on the claim page, with the name and date in its tooltip. (Not sure what a mark means? The register carries a key — What do the marks mean? above the tables.) The details a scanner can’t see are inline add… boxes; the in/out-of-scope ruling is approver-only:

An upload never saves straight away — it lands on a preview so you can check each row before you commit it:

Where the answer is a fixed list

Many cells take only a value from a fixed list the regulation defines — the contract types, the S01–S19 service taxonomy, the Yes/No and Low/Medium/High scales. Enter the code or the exact label; Regixo stores the canonical form and rejects anything else, in a CSV or a single set. regixo dora options <tableCode> <field> lists a column’s allowed values:

B_07.01 · service — 19 allowed values. Enter the code or the exact label; Regixo stores the canonical form:
  S01                      ICT project management
  S02                      ICT development
  …
  S17                      Cloud services: IaaS
  S18                      Cloud services: PaaS
  S19                      Cloud services: SaaS

Which S-code? Pick the one that names the service you actually buy — a SaaS product (Stripe, Snowflake, a cloud app) is S19 Cloud services: SaaS; raw compute is S08; non-cloud hosting is S07. Regixo already guesses S19 for an unambiguous cloud SaaS and leaves the rest for you. A value outside the list is a named row error that points you back at regixo dora options.

Imported 0 rows into B_02.01 (row key = ref; the same key updates its row in place). See: regixo dora status
REJECTED 1 row — value outside a closed option set (fix the file and re-import):
  row 2  type="perpetual"  (options: standalone arrangement · overarching (master) contractual arrangement · subsequent or associated arrangement)
  List a column’s allowed values:  regixo dora options B_02.01 <field>

LEIs

An LEI (Legal Entity Identifier) is 18 alphanumeric characters plus 2 check digits (ISO 17442). When you enter one on the portal or import a CSV, Regixo checks the checksum (mod-97-10), so a plausible-looking but invalid code — including all-zeros — is rejected with a clear message. Look providers up on the GLEIF register if you don’t have theirs. A provider with no LEI isn’t a dead end: the register carries other identification-code types (EUID, CRN, VAT…) — set codeType to the scheme you have and put its value in identifier.

Contract tables take whole rows, not single cells

The contract tables key each row by a composite of columns (a B_02.02 row is keyed by contract · using-entity LEI · service type, one row per value). regixo dora set only fills a cell of an existing row there — rows are created by import (or the portal’s + Add a row), which derive the key. Try to set a cell on a table with no rows yet and Regixo tells you exactly how to add them:

The DORA input could not be applied. (B_02.02 has no rows yet — its rows are keyed
ref·userLei·serviceType and are added by import: regixo dora import B_02.02 <file.csv>)
  (reference code: DORA_INPUT_INVALID)

However you fill it: CSV headers match either the column ids or the human column labels (case-insensitive); the first cell of each row is the row key; unknown columns are surfaced back to you, never silently dropped; and re-importing the same key updates that row in place instead of duplicating it.

Step 5 · Rule each function’s criticality — the decision walk

DORA scopes the heaviest requirements to the ICT services that support a “critical or important function”. Identifying your business functions (B_06.01) and rating each one’s criticality is yours to do — a scanner can’t know it. Like the scope ruling, criticality is an approver judgment: in the portal a preparer sees the gap but only an approver fills it, and the downloadable CSV template omits the column. To decide whether a function is critical or important, ask:

• Would a disruption or failure of this function materially impair your financial performance, or the soundness/continuity of your services and activities?
• Would failing it breach the conditions of your authorisation or your obligations under financial law?
• Does it support a core banking, payment, trading, settlement or reporting activity?

Any clear “yes” points to critical or important. The field is a fixed set — record the reasons alongside it:

B_06.01 · criticality — 3 allowed values. Enter the code or the exact label; Regixo stores the canonical form:
  yes                      Yes
  no                       No
  not-performed            Assessment not performed

Rule it from the terminal (or, in the portal, the approver picks it on the row):

$ regixo dora set B_06.01 <functionId> criticality Yes

How complete the package is — honestly

The DRAFT register models the full principal column set of every template — regixo dora status reports “columns: all 100 principal regulation columns are modelled.” Every export still carries a structural coverage report, so you (and your authority) are never told the package is more complete than it is. Where the field precision goes beyond what Regixo models, the export lists exactly which columns it carries and which it doesn’t.

Who produces the filing — you or the engineer

The claim you review is read-only for the sealed output. You fill and confirm the register on it, but the checked, sealed xBRL-CSV package is never built on the forwarded claim. It is produced on the engineer’s own Regixo — the machine that holds the source data and the licence key. The split is deliberate, the same as signing the RoPA, and it makes the roles clear:

• You (compliance) fill the contract, entity and scope facts on the claim, rule each provider in or out of DORA scope, rule each function’s criticality, and confirm the register is complete and correct.
• The engineer pulls your claim-side answers back into the local register (regixo pull), sets the licence key, and runs the export (regixo dora export) on their host — the only place the seal is produced.
• You get the finished file back — the engineer sends you the built package, or commits it where your team keeps its evidence. You submit it through your authority’s own channel; Regixo assembles and seals, it never files for you.

Both regixo dora export and the licence activation are person-run on the engineer’s machine — there is no “export” button on the forwarded claim, by design. The licence key reaches the engineer from your unlock receipt — see Unlock, sign & maintain.

The submission package

When the register is filled and signed, regixo dora export builds the EBA report package: a META-INF/ manifest, a reports/ folder with the report descriptor, a parameters.csv and a FilingIndicators.csv, one DPM-coded CSV per template (needs-you cells written empty), and a README that states the filing boundary — plus the seal. It lands beside your other artifacts as DORA_OFFICIAL.xbrl-csv.zip.

The four filing parameters

A package has to say which filing it is. Those four facts are declarations about your firm, so Regixo never guesses them — they go in regixo.yml, where the dora key takes an object instead of true. Using the object form still means scope on: only a filer sets filing parameters.

dora:
  refPeriod: "2025-12-31"   # the reporting reference date (ISO YYYY-MM-DD)
  baseCurrency: EUR         # ISO 4217
  nca: fi-fiva              # your authority's id in Regixo's NCA matrix (optional)
  consolidated: true        # filing at group level — the default is individual

Nothing here is ever prompted for. refPeriod and baseCurrency are required: either one missing at export time surfaces as EBA_FILING_PARAM_MISSING, naming the exact key to add, so an agent can fix it without a human in the loop. nca is optional. consolidated is what marks the package CON rather than IND — it is declared, never inferred from the register.

What the regulator accepts

DORA filings are made as a structured xBRL-CSV package — the machine-readable form the European Supervisory Authorities and your national authority ingest, not a PDF or a spreadsheet. What makes a package acceptable is that it validates: the EBA dry-run runs 116 checks over the register — LEIs that resolve and pass their checksum, contract types and the S01–S19 service taxonomy drawn from the fixed code lists, every cross-reference between tables resolving, and mandatory cells present. Regixo’s job is to hand over a validated pre-submission package that clears those checks before it reaches the regulator; the authority runs its own validation again at submission time.

Why draft from your real systems at all: in the European Supervisory Authorities’ DORA dry-run exercise, only about 6.5% of manually-built registers passed all 116 validation checks.

Step 6 · How you know the register is finished

Run the loop until all of these are true, then hand it back to the engineer:

• No scope rulings are open — every B_05.01 candidate is confirmed or excluded (with a ground). regixo dora status no longer lists any under “Scope rulings open”.
• Every function’s criticality is ruled — no critical-or-important call left unanswered on B_06.01.
• The tables that apply to your firm are filled — contracts imported, LEIs entered and valid, entities and functions in. Anything you genuinely don’t hold is left as a flagged gap, not a guess.

You don’t have to fill DORA before forwarding — you can forward the record now with regixo invite and your compliance team finishes the register on the portal. When it’s done, the engineer pulls your answers home (regixo pull) and produces the sealed file. The register stays DRAFT until it is sealed — which is the next step.