A European financial organisation running artificial-intelligence systems in production falls under GDPR, NIS2, DORA and the AI Act at the same time. The four regimes ask for largely the same work — risk management, asset inventory, incident notification, supplier oversight — but with different definitions, thresholds and timings. Treating them as four separate projects duplicates the evidence and multiplies the points where the interpretations fall out of step. The problem is to build a single data model that serves all of them.

Context: four regimes that took effect in 14 months

The application dates clustered into a little over a year. The DORA Regulation (Digital Operational Resilience Act) has applied since 17 January 2025 to around twenty types of financial entity and to their ICT (Information and Communication Technology) providers. The AI Act made the prohibited-practice bans and AI-literacy obligations applicable from 2 February 2025, and the obligations for general-purpose AI (GPAI) models from 2 August 2025. In Italy the NIS2 directive was transposed by Legislative Decree 138/2024, in force from 16 October 2024; the registration window for essential and important entities on the National Cybersecurity Agency portal closed on 28 February 2025, and the classification notified by the ACN on 15 April 2025 acts as the reference point for the later deadlines. GDPR has been in force since 2018 and remains the baseline for personal-data processing.

For the company carrying all four obligations the calendar is not theoretical. Incident-notification obligations for registered Italian NIS2 entities start from January 2026, with full compliance to the security measures expected by October 2026.

Architecture: a control-requirement graph, not four lists

The natural temptation is to write a checklist per regime. That works as long as the regimes share nothing, and here they share a great deal. Risk management is the common core of ISO/IEC 27001, NIS2 and DORA, and GDPR asks for it as risk-based accountability. Third-party oversight — the supply chain — is central to NIS2 and DORA and turns up in Annex A of ISO/IEC 27001. Continuous monitoring is asked for by all of them.

A model that avoids duplication keeps two entities apart: the control (a technical or organisational measure actually in place: encryption at rest, network segmentation, a notification procedure) and the requirement (the regulatory clause that the control satisfies). The relationship is many-to-many. A single incident-notification procedure satisfies GDPR Article 33, NIS2 Article 23 and DORA’s ICT reporting obligations, each on its own clock. A single ICT-supplier register feeds both the DORA register of information — whose first submission to the European supervisory authorities was set for 30 April 2025 — and NIS2’s supply-chain security obligations.

ISO/IEC 27001 holds up well as the backbone of the model because it is a management system built on risk rather than on rules: its controls are granular enough to act as the nodes the individual regimes’ requirements hang off. Three ISO/IEC 27002:2022 controls keep coming back as the spine of the evidence — 5.1 (security policies), 5.19 (supplier relationships), 5.24 (incident management planning and preparation) — plus 6.8 (security event reporting), which tells you whether reporting works in practice. Mapping the NIS2, DORA and GDPR requirements onto these nodes, rather than keeping four parallel trees, brings the evidence down to a single collection.

Critical point: thresholds and clocks do not merge

Sharing controls does not mean merging the notification triggers, and this is where the data model has to stay explicit instead of simplifying.

The timings diverge. GDPR requires notification of a personal-data breach within 72 hours. NIS2 follows a three-stage process: early warning within 24 hours, notification within 72 hours, final report within one month of the notification (Article 23, detailed by Commission Implementing Regulation (EU) 2024/2690). The same incident can therefore start a 24-hour clock towards the cybersecurity authority and a 72-hour clock towards the data-protection authority, with different content and different recipients.

The thresholds diverge. Commission Implementing Regulation (EU) 2024/2690 defines a significant incident for NIS2 purposes with precise criteria — including a financial impact above EUR 500,000 or 5% of annual turnover, whichever is lower (Article 3) — plus rules for recurring incidents (Article 4) and criteria by entity type (Articles 5 to 14). The GDPR notification threshold is instead the risk to the rights and freedoms of natural persons: a qualitative test, not a figure. An incident can cross one threshold and not the other.

To model this correctly, an incident event is a single entity, linked to one or more notification obligations, each with its own trigger condition evaluated independently and its own deadline computed from the moment the incident was detected. Compressing the two into one rule — “notify everything within 72 hours” — produces both late notifications to the 24-hour authority and superfluous notifications to the data-protection authority for incidents that touch no personal data.

Implications: evidence is produced once, presented in many views

If controls are shared nodes and requirements hang off them, the evidence artefact — a log, a signed policy, a test result — is produced once and pulled in by every requirement that depends on that control. A vulnerability-assessment report serves the NIS2 risk-management requirement, the DORA operational-resilience testing and the corresponding ISO/IEC 27001 control at the same time, without three separate collection runs.

The practical difference is in the marginal cost of the additional regime. When the AI Act adds the obligation to inventory AI systems, in a graph it is a new asset type hung off governance controls that already exist — audit logs, access management, documentation — not a twelfth silo. The cost of extending the model grows with the share of genuinely new requirements, not with the number of regimes.

It is on this unified model that noze built DataGovern, an on-premise compliance platform that holds GDPR, NIS2 and the AI Act together in a single tool; the reasoning on the marginal costs of integrated compliance is taken up in an insight published by noze: https://www.noze.it/en/insights/compliance-manager-integrated-platform/.

Limits

A unified model does not remove the regulatory judgement. The control-requirement mapping is an assertion to be verified: saying that control 5.24 satisfies NIS2 Article 23 means comparing what the procedure does with what the rule asks, and the two diverge — NIS2’s 24-hour warning has no equivalent in ISO/IEC 27001. The mapping has to be revisited whenever the rules or the standards are updated; the regimes cited still have open deadlines in 2026, and the authorities’ guidance keeps refining their interpretation. The data model reduces the duplication of evidence, not the responsibility for deciding whether that evidence is enough.

https://www.gazzettaufficiale.it/eli/id/2024/10/01/24G00155/sg https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj https://eur-lex.europa.eu/eli/reg/2022/2554/oj https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai https://www.iso.org/standard/27001 https://www.acn.gov.it/portale/nis

Cover image: The Berlaymont building in Brussels, headquarters of the European Commission, with its curved glass-and-steel facade under a clear sky — photo by Andersen Pecorone, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Berlaymont_building_2015.jpg