The data core: How can one inventory serve DORA, NISG, SREP and the AI Act?

Editorially reviewed: 22 October 2026 · Legal status checked up to: 22 October 2026. Time-bound statements are dated; legal acts that are announced but not yet published are marked as such.

For whom: Banks (SI) Banks (LSI) Insurers Reporting service providers The data core architecture applies to banks and insurers alike; the legal references to SREP and RDARR concern banks.

The core thesis in one sentence: a complete, current and responsibly assigned inventory of holdings – ICT assets, data attributes, critical functions, provider contracts and AI use cases, linked by unique identifiers – feeds the ICT asset inventory under Art. 8 DORA, the register of information under Art. 28(3) DORA, the perimeter question of NISG 2026, the data capability assessed in the SREP from 2027 and the data requirements of Art. 10 AI Act. It does not fulfil these obligations – the respective views, data fields, quality controls and above all the statutory classifications remain separate – but it prevents the same collection from happening four times. In short: shared inventory, separate regulatory classifications.

What common finding do supervisors see?

From its on-site campaign 2022 to 2024, the 2024 targeted review and the annual management report, the ECB has distilled three clusters of deficiencies: incomplete data governance, unfit data infrastructure and IT architecture, inadequate data accuracy and integrity. Two detailed findings are decisive for this page: the data governance framework does not cover certain material risks, and the criteria for determining material legal entities are vague; in the IT risk survey, IT data quality management proved to be the least mature domain. Neither finding is confined to risk reporting – an institution that cannot delineate its scope cleanly has the same problem with critical functions under DORA, with the NIS2 perimeter and with the classification of its AI use cases.

Supervisors have meanwhile made the connection themselves. EBA/GL/2026/06 brings DORA matters and risk data aggregation together in one SREP section from 1 January 2027, and the ECB supervisory priorities 2026–2028 list risk data aggregation, ICT resilience and AI governance together under priority 2.

DORA: Why is the register of information a data quality test?

In practice the register of information is treated as an outsourcing topic. Professionally it is something else: a structured, machine-validated submission on contractual relationships, provider chains, criticality and substitutability – with mandatory fields, foreign-key relationships and identifier checks. The only quantified evaluation stems from the ESAs' 2024 dry run with 1,039 financial entities from 27 Member States and 947 evaluated registers:

The last point is the most telling: financial entities report their own identifier incorrectly more often than their providers'. That has nothing to do with ICT risk – it is a master data problem, the same defect the ECB criticises in the RDARR context as missing unique data identification. From the Austrian supervisory dialogue of October 2025 the FMA reported rejections because of a blank after the LEI and copying errors from the Excel format: not conceptual shortcomings but symptoms of missing automated controls at the data source. And the register is the direct data input for designating critical ICT third-party providers – on 18 November 2025 the ESAs designated 19 providers.

Where do DORA and RDARR/BCBS 239 overlap?

In four requirements: asset inventory, dependencies, criticality and scope, and data integrity, just with different vocabulary.

NISG 2026: Why does the examination task lie in the group?

For the regulated institution itself, the DORA provisions take precedence under section 24(7) NISG 2026: according to the FMA, governance (section 31), risk management measures (section 32), evidence (section 33), reporting duties (section 34) and supervisory and enforcement measures do not apply to financial entities; registration under section 29(2) remains – via the business service portal, by 31 December 2026 according to the Federal Office for Cybersecurity, each entity separately. In every case the precondition is that the undertaking is an essential or important entity by activity and size at all; DORA alone makes nobody subject to registration. The real effort arises at group-owned data centres, IT companies and managed-service units that may fall independently into full scope via Annex I points 8 and 9 of the Directive – ICT third-party providers are not financial entities under Art. 2(2) DORA, so DORA does not act as lex specialis for them. Whether a group company is covered is decided by activity, thresholds with group attribution and exemptions – not by group membership as such; Austria, unlike Germany, has no exemption for purely intra-group service provision. This perimeter determination is the same exercise as delineating material legal entities in the RDARR guide. An institution with a maintained map of legal entities and service relationships answers the question in days; one without starts a survey it will repeat in two years.

AI Act: Why is Art. 10 the same build on a new site?

