DORA Register of Information

Under DORA, a financial entity keeps a register of information that records its ICT third-party arrangements in one structured place. The register names the providers it relies on, the ICT services those providers supply, the business functions those services support, and the contractual terms that govern each arrangement. It is kept at entity level, it is updated as arrangements change, and it is reported to the competent authority. The point is visibility. A supervisor reading a single firm's register should be able to trace dependencies that would otherwise stay hidden inside contracts, invoices, and team knowledge. For the entity itself, the same record becomes the starting point whenever a provider changes, a service fails, or a question arrives about who really delivers a critical process.

That last point explains why DORA treats the register as a living record rather than a filing exercise. A register assembled for a reporting date and then left alone will soon describe arrangements that no longer exist, because providers merge, services move, contracts renew on different terms, and internal teams quietly adopt new tools. This cluster explains what the register records, how each part is put together, how it stays current, and how supervisors use it, so the record remains a reliable map rather than a snapshot that ages badly.

Financial services now run on chains of providers. A payment, a trade, a claim, or a customer login may pass through cloud infrastructure, a software provider, a data feed, and a support desk, each supplied by a different firm. From inside one entity, each link can look manageable. From outside, the full chain is hard to see, and a weakness in one shared provider can affect many entities at once. The register is DORA's answer to that blind spot. By asking every in-scope entity to record its arrangements in a comparable way, DORA gives competent authorities a view across the sector, not just inside one firm.

At its core, the register links four kinds of fact. First, entity and branch information identifies the financial entity and any branches covered, so a reader knows exactly whose arrangements are described. Second, contractual information records the arrangement itself, including the provider, the agreement, and its key terms. Third, service and function information explains what the provider does and which business functions depend on it. Fourth, data and location information records what data is involved and where relevant activity takes place. Later guides take each part in turn, because each part fails in a different way and needs a different owner.

Drift is the central pitfall for this cluster, and it usually arrives quietly. A team signs a new arrangement and tells procurement but not the register owner. A provider replaces a subcontractor, or moves a service to a different location, and the change is noted in an email thread rather than in the register. A contract renews with a changed scope, and the old entry is left standing. None of these events looks like a failure on its own, yet together they mean the next report describes a past version of the firm. Supervisors then ask questions based on stale facts, incident response starts from the wrong map, and exit planning leans on terms that no longer apply.

Read this pillar first for the overall picture, then follow the supporting guides in the order the register is built. Start with what the register records, then entity and branch information, contractual arrangements, and ICT services and functions. Those four guides define the content. The guides that follow cover data and locations, reporting to authorities, format and templates, currency, quality, the link to third-party risk, group and branch questions, and supervisory use. Each guide stands on its own topic, so a reader with a specific problem, such as a messy group structure or a format dispute, can go straight to the relevant guide.

Throughout, the guides describe DORA arrangements in general educational terms. They do not give advice for a particular firm, and they do not promise that any particular register format will satisfy a competent authority in a specific case. Technical standards under DORA add detail on format and content, and those standards apply on their own stated dates, so a reader should always check the current standard alongside the Regulation. Used that way, the register becomes what DORA intends it to be: a current, checkable map of dependence, useful to the entity every day and to the supervisor when it matters most.