Cross-regulation synergies
Shared inventories, ownership and evidence can reduce duplicate work. The benefit depends on the organisation’s existing controls and actual scope; this guide does not claim a measured percentage saving or a fixed duration for achieving compliance with five regulations.
What can be shared, and what remains specific
| Process | Shared foundation | Separate legal tests |
|---|---|---|
| Risk management | Asset/system register, owners, risk treatment tracking | AI Act Article 9 for relevant high-risk providers; NIS2 Article 21 cyber risk; DORA ICT framework; GDPR risks to people |
| Incidents | Intake, timestamps, evidence, escalation and remediation | Reportability, recipients and clocks under each law — see below |
| Data governance | Data lineage, access, classification and retention schedule | GDPR purpose/basis; Data Act access rights including personal and non-personal data; AI Act Article 10 where applicable |
| Documentation | One repository with version, scope, owner and evidence links | GDPR Article 30 records and limited exceptions; Annex IV for relevant high-risk providers; DORA contracts/assets |
| Training | Role matrix, practical learning, records and review | Contextual AI literacy measures, relevant cybersecurity duties and data protection competence; one certificate does not prove all three |
| Suppliers | Contract register, service criticality, due diligence and exit planning | GDPR processor contracts; AI role allocation; NIS2 supply chain; DORA Article 30 clauses and designated critical provider oversight |
| Testing and audit | Evidence calendar, remediation and independent review where needed | Relevant AI conformity assessment route; suitable tests of all ICT systems/applications supporting critical or important functions at least annually under DORA Article 24(6), excluding microenterprises; account for Article 16 and designated-entity TLPT; risk-based security validation and any national requirements |
Incident reporting: separate triggers and clocks
| Regime | Trigger and main sequence |
|---|---|
| GDPR Articles 33–34 | Controller: notify the authority without undue delay and, where feasible, within 72 hours of awareness unless unlikely to risk people’s rights/freedoms. Processor: notify the controller without undue delay. Inform affected people without undue delay when high risk exists, subject to Article 34 exceptions. The controller documents every personal data breach. |
| NIS2 Article 23 | For the same significant incident, early warning without undue delay and within 24 hours of awareness, notification within 72 hours, final report within one month of the notification. Trust service and ongoing-incident rules qualify this sequence. Apply national recipients and implementation/transition rules. The 72-hour report is not the final report. |
| DORA / Regulation 2025/301 | For a major ICT incident: initial notification as early as possible, at most four hours from classification and no later than 24 hours of awareness; if classification occurs later than 24 hours, within four hours of classification. Intermediate report within 72 hours of initial notification; final report within one month of the intermediate or latest updated intermediate report. Submit the intermediate report even without a status change; update without undue delay and in any case when regular activities recover. Assess weekend/holiday rules and their exclusions under Article 5(3)–(6); notify the authority of delay and reasons no later than the relevant deadline. |
| AI Act Article 73 | Serious incident reporting for relevant high-risk providers, generally immediately after establishing a causal link or reasonable likelihood and no later than 15 days of awareness. Separately assess the special two-day/fatality ten-day cases and Article 73(9)–(10) limitations for equivalent reporting under other law and MDR/IVDR. Deployers have their own notification duties under Article 26(5). Do not apply these high-risk duties to every GPAI API user or confuse Article 73 with Article 62. |
Czech NIS2 implementation: Cybersecurity Act § 15 distinguishes the higher and lower regimes. The higher regime reports cyberspace-origin incidents within the established scope for which intentional fault cannot be ruled out within 24 hours; the lower additionally requires significant impact on the regulated service. The higher regime reports to the Office, the lower to the National CERT. Initial § 16 reporting is without undue delay and no later than 24 hours from awareness of the incident. Further § 16(3) stages require § 15(2) or significant impact on the state’s cyberspace under § 16(2): notification without undue delay within 72 hours from awareness (24 hours from awareness for specified trust services), an intermediate report on request and a final report within 30 days of notification. For an ongoing incident, a progress report follows without undue delay after that deadline, and a final report within 30 days of resolution. Also assess the special digital-services regime in § 18 and commencement under § 15(4) / § 71; distinguish the Directive’s month from Czech law’s 30 days.
AI application dates: the Article 113(c) deferral covers only Chapter III Sections 1–3 except Article 6(5). Article 73 is outside that group. Also check Article 2 scope and Article 111 transitions for each system; do not automatically give Articles 26 and 73 the same deferral.
One case can meet several tests. Record awareness, classification and each submission separately. A shared tool supports this process but does not itself establish compliance.
Boundaries that matter
- DORA and NIS2: DORA is the sector-specific Union act for DORA financial entities also within NIS2, as provided by DORA Article 1(2) and NIS2 Article 4. Assess equivalence of the relevant duties. This is not a blanket exemption for finance from GDPR/Data Act or for ICT suppliers from NIS2.
- AI Act and GDPR: AI high risk does not automatically establish GDPR DPIA or vice versa. Determine Article 27 FRIA and Article 35 DPIA independently; combine work where their requirements overlap. Assess personal data in AI against GDPR Articles 2–3 scope; AI high-risk status is not required. New AI Act Article 4a permits exceptional special-category processing for bias detection and correction under strict cumulative conditions; it does not displace other applicable GDPR duties.
- ISO and law: ISO/IEC 42001 certification concerns a defined AI management system. It is not automatic CE conformity or complete AI Act compliance. A conformity assessment may use internal control or a notified body depending on the legal route.
- TLPT: DORA Article 26 applies to designated entities other than microenterprises and Article 16(1) categories, at least every three years with supervisory adjustment; ordinary testing and TLPT are different obligations.
- Responsibility: Management bodies have duties under NIS2 Article 20 and DORA Article 5; the Article 16 categories use its simplified framework. GDPR accountability belongs to the controller/processor; the DPO advises and monitors. Do not transfer all company fines to an employee’s job title.
- Retention: Automatic high-risk AI logs held under the relevant operator’s control have an appropriate retention period of at least six months under Articles 19/26, unless other law provides otherwise. Where Article 18 applies, providers retain the specified documents for ten years after the system is placed on the market or put into service; financial institutions must account for paragraph 3. Personal data require a purpose-specific retention assessment; neither period is a blanket rule for all prompts or all company records.
How to measure the benefit
- Map each applicable duty to an owner, source and acceptance evidence.
- Reuse genuinely shared evidence while keeping the legal conditions visible.
- Track work hours, repeated requests and unresolved gaps against a documented baseline.
- Review sample quality and operation before declaring completion.
A governance project can provide a scoped inventory, rules, gap analysis and remediation plan. The applicable obligations, implementation, testing and any certification must be specified separately for the actual delivery.
Content reviewed: 6 September 2026. Primary sources: AI Act, Digital Omnibus on AI, NIS2, NÚKIB: registrace a lhůty, GDPR, DORA, Data Act, DORA incident reporting.
Primary source for the Czech rules: 264/2025 Sb..