The Digital Omnibus (Regulation (EU) 2026/1744) postponed the high-risk deadline for Annex III systems to 2 December 2027 – with fixed calendar dates, without a trigger mechanism. It did not leave Art. 10 untouched: the legal basis for processing special categories of data to detect and correct bias was moved from Art. 10(5) into a new Art. 4a and extended to deployers, and Art. 4 on AI literacy was also recast (check the full text of the amending regulation before relying on it). The core of the data requirements remains: training, validation and test data sets must be relevant, sufficiently representative, as free of errors as possible and complete, with documented examination for bias (Art. 10(2) and (3)). Compared with RDARR data quality management, both norms describe the same discipline for different data holdings: defined quality dimensions, measurable criteria, documented examination, named responsibility, evidenced remediation. In its Supervision Newsletter of 20 November 2025 the ECB noted that only some banks consistently apply their own data management standards to AI models – particularly for unstructured data. That is exactly where the typical data quality framework ends: at the boundary of regulatory reporting.

Which six building blocks are built once?

Inventory, valuation set, data quality framework, lineage view, master data regime and findings register.

1. One shared inventory with shared keys. ICT assets, critical data elements, legal entities, provider contracts, business processes and AI use cases in one object model, linked by unique identifiers. The most expensive building block – and the only one without which none of the others holds.
2. One shared fact base for separate classifications. Criticality under DORA, materiality under RDARR, coverage under the NISG and the high-risk classification under Annex III answer different questions and follow their own statutory criteria – an outage can be business-critical without any AI system involved being high-risk. What should be shared is the fact base: the same functions, legal entities, systems and use cases with the same identifiers. What shows up in examinations are contradictory holdings data, not different legal classifications.
3. One data quality framework with extended scope. Dimensions, metrics with tolerance thresholds, documented escalation – applied to regulatory reporting, DORA register data and model data sets including unstructured sources.
4. One tool-supported view of provenance and dependencies. Derived from the processing chains, not documented manually; it serves the lineage requirement, the dependency maps under Art. 8 DORA and the provenance evidence under Art. 10 and 11 AI Act.
5. One master data regime. Mandatory maintenance of legal entity, contract and system identifiers with automated validation at source. The 2024 dry run showed that most reporting errors arise here – and remediation is comparatively cheap.
6. One shared findings and remediation register. One entry per defect with assignment to all affected rulebooks, cause, owner, deadline and evidence of remediation – the instrument for demonstrating to supervisors that a finding was fixed at the cause.

What must stay separate?

FRIA, penetration testing, NISG registration of group entities, conformity assessment with CE marking and the reporting cascades.

• The fundamental rights impact assessment under Art. 27 AI Act. Grounded in fundamental rights, not prudential; referring to a data protection impact assessment is permitted, equating it with a risk inventory is not.
• Threat-led penetration testing. Its own methodology, confidentiality regime and supervisory involvement.
• NISG registration of group companies. Different addressees, authority and deadlines – organisationally with the affected companies, with central steering of the perimeter question.
• Conformity assessment and CE marking for in-house development. A product safety procedure with no equivalent in banking supervision law.
• The reporting cascades. Different triggers, deadlines, classification logics and addressees: under DORA the initial notification runs from classification as major (four hours) and at the same time from awareness (24 hours), intermediate and final reports follow in stages; under the CRA the trigger is awareness of an actively exploited vulnerability or a severe incident, and for vulnerabilities the final report depends on the availability of a fix; the NISG has its own cascade for covered group companies. The deadline clock on the CRA page calculates CRA and DORA with their triggers. The data base should be shared, not the reporting channel.

Who is responsible for what?

Frequently asked questions

Does an asset inventory fulfil the four obligations at the same time?

No – it feeds them. The regulatory views, data fields and quality controls of the register of information, the SREP evidence, the NISG registration and the AI documentation remain necessary. The data core only prevents the same collection from happening four times.

Do banks have to register under NISG 2026 although DORA applies?

If they are an essential or important entity by activity and size: yes. According to the FMA, registration under section 29(2) NISG 2026 remains, while the substantive obligations – governance, risk management, evidence, reports – are displaced by DORA under section 24(7). Registration runs via the business service portal, by 31 December 2026 according to the Federal Office for Cybersecurity.

What does the register of information have to do with data quality?

It is a machine-validated submission with 116 data quality checks. In the 2024 dry run, 93.5 % of registers had at least one error, 86 % of errors were missing mandatory fields, and reporting entities stated their own LEI incorrectly more often than their providers'. That is master data maintenance, not ICT risk.

Which AI Act deadline matters for banks?

2 December 2027 for high-risk systems under Annex III – in banking, credit scoring of natural persons; for insurers, risk assessment and pricing in life and health insurance. The data quality requirements of Art. 10(2) and (3) apply from then; whoever extends the data quality framework to model data sets beforehand does not build twice.