DORA's Register of Information: Mapping the Outsourced Services Behind Reinsurance Operations

DORA's register of information requires reinsurers to identify, classify, and document every ICT third-party service that supports a critical or important function. A complete register is the foundation of operational resilience. An incomplete one is the evidence a supervisor will use to question whether the firm understands its own technology dependencies.

Why does DORA's register of information represent a new compliance discipline for reinsurers?

DORA's register of information represents a new compliance discipline because it demands a structured, granular, and continuously maintained inventory of outsourced ICT services that most reinsurers have never compiled. The data resides in procurement files, departmental budgets, and IT asset inventories that were never designed to talk to each other.

The Digital Operational Resilience Act applies to all financial entities operating in the EU, including reinsurers, and the register of information is its most operationally demanding requirement. Every ICT service provided by a third party that supports a critical or important function must be recorded with its contract reference, service description, provider identity, sub-contractor chain, renewal date, and criticality classification. The register must be submitted to the competent authority on request and must be current at all times.

For reinsurers, this reaches into every operational function. Treaty administration platforms, actuarial modeling software, bordereaux processing services, data-hosting infrastructure, cybersecurity monitoring, and even the communication tools used to manage broker and cedent relationships may qualify. The scope is broad, the data is scattered, and the consequence of an incomplete register is a supervisory finding that questions the firm's operational resilience at its foundation.

What goes wrong when firms attempt to build the register from existing procurement and IT records?

Five failures emerge: services that fall outside centralized procurement visibility, contracts that lack structured data, bundled services that obscure sub-contractor dependencies, stale records that do not reflect current arrangements, and inconsistent criticality classifications that undermine the register's risk-assessment value.

The register demands a level of completeness and consistency that general procurement records rarely provide. The IT department knows some services; procurement knows others; business-unit leads commissioned others directly. Bringing these three views together into a single, consistent register is a data-integration exercise disguised as a compliance filing.

1. Why do ICT services fall outside centralized procurement visibility?

ICT services fall outside centralized visibility because business units increasingly procure software-as-a-service tools directly, expensed rather than contracted, without IT or procurement involvement. Actuarial teams subscribe to modeling platforms; finance teams use cloud-based reporting tools; underwriting teams license data-enrichment services.

These services support critical functions but exist nowhere in the firm's formal ICT inventory. The DORA register compilation process begins with a census of the organization's actual technology usage, not a review of procurement contracts. The census often reveals twice as many services as the procurement records suggest.

2. How do unstructured contracts frustrate register compilation?

Unstructured contracts frustrate register compilation because the data points DORA requires, service description, sub-contractor identity, data-location details, termination rights, and service-level parameters, are buried in prose documents rather than captured as structured fields. Extracting them is a manual document-review exercise that must be repeated for every service and every contract.

A contract may specify the primary provider but not mention the sub-contractor that hosts the data. It may describe the service in commercial terms but not in the technical terms the register requires. The contract analysis needed to populate the register is substantial, and without automation, it is the bottleneck that determines whether the register is ready for the supervisor's deadline.

3. What does bundling hide in the ICT supply chain?

Bundling hides sub-contractor dependencies because a single managed-service contract may encompass cloud hosting, application support, security monitoring, and data backup, each provided by a different sub-contractor. The primary contract names only the managed-service provider; the sub-contractors are invisible.

The DORA register requires transparency into the ICT supply chain, including sub-contractors that support critical functions. A firm that lists only the primary provider is under-reporting its dependencies, and the supervisor, when it compares the register against known industry dependencies, will identify the gaps.

4. How do stale records undermine the register's reliability?

Stale records undermine reliability because services change, providers are replaced, contracts expire and renew on different terms, but the register still reflects the arrangement that existed when it was first compiled. A register that is accurate on the filing date but not maintained becomes inaccurate within months, and the supervisor expects currency, not a one-time snapshot.

Maintenance is the harder problem than compilation. The register must be updated as services are added, changed, or terminated, and the update process must be integrated into the firm's procurement, IT change-management, and contract-governance workflows. Without that integration, the register decays and the compliance gap reopens.

5. Why does inconsistent criticality classification weaken the register?

Inconsistent criticality classification weakens the register because services are classified by different people using different interpretations of "critical or important." One analyst classifies the bordereaux platform as critical; another classifies the actuarial modeling platform as non-critical. The register then understates or overstates the firm's dependency on specific services.

