Establish the boundary of responsibility
The EU Digital Operational Resilience Act, commonly known as DORA, has applied since 17 January 2025. It establishes requirements across areas including ICT risk management, incident reporting, resilience testing and ICT third-party risk. Its application depends on the entity and relevant provisions, including proportionality and exemptions. A group with UK and EU operations should assess the legal position by entity rather than assume one regulatory perimeter covers everything.
Data governance does not replace the functions accountable for those requirements. Its contribution is to make the information used by ICT risk, operational resilience, procurement and management reliable, consistent and traceable. Begin by agreeing responsibilities with those teams and legal advisers. The useful question is not whether data governance owns DORA, but which critical decisions depend on data whose ownership, meaning or quality is currently uncertain.
Reconcile the operational picture
Different teams often maintain different representations of services, applications, suppliers and legal entities. Those representations may each serve a valid purpose while using incompatible identifiers or levels of detail. Map the relationships needed to understand which ICT services support critical or important functions, and retain the rationale for classifications. Do not collapse distinct concepts simply to produce a single spreadsheet.
Create controlled reference data for identifiers and agreed definitions for key attributes. Clarify how subcontracting relationships, contractual arrangements and internal service provision are represented. Record provenance so reviewers can distinguish contractual evidence from an operational assertion. Where authoritative sources disagree, establish a reconciliation process with an owner and decision deadline rather than allowing each reporting team to choose the version that suits its immediate task.
Treat the register of information as a controlled product
DORA requires financial entities to maintain a register of information concerning contractual arrangements for the use of ICT services provided by ICT third-party service providers. Applicable technical standards specify detailed requirements. The data governance team should help translate the relevant templates and instructions into maintainable definitions, validation rules and source mappings, working with the teams accountable for completeness and submission.
A register assembled just before a reporting deadline is difficult to keep reliable. Design updates around supplier onboarding, contract changes, renewals and exits. Validate relationships as well as fields: a populated identifier is not useful if it points to the wrong entity or arrangement. Keep evidence of checks, exceptions and approvals so that a submitted version can be explained later without reconstructing decisions from email.
- Define the authoritative source and accountable owner for each material register attribute.
- Reconcile the register with procurement, contract and service inventories using documented scope rules.
- Track missing or inconsistent relationships separately from simple formatting failures.
- Version submitted extracts and preserve the transformation logic and approval record.
Support incident assessment and credible testing
Incident classification and reporting depend on timely, reliable information. Data governance can help standardise service identifiers, impact measures and definitions used across operational teams. However, ownership of classification, escalation and regulatory notification should remain explicit within the incident framework. Do not introduce a stewardship approval step that delays urgent response or obstructs established reporting obligations.
Resilience exercises should test whether essential information remains available and intelligible during disruption. Consider whether responders can identify affected services and responsible suppliers when a primary inventory is unavailable. Test access to approved alternative records and subsequent reconciliation. Synthetic or minimised test data may be appropriate, but the exercise must still challenge realistic dependencies; a perfectly curated demonstration dataset can conceal weaknesses in everyday operational records.
Make evidence sustainable and proportionate
Build controls into existing workflows rather than creating a separate DORA data bureaucracy. Procurement can capture required contractual attributes at the point of negotiation, architecture teams can maintain service relationships during change, and data stewards can resolve definition conflicts. Assign exceptions to the function able to correct the source. A central governance team should not become the permanent manual repair service for every incomplete record.
Report a small number of meaningful indicators: unresolved ownership gaps, unreconciled contractual arrangements and material relationship changes awaiting review. Explain coverage and uncertainty rather than presenting a completeness percentage as proof of compliance. CrestQA approaches DORA as a shared evidence challenge with clear functional accountability. Reliable data supports operational resilience, but neither a populated register nor a catalogue replaces the broader legal, technical and management obligations that the regulation establishes.