Skip to main content

Sample artefact · DORA Article 28

The Register of Information — what a working one looks like

DORA Article 28 requires every regulated entity to maintain a Register of Information — a complete map of ICT third-party providers in the format the National Competent Authority specifies. Below is what a working RoI built for a Bank-of-Lithuania-supervised EMI looks like, anonymised. Use it as a yardstick for your own.

The 14 fields, in plain language

The DORA Implementing Technical Standards (Article 28 RTS) prescribe 14 information categories. The ones most fintechs miss on first review are:

  • ICT third-party type — classified per the RTS taxonomy, not by the firm’s internal naming.
  • Critical or important function support — every contract mapped to one or more such functions, with evidence of the linkage.
  • Concentration risk view — aggregated across providers, not provider-by-provider.
  • Article 30 contractual clauses — status per provider, with remediation owner and date where missing.
  • Sub-outsourcing chain — named down to the level the regulator can audit.
  • Termination & exit conditions — with data-portability evidence.

What the RoI is not

A spreadsheet of vendors is not a Register of Information.Most firms walk into first review with a list of suppliers grouped by department, prices, and renewal dates. None of that satisfies Article 28. The RoI is a control artefact, not a procurement tracker.

Quick check — ask your compliance officer

Can you show me our Register of Information in the exact format our NCA expects, with all 14 fields populated, including ICT third-party provider type per Article 28 RTS?

If the answer is anything other than “yes” — you have a gap. The RoI is the single most common starting point of a regulator’s information request, because it tells the supervisor in five minutes whether ICT third-party risk is owned, classified, and documented.

How CyAdviso builds one

Two-week scope. Output: a complete Register of Information in your NCA’s required format, all 14 fields populated, all critical providers classified, DORA contract-clause status mapped per provider, concentration-risk view across critical or important functions, and an annual update protocol so it stays correct.

Across 8 EU fintech engagements (EMIs, PIs, CASPs supervised by Bank of Lithuania, Latvijas Banka, Central Bank of Cyprus and the UK FCA), every Register has been accepted on first review. None has triggered a repeat question on ICT third-party risk in post-engagement supervisory reviews over the last 24 months.

Want to see the anonymised sample?

The full anonymised RoI is shared on request — standard non-disclosure applies. Email info@cyadviso.com or book a 15-minute call to walk through it.

Book a 15-min call → Or take the 3-min Readiness Check


This page covers DORA Article 28 specifically. For the broader picture — gap analysis, ICT risk framework, incident response, board reporting — see the CyAdviso services overview.