DORA provides criteria for criticality assessment, but the criteria require judgment. A centralized classification framework, with definitions, examples, and a governance process that reviews and approves classifications, converts judgment into consistency. Without it, the register is a collection of individual opinions rather than an organizational risk assessment.

Build a DORA-ready register of information with Insurnest's compliance technology

Talk to Our Specialists

Visit Insurnest to learn how we help reinsurers and carriers discover, classify, and maintain a complete ICT service inventory that satisfies DORA and supports operational resilience.

What do CFOs actually expect from a DORA register of information?

CFOs expect a complete inventory of every ICT service the firm depends on, a clear classification of which are critical and why, visibility into the sub-contractor chain behind each provider, identified concentration risks, and a register maintenance process that is integrated into procurement and IT governance so it stays current without a separate compliance project.

Michael is the CFO of a reinsurance group operating across five European jurisdictions, writing life, non-life, and specialty treaties. He oversees the operational resilience budget, the ICT procurement governance, and the regulatory compliance function. When DORA's register requirement was published, he recognized it immediately as an exercise his organization was not organized to complete.

His finance systems run on a cloud platform procured by IT. His actuarial models run on a separate provider commissioned by the chief actuary. His bordereaux processing is outsourced to a third-party administrator, which uses its own technology stack, which in turn sub-contracts data hosting. His treaty management system was acquired before his tenure, and the contract is in a procurement archive nobody has opened in three years. The register asks him to document all of these in a structured file and keep it current, and today he cannot do it.

He sees the register not only as a compliance obligation but as a risk-management asset. A complete inventory reveals concentration to a single cloud provider, single sub-contractor dependencies that span multiple business functions, and services that lack viable exit strategies. His asks below reflect both the compliance requirement and the business case.

• A comprehensive ICT service census across every function. "I need to know every service the firm uses, regardless of how it was procured. The register must include IT, actuarial, finance, underwriting, claims, and operations services, and the census must reach departmental tools." The census is the register's foundation.
• Structured service records with all DORA-required data fields. "Every service entry must capture the provider name, contract reference, service description, criticality classification, sub-contractor chain, data location, renewal date, and termination rights. Free-text descriptions are not enough." Structured data enables analysis and reporting.
• Sub-contractor visibility across the ICT supply chain. "If a critical service depends on a sub-contractor, that sub-contractor must be in the register with its own entry, linked to the primary provider. I cannot manage concentration risk I cannot see." Supply-chain transparency is a supervisory expectation.
• A governed criticality-classification framework. "Every service must be classified as critical or non-critical using defined criteria, applied consistently, and approved by a designated owner. I will not accept classifications made by individual analysts without review." Consistency supports both compliance and resource allocation.
• Concentration-risk reporting from the register data. "The register must show me which provider supports how many critical services, and where a single sub-contractor appears behind multiple providers. Concentration risk is the operational equivalent of counterparty credit risk." The register must double as a risk-management tool.
• Integration with procurement and IT change management. "When a new service is procured or an existing service is changed, the register must be updated as part of the procurement workflow, not as a separate project. If the register requires a separate update process, it will be out of date." Integration drives currency.
• Annual review with evidence of sign-off. "Every service entry must be reviewed annually by the service owner for accuracy and completeness. The review must produce an audit trail showing who reviewed what and when." Annual attestation supports the audit preparation obligation.
• Exit-strategy documentation for critical services. "Every critical service must have a documented exit strategy that describes how the firm would migrate or replace the service if the provider failed. The exit strategy must be attached to the register entry." The register is incomplete without exit planning.
• Data-location tracking for every service. "I need to know where the data for each service resides, both primary and backup locations, because data sovereignty and cross-border transfer rules apply differently across jurisdictions." Location data supports multiple compliance regimes.
• Regulator-ready extraction and submission. "When the supervisor requests the register, the system must produce it in the required format within the required timeframe. I cannot have a team assemble it manually every time the supervisor asks." Submission readiness is the final compliance test.
• Business-continuity linkage from register entries. "The critical services in the register must be referenced in the business-continuity plan and the incident-response plan. If a service fails, the response starts from the register." The register feeds the resilience framework.

Michael's business case extends beyond compliance. The register is his firm's first complete ICT service inventory, and it supports procurement consolidation, vendor negotiation, resilience planning, and technology-strategy decisions. The compliance investment produces an asset the business uses every day.

How can reinsurers build and maintain a DORA-compliant register of information?

