Does a technically accepted upload mean the register is correct?

No. Technical processing and substantive data quality are separate checks. Plausibility, completeness and relationships need additional review.

What should I check when a supplier changes?

Which contractual relationship ends or begins, which services and functions are affected, and which identifiers and relationships change. The specific reporting dataset must follow the applicable requirements.

DORA register of information: How do you check data quality?

A DORA register of information can be technically processable yet contain incorrect relationships. A provider appears twice, a contract reference leads nowhere or a placeholder replaces the actual ultimate parent. Data quality therefore needs its own review before submission.

The Central Bank of Ireland describes additional substantive checks of register data by the EBA for 2026. Examples include unusable identifiers and generic provider names. The Irish submission deadlines described there are not deadlines for German organisations. Central Bank of Ireland

Our DORA register of information guide covers the fundamentals and structure. This article focuses on reviewing and correcting an existing dataset.

Review in three separate passes

Start with the schema applicable to your submission and the competent authority’s current instructions. Freeze the dataset under review so corrections and results can be attributed to it.

Review	Main question	Typical error
Technical	Does the file meet the required format?	Incorrect structure or invalid data type
Relationships	Are references between tables correct?	Contract points to an unknown provider
Business accuracy	Do entries describe the actual service?	Former legal entity or wrong function assigned

This working aid does not replace an official validation catalogue. It helps prevent a successful upload being mistaken for substantive approval.

Reconcile the register with source documents

A supplier list is an input, not automatically the complete register. Compare it with contracts, service descriptions and internally owned functions. Establish where one company appears under several spellings and where similarly named companies are actually different legal entities.

Identifiers should have a traceable source. If uncertain, do not simply enter “unknown” into a field requiring a defined value. Obtain the information or handle the unresolved point according to the applicable rules.

Our third-party risk management guide helps identify the business owner behind an entry. A procurement contact can provide contract data; someone else often needs to assess the service’s significance to a business process.

Trace an entry through every relationship

For each critical case, select a complete chain: contractual arrangement, direct provider, service, using entity and supported function. Check further required details against the applicable register requirements.

This is not about inventing your own hierarchy. You are checking whether references in the prescribed data model make sense together. A valid identifier can still point to the wrong record.

Example: The contracting party changes

Fictional case: A financial services company changes its hosting contracting partner. The technical environment initially stays the same. Only the company name is overwritten in the register; contract references and assigned services are left unchecked.

Instead, the team records the change traceably: which agreement ended? Which began? Which legal entity provides which service? Which functions are affected? It then checks every affected register entry against those records.

The decision history is retained. Whether and how terminated arrangements must appear in the specific reporting dataset is established against current requirements. Simply deleting old rows is insufficient.

Track errors through to business acceptance

A useful error record includes the record reference, affected field, finding, source, owner and correction status. Separate “changed” from “checked”. After a correction, dependent tables may need revalidation too.

Recurring errors require changes to data collection. If new contracts routinely arrive without a clear mapping, another spreadsheet cleanup will not solve the underlying problem. Embed required information in the procurement and change process.

Reusable error log

Record / field	Rule source and version	Finding	Owner	Correction	Recheck result
Enter reference	Link applicable requirement	Describe the error specifically	Name a person	Document the change	Checked, open or requires further work

For contract changes, also consider DORA third-party risks. Data checks and risk assessments complement one another; neither replaces the other.

What Kopexa can contribute

In Kopexa, you can bring together responsibilities, measures and their evidence. This supports traceable work on unresolved checks and supporting records. The suitability of a specific register export for your authority and schema version must be assessed separately; it does not imply automatic regulatory acceptance.

Use a sanitised contract change as a test and check whether everyone involved can contribute. A good dataset stays good only if operational changes reach it.

Our guide to current ISMS evidence explains how to assess supporting records. A clear management review brief helps with decisions about remaining gaps.