Reinsurers build a DORA-compliant register by conducting a firm-wide ICT service census, structuring every service record with the required data fields, mapping sub-contractor chains, applying a governed criticality-classification framework, integrating the register into procurement and IT change workflows, and maintaining it with annual reviews tied to service-owner attestations.

The register is a living document, not a filing. Building it requires data collection, classification, and governance. Maintaining it requires integration with the processes that add, change, and remove ICT services. The six capabilities below describe the infrastructure that makes the register both complete and current.

1. How does an ICT service census produce a complete inventory?

An ICT service census produces a complete inventory by surveying every department for every technology service it uses, cross-referencing survey results against IT asset records and procurement contracts, and reconciling the three sources into a single, de-duplicated service list. The census reaches departmental SaaS tools, embedded services, and trial subscriptions.

This is the foundational data-collection step. It must be thorough enough to satisfy the supervisor that the firm has looked everywhere ICT services might exist, and it must be documented enough to show the method. The census process is the evidence that the register is complete, and completeness is the supervisor's first test.

2. Why does structuring service records matter for register usability?

Structuring service records matters because the register must be queryable, reportable, and submittable. Free-text service descriptions prevent aggregation, mask concentration risk, and fail the supervisor's format requirements. Structured fields enable every downstream use of the register data.

Each service record should capture provider identity, contract reference, service category, criticality classification, data residency, sub-contractor identifiers, renewal date, termination notice period, and the service owner. The structured data approach converts the register from a document into a database, and the database supports concentration-risk analysis, exit-strategy planning, and regulatory submission simultaneously.

3. What does sub-contractor mapping reveal about concentration risk?

Sub-contractor mapping reveals that multiple critical services share dependencies the firm did not know existed. A single cloud sub-contractor may support the treaty administration platform, the actuarial modeling environment, and the data warehouse, creating a concentration that is invisible at the primary-provider level.

Mapping the ICT supply chain requires asking every provider to identify its material sub-contractors, recording those sub-contractors as separate register entries linked to the primary service, and analyzing the resulting dependency graph. The analysis often reveals concentration risk that changes the firm's resilience planning and its procurement strategy.

4. How does a governed classification framework ensure consistency?

A governed classification framework ensures consistency by defining critical and important in operational terms specific to reinsurance, providing classification examples, requiring classification to be proposed by the service owner and approved by a designated governance body, and re-assessing classification when the service or its usage changes.

The framework is applied uniformly across the organization. The bordereaux platform is classified by the same criteria as the actuarial modeling platform. The result is a register where criticality means the same thing everywhere, and the firm can demonstrate to the supervisor that its classification decisions are systematic.

5. What does integration with procurement and IT change workflows deliver?

Integration with procurement and IT change workflows delivers a register that stays current without a separate maintenance project. When a new ICT service is procured, the procurement workflow triggers a register-entry creation step. When an existing service is changed or terminated, the change-management workflow updates the register.

This is the answer to the maintenance problem. A register that requires a separate update process will be out of date. A register that is updated as a by-product of the processes that add, change, and remove services will be current. The workflow integration converts maintenance from a project into a control.

6. How does annual review with service-owner attestation sustain accuracy?

Annual review with service-owner attestation sustains accuracy by requiring every service owner to confirm that the register entry for their service is complete and correct, to update any changed data fields, and to sign the attestation, which is preserved as evidence for the supervisor and the external auditor.

The annual review cycle catches the entries that change-management workflows miss, services that were procured outside the approved process, trial subscriptions that became permanent, and contact details that have changed. It also provides the evidence that the firm's governance of the register is active, not passive.

Deliver a complete, current, and compliant DORA register with Insurnest's compliance technology

Talk to Our Specialists

Visit Insurnest to see how we help reinsurers, carriers, and groups build governed ICT service inventories with concentration-risk analysis and regulator-ready submission.

What does an ideal DORA register of information look like in practice?

An ideal DORA register is a structured, queryable inventory of every ICT third-party service, complete with sub-contractor chains, governed criticality classifications, exit-strategy documentation, and an integrated maintenance process. The register is submitted to the supervisor on request, and the submission is accompanied by concentration-risk analysis that demonstrates the firm understands its own dependencies.

Returning to Michael's group, the ideal register is built over six months. Month one is the census: every business unit and department is surveyed, the survey results are reconciled with IT and procurement records, and the initial service list is validated. Month two is structuring: every service record is populated with the required data fields, provider information is verified, and contracts are reviewed for sub-contractor and data-location details. Month three is classification: every service is assessed against the criticality framework and the classifications are reviewed and approved by the governance body.

Month four is concentration-risk analysis: the register reveals that three of the five most critical services share a single cloud sub-contractor, and that two services lack documented exit strategies. The risk committee reviews the analysis and commissions exit-strategy development and procurement diversification planning. Month five is integration: the register is linked to the procurement workflow, the IT change-management process, and the business-continuity plan. Month six is the first annual review cycle, where every service owner attests to their entries and the register emerges as a governed, living asset.

When the supervisor requests the register, Michael's team produces a complete file with concentration-risk analysis, classification rationale, and annual-review evidence, all within the required timeframe. The supervisor's review raises no findings on ICT third-party risk management. The register's value to the business extends beyond compliance, supporting vendor consolidation that reduces ICT costs and resilience planning that protects critical operations.

Turn DORA compliance into operational resilience with Insurnest's ICT service-mapping technology

Talk to Our Specialists

Visit Insurnest to learn how we help reinsurance organizations build, maintain, and leverage a complete ICT service inventory for DORA compliance and operational resilience.

Conclusion

For reinsurers operating in the EU, DORA's register of information is the most operationally demanding regulatory filing they will build this decade. The scope is broad, the data is scattered, and the maintenance obligation is continuous. A firm that approaches the register as a one-time data-collection exercise will have an incomplete file on the day the supervisor asks for it.

A firm that approaches the register as a governed ICT service inventory, built from a thorough census, structured for analysis, classified consistently, and maintained through integration with procurement and change workflows, will have a complete and current file and an asset that supports vendor management, resilience planning, and technology strategy.

For CFOs, chief risk officers, and compliance leads, the practical sequence is clear. Census first; structure second; classify third; analyze fourth; integrate fifth; review annually. The supervisor will ask for the register. The firm's response should be a file that demonstrates control over its ICT dependencies, not a project to create one.

Frequently asked questions

What is DORA's register of information?

It is a mandatory record of ICT third-party service arrangements supporting a financial entity's critical functions. Reinsurers must maintain it, keep it current, and submit it to the competent authority on request.

Which outsourced ICT services must be included in the DORA register?

Every ICT service provided by a third party that supports a critical or important function, including cloud infrastructure, data hosting, software-as-a-service platforms, actuarial modeling tools, bordereaux processing systems, and cybersecurity monitoring services.

How does DORA define a critical or important function in reinsurance?

A function whose disruption would materially impair the firm's financial performance, solvency position, or policyholder obligations. In reinsurance, this includes treaty administration, claims handling, exposure modeling, and regulatory reporting systems.

What makes the register of information difficult to compile and maintain?

ICT services often enter the organization through departmental procurement rather than central IT, contracts lack standardized data, services are bundled, and sub-contractors are not consistently identified. Mapping the full chain is a data-collection challenge.

How does the register of information relate to concentration risk?

The register reveals how many critical services depend on a single provider or small group. Concentration risk invisible when contracts sat in departmental folders becomes visible when mapped in one register.

What happens when a reinsurer cannot produce a complete DORA register?

The supervisor may impose conditions, require remediation, or levy penalties. More importantly, the firm cannot assess its own ICT concentration risk, leaving it exposed to a systemic provider failure.

How often must the DORA register be updated?

The register must be updated continuously as services are added, changed, or terminated. Annual review is the minimum, but material changes such as a new provider or contract restructure must be reflected promptly.

Can the DORA register be used for purposes beyond regulatory compliance?

Yes. A complete ICT service inventory supports procurement consolidation, vendor-risk management, business-continuity planning, and exit-strategy development. The regulatory obligation creates an asset the business can use.

About the author

Hitul Mistry is the Founder of Insurnest, an InsurTech company that engineers end-to-end technology exclusively for the insurance industry serving carriers, TPAs, MGAs, brokers, and reinsurers across India, the UAE, and the US. With more than a decade of insurance domain experience, he has built systems spanning underwriting automation, AI-powered underwriting intelligence, claims management, rating and quoting, broking and agency platforms, and reinsurance automation across Health/GMC, Group Life, Motor, P&C, and Reinsurance. Insurnest doesn't adapt generic software to insurance; it builds from the workflow up.

Connect with Hitul on LinkedIn.