Regulatory, GRC, Compliance

Regulation as Architecture - DORA, NIS2, and the EU AI Act

By Clateway Technology Council · 15 March 2026 · 36 min read

CLATEWAY INSIGHTS · DEEP DIVE SERIES

Trend Report 2025–2026 · Part 5 of 6

Regulation as Architecture --- DORA, NIS2, and the EU AI Act

How the EU's regulatory superstructure is forcing enterprises to redesign governance from the ground up — and why compliance with DORA, NIS2, and the incoming EU AI Act is no longer a legal exercise but an architectural one.

Based on 5,000 news signals, April 2025 – March 2026 | www.clateway.com

The fifth major trend identified across the Clateway Media feed of 5,000 news signals is the one that binds all the others together: regulation. Specifically, the convergence of three landmark EU regulatory frameworks — DORA, NIS2, and the EU AI Act — into an unprecedented governance architecture that is reshaping how European organisations think about technology risk, ICT vendor relationships, AI deployment, and board accountability simultaneously.

The feed's regulatory signal ran consistently across the entire 12-month period at a volume of over 393 articles, but with a character that distinguished it from the compliance-heavy coverage of previous years. The dominant theme was no longer 'what does this regulation require?' — that phase is over. The dominant theme of 2025–2026 was 'how do these regulations interact with each other, and why is compliance a fundamentally different kind of challenge when you are trying to satisfy three major frameworks simultaneously?'

Three developments anchored the regulatory narrative of the period. First, DORA entered full enforcement on 17 January 2025 — the first day it became legally binding, not merely advisory — immediately changing the character of every cloud vendor negotiation, every ICT third-party risk assessment, and every board-level technology risk conversation in European financial services. Second, the EU AI Act crossed its August 2025 governance milestone: GPAI model obligations and the EU AI Office became operational, with the penalty regime activating and the full Annex III high-risk compliance deadline fixed at 2 August 2026. Third, the CISA/CSA governance maturity research and the November 2025 Digital Omnibus proposal together created a new dynamic: the EU was simultaneously accelerating enforcement and proposing simplifications to reduce compliance burden — sending mixed signals that pragmatic IT leaders needed to decode carefully.

The synthesis for enterprise IT leaders is clear: compliance with DORA, NIS2, and the EU AI Act can no longer be managed through separate workstreams. The frameworks overlap, cross-reference, and in some cases contradict each other. The organisations that will navigate this regulatory environment most effectively are those that treat regulation as an architectural input — a design constraint that shapes how systems are built, how vendors are selected, how AI is deployed, and how governance operates — rather than a checklist that is completed after the fact.

The Clateway RCEC framing: Research the three frameworks and their interactions. Commit to a unified governance programme that addresses all three without duplicating effort. Execute the technical and operational controls each framework requires. Control through continuous compliance monitoring that generates evidence for supervisors, auditors, and insurers who will ask for it.

PART 1 DORA: THE FIRST YEAR OF ENFORCEMENT REALITY

DORA at One Year: From Deadline Anxiety to Operational Reality

What DORA actually requires — and where most firms still fall short

DORA — the Digital Operational Resilience Act — entered full application on 17 January 2025, covering banks, insurance companies, investment firms, payment service providers, crypto-asset service providers, and their ICT third-party service providers across all EU member states. After two years of preparation, the consensus from the Clateway feed's coverage through 2025 was consistent: most firms met the deadline in form, but not in substance.

The Morgan Lewis analysis of DORA's first implementation wave documented what 'meeting the deadline in form' looked like in practice: policies written and submitted, registers of information filed with national competent authorities by the April 30, 2025 deadline, and contractual clauses added to ICT vendor agreements. What lagged was the operational reality behind those forms — the ongoing monitoring of third-party ICT providers, the actual execution of digital operational resilience testing programmes, and the cultural shift required to treat ICT risk as a board-level topic rather than an IT department concern.

The five pillars of DORA and their practical compliance gaps

DORA organises its requirements across five pillars, each with a distinct compliance challenge that the Clateway feed's 2025 coverage surfaced repeatedly:

• Pillar 1 — ICT Risk Management Framework: Firms must maintain a comprehensive, board-approved ICT risk management framework covering identification, protection, detection, response, and recovery. The gap most firms encountered: governance oversight. DORA requires the management body to bear personal accountability for ICT risk — a cultural shift in organisations where board members historically viewed technology risk as a delegated management function.

• Pillar 2 — ICT Incident Management and Reporting: Major ICT incidents must be reported to competent authorities within strict timeframes: initial notification within four hours of classification, intermediate report within 72 hours, and final report within one month. The gap: incident classification. Most firms had incident management processes; few had the classification methodology required by DORA's Regulatory Technical Standards, which introduced specific criteria for 'major' incidents including service availability thresholds, client impact, and geographic scope.

• Pillar 3 — Digital Operational Resilience Testing: Annual basic resilience testing for all entities, with threat-led penetration testing (TLPT) at least every three years for systemically important entities. The gap: TLPT readiness. As BaFin noted, only a small proportion of entities would be subject to mandatory TLPT — but those that are faced a demanding methodology based on TIBER-EU standards, requiring a threat intelligence component, red-team execution against live production systems, and a formal remediation plan submitted to the supervisor.

• Pillar 4 — ICT Third-Party Risk Management: This was the most widely discussed pillar in the Clateway feed, and for good reason: it fundamentally changed vendor relationships. Firms must maintain a comprehensive register of all ICT third-party arrangements, assess concentration risk before entering new contractual arrangements, include mandatory contractual clauses in all agreements, and perform due diligence assessments proportionate to the criticality of the service. For cloud providers, this means audit rights, data location clauses, business continuity obligations, and exit strategy documentation.

• Pillar 5 — ICT Concentration Risk and Critical Third-Party Oversight: The most forward-looking pillar establishes EU-level oversight of critical ICT third-party providers (CTPPs). The ESAs' April 2025 roadmap outlined the designation process: national competent authorities submitted registers of information by April 30, 2025; the ESAs performed criticality assessments by July 2025; designation notifications were issued with a six-week objection window. The practical consequence: the largest cloud providers — AWS, Microsoft Azure, Google Cloud — face direct Joint Examination Team oversight, a development with significant implications for how those providers structure their European operations.

Google Cloud: a critical ICT third-party provider under DORA

One article from the Clateway feed that captured the practical significance of DORA's third-party pillar with unusual directness was the November 2025 Google Cloud blog: 'A new era: Supporting customers as a critical ICT third-party provider under EU DORA.' The article documented Google Cloud's own acknowledgement of its CTPP status and the specific contractual, operational, and documentation commitments it was making to financial sector customers subject to DORA obligations. The significance was not Google Cloud's specific commitments — it was the precedent: for the first time, major hyperscalers were publicly positioning compliance with financial sector regulation as a core product requirement, not merely a commercial nicety.

The Clateway feed documented similar positioning from AWS and Microsoft, both of which updated their financial sector compliance documentation, added DORA-specific contractual addenda to their customer agreements, and launched DORA-specific compliance tools for regulated customers. The competitive dynamic was instructive: DORA compliance support became a differentiator in cloud procurement conversations, with regulated entities asking vendors not just 'can you sign our DORA contract clauses?' but 'can you provide the audit evidence, resilience test documentation, and concentration risk data that our supervisors will ask for?'

The DORA-AI Act intersection: a governance challenge nobody was fully prepared for

The most complex compliance challenge to emerge from the feed's DORA coverage was the intersection with the EU AI Act. DORA's ICT risk management requirements apply to AI systems used by financial entities — but the EU AI Act introduces additional, AI-specific obligations that overlap with, complement, and in some cases go beyond DORA's requirements. The November 2025 Digital Omnibus proposal acknowledged this explicitly, proposing amendments to create a single incident reporting point and align breach notification timelines between DORA, GDPR, NIS2, and the AI Act.

Before the Digital Omnibus creates legislative clarity, firms in financial services are operating in an environment where an AI system used for credit scoring, risk assessment, or fraud detection must simultaneously satisfy DORA's ICT risk management requirements (ICT asset management, resilience testing, vendor documentation), the EU AI Act's high-risk AI obligations (conformity assessment, technical documentation, human oversight, post-market monitoring), GDPR's data protection requirements (lawful basis, purpose limitation, subject rights), and potentially NIS2 if the firm operates critical infrastructure. The practical implication: compliance is not a legal review exercise. It is a systems architecture exercise.

2% of global annual turnover — maximum penalty for financial entities failing DORA requirements

Source: DORA Regulation (EU) 2022/2554, Article 50

€5M maximum fine per day for critical ICT third-party service providers failing to remedy DORA deficiencies, for up to six months

Source: DORA Regulation, Article 52

4 hrs maximum time from classification to initial supervisor notification for major ICT incidents under DORA

Source: DORA Regulatory Technical Standards on Incident Classification

20 categories of financial entities covered by DORA — from banks to crypto-asset service providers to data analytics providers for financial institutions

Source: DORA Regulation, Article 2

Leadership implication: DORA's enforcement is not a theoretical risk. The ESAs designated Critical ICT Third-Party Providers in 2025 and launched Joint Examination Teams. Your organisation's register of information is already with your national competent authority. If your ICT risk management framework, incident classification methodology, and third-party contract documentation are not in full alignment with DORA's RTS requirements, you are already non-compliant. The question is how long before a supervisor asks to see the evidence.

PART 2 NIS2: THE WIDER CIRCLE OF OBLIGATION

NIS2: Cybersecurity Compliance Becomes a Board Responsibility Across Every Sector

NIS2 in practice: the expanded scope and its implications

While DORA dominated the regulatory conversation in financial services, NIS2 — the Network and Information Systems Directive 2 — was reshaping cybersecurity governance obligations across a much broader population of European enterprises. NIS2 expanded the scope of the original NIS Directive to cover 18 sectors across essential and important entities, including energy, transport, health, water, digital infrastructure, manufacturing, food production, postal services, waste management, and public administration. The expansion was not incremental — it was structural, potentially increasing the number of EU entities subject to cybersecurity regulation by tenfold.

The compliance deadline for NIS2 transposition into national law was October 17, 2024. The Clateway feed's coverage of NIS2 through 2025 documented an uncomfortable reality: most EU member states had transposed the directive, but implementation at the enterprise level was uneven. Many 'important entities' — companies in the second tier of NIS2's scope — were still assessing whether they fell within the regulation's coverage, let alone implementing the required security measures.

What NIS2 actually requires from IT leaders

NIS2's Article 21 security measures are the operational core of the regulation. They require entities to adopt 'appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems.' The measures are not prescriptive in the way DORA's RTS are — NIS2 leaves significant discretion to entities to determine appropriate controls — but the minimum obligations are substantial:

• Risk management policies and incident handling: Entities must have documented risk management policies, incident detection and response procedures, and a formal incident classification methodology. NIS2 introduces 24-hour initial notification requirements for significant incidents — tighter than the DORA 4-hour window, which applies only to 'major' ICT incidents in financial services.

• Business continuity and crisis management: Backup management, disaster recovery, and crisis management plans. The standard is not prescriptive, but supervisory expectations — documented in ENISA's NIS2 implementation guidance — suggest that entities should be able to demonstrate tested recovery procedures with defined RTOs for critical systems.

• Supply chain security: NIS2's supply chain security requirements are the most operationally demanding for many enterprises. Entities must assess the security practices of direct suppliers and service providers, and the language of Article 21(2)(d) extends this to 'the security of networks and information systems of suppliers and service providers.' This is a significant expansion: it means the security posture of your software vendors, cloud providers, and managed service providers is now within scope of your NIS2 compliance programme.

• Cybersecurity training and awareness: Board members and senior management must complete cybersecurity training. This is not a general corporate governance recommendation — it is a specific NIS2 obligation. The regulation makes management bodies personally liable for approving and overseeing the implementation of cybersecurity risk management measures, and requires that they participate in specialised training to acquire sufficient knowledge to identify risks and assess cybersecurity risk management practices and their impact.

• Encryption and access control: Multi-factor authentication, zero trust principles, encryption in transit and at rest, and secure voice, video, and text communications. The MFA requirement in NIS2 is broadly interpreted by supervisory authorities to include all administrative access, not just external user authentication.

The board liability dimension: personal accountability under NIS2

The most consequential governance change introduced by NIS2 was the personal liability of management body members for cybersecurity failures. Article 20 of NIS2 makes explicit that management bodies are responsible for approving cybersecurity risk management measures and overseeing their implementation — and that member states shall ensure that management bodies can be held liable for infringements of the regulation. Several EU member states transposing NIS2 into national law extended this to include personal fines for members of the management body who approve inadequate cybersecurity measures.

The Clateway feed's coverage of this development was consistent through the period: CISOs rising to board prominence, cybersecurity appearing in board reporting packs alongside financial metrics, and the concept of the 'bilingual board' — fluent in both AI strategy and cybersecurity risk — emerging as a governance aspiration. The Google Cloud CISO Perspectives piece from September 2025, 'Boards should be bilingual in AI, security to gain advantage,' captured the direction of travel: organisations where the board understands both dimensions of the technology risk landscape will respond more effectively to regulatory scrutiny than those where the board treats cybersecurity as a technical function that is delegated downward.

NIS2 and DORA: the overlap that creates compliance efficiency opportunities

A point that the Clateway feed's compliance-focused articles surfaced repeatedly was that NIS2 and DORA, while distinct, have significant overlap in their security measure requirements. For financial entities subject to both (NIS2's digital infrastructure and ICT service management categories overlap with DORA's scope), a unified compliance programme that satisfies both simultaneously is both possible and more efficient than two separate programmes.

The practical approach — documented in both the ENISA guidance and the practitioner analysis in the feed — is to build the compliance programme around the more demanding requirements of DORA (given its greater specificity through the RTS framework), and then verify that each DORA control satisfies the relevant NIS2 Article 21 obligation. Where DORA is silent on a topic that NIS2 covers (supply chain security for non-ICT vendors, for example), supplement accordingly. The result is a unified ICT risk and cybersecurity governance programme that demonstrates compliance with both frameworks from a single evidence base.

Key distinction: NIS2 applies to your supply chain — not just your own systems. If a key software supplier or cloud service provider has poor security practices, that is your NIS2 compliance problem, not theirs. Article 21(2)(d) supply chain security requirements mean that the security posture of your vendors is within scope of your NIS2 programme. This fundamentally changes how vendor security assessments must be structured.

PART 3 THE EU AI ACT: THE COMPLIANCE DEADLINE MOST ENTERPRISES ARE NOT READY FOR

The EU AI Act: Five Months to the Most Consequential AI Governance Deadline in History

The timeline that defines enterprise AI governance in 2026

The EU AI Act entered into force on 1 August 2024. Since then, it has been rolling out in phases, with each milestone creating new obligations for providers and deployers of AI systems in the EU market. From the perspective of an enterprise IT leader in March 2026, the critical picture is this:

2 Feb 2025 Prohibited AI practices enforceable. Unacceptable-risk AI systems banned. AI literacy obligations active for all entities using AI.

2 Aug 2025 GPAI governance active; penalty regime live. General-purpose AI model obligations apply. EU AI Office operational. Fines of up to €35M or 7% of global turnover for prohibited practices; up to €15M or 3% for other obligations.

2 Aug 2026 Full enforcement for Annex III high-risk AI systems. The majority of remaining obligations enter application. Conformity assessments must be complete. CE marking required. EU database registration for high-risk systems. THIS IS FIVE MONTHS AWAY FROM THE DATE OF THIS PUBLICATION.

2 Aug 2027 High-risk AI in regulated products. AI systems embedded in products covered by EU product safety legislation (medical devices, machinery, automotive) must comply. Extended transition for systems already on the market.

What 'high-risk' means — and why more organisations are affected than they realise

The EU AI Act's Annex III lists the categories of AI systems that are classified as high-risk and therefore subject to the full conformity assessment and technical documentation regime. For enterprise IT leaders, the scope of Annex III is often surprising. The categories include AI systems used in:

• Employment and workforce management: AI used for recruitment and selection (CV screening tools, interview scoring systems), task allocation, performance monitoring, and promotion decisions. Every enterprise using an AI-powered HR or recruitment platform needs to assess whether it falls within this category.

• Access to essential services: AI used in creditworthiness assessment, insurance premium setting, and social benefit decisions. Financial services firms using AI for any credit decision — including internal credit scoring for counterparty risk — face high-risk obligations.

• Education and vocational training: AI used for determining access to educational institutions or evaluating learning outcomes. For enterprises deploying AI in corporate learning management systems or employee assessment tools, this category may apply.

• Law enforcement and border control: Primarily public sector, but also relevant to private security services and employers using biometric identification systems.

• Critical infrastructure management: AI used as safety components in critical digital infrastructure — relevant to utilities, telecoms, financial market infrastructure operators, and transport providers.

The practical compliance burden for Annex III high-risk AI systems is substantial. Providers (companies that develop and place AI systems on the market) must establish a quality management system, maintain technical documentation, maintain logs, conduct conformity assessments (including third-party assessment for some categories), affix CE marking, and register the system in the EU database. Deployers (enterprises using high-risk AI systems) must use systems in accordance with instructions of use, ensure human oversight, monitor system performance, and report serious incidents.

The GPAI provisions: what took effect in August 2025

The August 2025 GPAI obligations — which became active during the feed period — created immediate compliance requirements for providers of general-purpose AI models. Providers must maintain technical documentation and submit it to the EU AI Office on request. They must publish a public summary of training content. They must implement measures to comply with EU copyright rules. For GPAI models with 'systemic risk' (currently interpreted as models trained with computing power exceeding 10^25 FLOPs), additional obligations apply: adversarial testing, incident reporting to the EU AI Office, and energy efficiency disclosures.

The August 2025 GPAI Code of Practice — published voluntarily by independent experts and endorsed by the Commission — provided practical guidance for providers to demonstrate compliance. The Clateway feed documented extensive activity around the Code from foundation model providers including Google, Microsoft, Anthropic, Mistral, and Meta, all of whom engaged with the Code of Practice process while simultaneously advocating for proportionate implementation through their regulatory affairs channels.

For enterprise IT leaders, the GPAI provisions have a specific relevance that is often overlooked: when an enterprise deploys a GPAI model within its own infrastructure — whether through fine-tuning, system prompt configuration, or integration into a product — it may assume the role of 'provider' rather than 'deployer' under the AI Act, with the full provider compliance burden. The distinction between deployer (use the model as-is) and provider (modify, fine-tune, or integrate into a product and place on the market) is critical for determining compliance obligations, and many enterprise AI deployments sit in legally uncertain territory.

The Digital Omnibus: the proposed simplification that may or may not materialise

In November 2025, the European Commission published the Digital Omnibus package — a legislative proposal to simplify and harmonise the EU's digital regulatory landscape. For AI Act compliance specifically, the Digital Omnibus proposed linking the application of high-risk Annex III rules to the availability of harmonised standards and compliance support tools, with a long-stop deadline of 2 December 2027 (rather than 2 August 2026). This would provide enterprises with additional preparation time — but it is not law.

The Clateway feed's regulatory coverage through early 2026 was consistent on this point: organisations should not plan on the Digital Omnibus delay materialising. The proposal requires European Parliament and Council agreement, which takes time. August 2026 remains the binding deadline until amended legislation is formally adopted. Prudent organisations are treating August 2026 as the compliance target and will benefit from any Digital Omnibus extension as additional buffer — not as a reason to defer action.

€35M or 7% of global annual turnover — maximum penalty for infringements relating to prohibited AI practices under the EU AI Act

Source: EU AI Act, Regulation (EU) 2024/1689, Article 99

€15M or 3% of global annual turnover — maximum penalty for non-compliance with high-risk AI obligations, including inadequate conformity assessment or missing technical documentation

Source: EU AI Act, Article 99

76% of organisations in a CSA 2025 compliance benchmark report planned to pursue AI governance frameworks like ISO 42001

Source: CSA 2025 Compliance Benchmark Report, cited in ISACA analysis

~65% of organisations now using generative AI in some business function — up from 33% in 2023

Source: CSA/Google Cloud State of AI Security and Governance Survey, December 2025

Leadership implication: August 2 2026 is five months away. If your organisation deploys AI systems in any of the Annex III high-risk categories — which almost certainly includes AI used in HR, credit, critical infrastructure, or safety systems — you need completed conformity assessments, finalised technical documentation, and a deployment monitoring programme in place by that date. If you have not started this work, the window for comfortable compliance has closed.

PART 4 THE GOVERNANCE STANDARDS: ISO 42001, NIST AI RMF, AND CSA STAR FOR AI

The Governance Standards: From Voluntary Frameworks to Compliance Infrastructure

The proliferation of AI governance frameworks and why it matters

The regulatory landscape for AI is not limited to the EU AI Act. The 2025–2026 Clateway feed documented the emergence of a parallel ecosystem of voluntary governance frameworks, industry standards, and certification programmes that are rapidly transitioning from nice-to-have differentiators to de facto compliance requirements. The driver: regulatory frameworks like the EU AI Act and NIS2 require 'appropriate' and 'proportionate' security and governance measures without always specifying exactly what those measures are. The harmonised standards that will provide that specificity are still being developed by CEN/CENELEC. In the interim, standards like ISO 42001 and NIST AI RMF fill the gap.

ISO 42001: the certifiable AI governance standard

ISO/IEC 42001, published in December 2023, is the international standard for AI Management Systems (AIMS). It is the AI equivalent of ISO 27001 for information security: a certifiable standard that organisations can have independently audited, with a formal certificate issued by an accredited body. The Clateway feed documented rapid adoption through 2025:

• GitLab achieved ISO 42001 certification for AI governance in September 2025, becoming one of the first major enterprise software platforms to do so.

• The 2025 CSA Compliance Benchmark Report found that 76% of organisations planned to pursue ISO 42001 or equivalent frameworks.

• Early adopters of ISO 42001 reported faster customer adoption, reduced friction in sales cycles, and competitive differentiation with enterprise customers requiring verified AI governance as a procurement condition.

The commercial significance of ISO 42001 certification — documented extensively in the Clateway feed — is that it provides the 'verifiable proof' of AI governance that DORA, NIS2, and the EU AI Act each require in different ways but none of them prescribe specifically. A DORA-regulated financial entity purchasing an AI system from a certified ISO 42001 vendor has a much cleaner path to demonstrating that it conducted appropriate due diligence on the AI system's governance than one purchasing from a vendor with only a self-asserted governance statement.

The 38 controls of ISO 42001

ISO 42001's compliance requirements include 38 distinct controls organised into 9 control objectives, covering AI system risk assessment and impact assessment, AI policy and governance framework design, AI system lifecycle management (from design through decommissioning), data management for AI (data quality, bias assessment, training data governance), human oversight mechanisms, transparency and explainability requirements, stakeholder communication, monitoring and continuous improvement, and incident response for AI-specific failures.

For organisations already certified to ISO 27001 (information security management), the transition to ISO 42001 is significantly streamlined — the two standards share a management system structure, and many controls overlap. The CSA FAQ on ISO 42001 documented the most efficient implementation path: treat ISO 42001 as an extension of the existing ISMS rather than a separate programme, reuse the risk committee structure, evidence collection processes, and management review cycle, adding AI-specific controls as supplemental requirements.

NIST AI RMF: the US framework with global relevance

The NIST AI Risk Management Framework (AI RMF) — published in January 2023 and updated through 2025 with supplementary guidance — provides a flexible, voluntary framework organised around four core functions: Govern, Map, Measure, and Manage. Unlike ISO 42001, the NIST AI RMF is not certifiable — organisations can align with it or use it as a management tool, but cannot obtain independent certification.

The NIST AI RMF's relevance for European IT leaders is indirect but significant: it was developed in close alignment with the EU AI Act's risk-based approach, and the crosswalk between the two frameworks — documented by the CSA — shows substantial overlap in requirements. Organisations that implement the NIST AI RMF as a management tool are building capabilities that directly translate into EU AI Act compliance evidence.

More directly, the NIST Centre for AI Standards and Innovation (CAISI) — launched in December 2025 — positioned NIST as the central institution for developing harmonised AI governance standards with global relevance. For multinational organisations operating in both EU and US jurisdictions, an integrated governance programme that satisfies both the NIST AI RMF and ISO 42001 provides the broadest regulatory coverage at the lowest incremental cost.

CSA STAR for AI: the cloud AI governance certification

The CSA launched STAR for AI in October 2025, described as the first global framework for responsible and auditable artificial intelligence in cloud environments. STAR for AI builds on the existing CSA STAR cloud security certification, adding AI-specific controls drawn from the AI Controls Matrix (AICM), and requires ISO 42001 or ISO 27001 as a prerequisite.

The AICM itself — published by the CSA in July 2025 and named a 2026 CSO Awards winner in March 2026 — provides the most comprehensive practical control framework for AI security governance available from a neutral, standards-setting body. The Clateway feed noted its relevance for organisations navigating the intersection of cloud security, AI governance, and regulatory compliance: the AICM maps directly to the EU AI Act, ISO 42001, the NIST AI RMF, and DORA's ICT risk management requirements, providing a unified control library that satisfies multiple frameworks simultaneously.

AIUC-1: the emerging agentic AI governance standard

One framework that appeared in the Clateway feed in late 2025 and deserves forward-looking attention is AIUC-1 — a new framework developed for AI agent adoption and usage, built on ISO 42001, the EU AI Act, and NIST AI RMF. As AI agents move from experimentation to autonomous operation within core business systems, AIUC-1 provides a single, auditable governance standard for enterprises deploying agents in high-stakes workflows. Given the agentic AI adoption trajectory documented in Part 1 of this series, AIUC-1 is likely to become a significant governance reference within the next 12 to 24 months.

Governance maturity as the strongest predictor of AI readiness

The most important finding from the CSA/Google Cloud State of AI Security and Governance Survey, published in December 2025, was not about any specific control or framework. It was about the relationship between governance maturity and AI readiness: governance maturity was the strongest predictor of an organisation's ability to adopt AI responsibly and generate measurable business value from it. Organisations with mature governance frameworks deployed AI more successfully, experienced fewer security incidents, and reported higher levels of stakeholder confidence in their AI programmes.

The implication — reinforced throughout the Clateway feed's governance coverage — is that the organisations treating regulatory compliance as a burden are misreading the situation. ISO 42001, NIST AI RMF, and CSA STAR for AI are not friction added to AI adoption. They are the governance infrastructure that makes AI adoption scalable, trustworthy, and commercially durable. The organisations that build this infrastructure now will outperform those that build it reactively in response to a regulatory enforcement event or a governance failure.

Leadership implication: ISO 42001 certification is becoming a procurement requirement. Enterprise customers buying AI-integrated software platforms will increasingly require certified AI governance as a condition of purchase — exactly as ISO 27001 became a standard procurement requirement for information security over the past decade. If your organisation provides AI services to regulated enterprises, the question is not whether to certify, but how soon.

PART 5 THE BOARD DIMENSION: FROM COMPLIANCE TO ACCOUNTABILITY

From Compliance to Accountability: The Board-Level Governance Transformation

The CISO ascendancy — and what it means

The Clateway feed documented a persistent theme through 2025–2026: CISOs rising to board prominence, with cybersecurity and AI risk governance appearing on board agendas as primary topics rather than management updates. The January 2026 article 'CISOs Rise to Prominence: Security Leaders Join the Executive Suite' documented the structural driver: rising regulatory and compliance standards — specifically DORA's management body accountability requirements and NIS2's board training obligations — were forcing organisations to elevate security leadership to the level where accountability resided.

The CISOs Finally Get a Seat at the Board's Table analysis from October 2025 added nuance: the opportunity was real, but the catch was significant. Boards were inviting CISOs to the table not because they had become enthusiastic about cybersecurity governance, but because regulation had made the cost of not understanding it unacceptably high. The CISOs that succeeded in this environment were those who could translate technical risk into business risk language — quantified, comparative, and actionable — rather than those who presented CVSS scores and patch cycle statistics.

The AI Control Tower concept: enterprise architecture as governance platform

The most intellectually significant governance article in the Clateway feed's regulation category was the January 2026 piece 'The Control Illusion is Over: Why Your Enterprise Architecture Must Become the AI Governance Operating System.' The article articulated a structural governance challenge that the regulatory frameworks themselves do not resolve: how do you govern AI systems that operate continuously, autonomously, and across multiple enterprise systems when your governance framework was designed for human-supervised, bounded processes?

The article's central argument was that enterprise architecture — specifically the technology platforms and workflow systems that define how the enterprise operates — must become the governance layer for AI, not merely the deployment platform. This is not a metaphor. The ServiceNow AI Control Tower concept, the Microsoft AI Governance Platform (named a Leader in the IDC MarketScape for Unified AI Governance Platforms in January 2026), and Google Cloud's Recommended AI Controls Framework (published June 2025) all represent the same architectural thesis: AI governance cannot be delivered through a separate compliance programme. It must be built into the systems that run the enterprise.

For IT leaders, the practical consequence is that governance investments and technology investments are converging. Buying an AI platform without a governance layer is not a compliance shortcut — it is a liability accumulation. The platforms that will win in the enterprise AI market are those that deliver governance capability as a first-class feature, not an add-on compliance module.

Model risk management: the financial sector governance precedent

Financial services organisations face an additional governance dimension that the broader enterprise market is only beginning to encounter: model risk management (MRM). The concept — developed by banking regulators including the Federal Reserve's SR 11-7 guidance — requires financial institutions to validate, test, document, and monitor the models they use for decision-making, including AI models.

The Clateway feed documented a significant development through the regulatory coverage: model risk management principles are migrating from the financial sector to the wider enterprise through the EU AI Act. The AI Act's high-risk AI system requirements for conformity assessment, technical documentation, post-market monitoring, and human oversight are, in substance, a form of model risk management applied to AI systems in regulated contexts. Organisations in financial services already operating mature MRM frameworks have a significant compliance advantage for the August 2026 AI Act deadline — they have the governance structures, the documentation practices, and the testing methodologies that the AI Act requires.

AI insurance: the market signal on governance maturity

One signal that the Clateway feed surfaced that is often missed in regulatory compliance analysis was the insurance market's response to AI governance maturity. The January 2026 article on data centre insurance and the feed's broader cyber insurance coverage documented a consistent theme: insurers were beginning to differentiate AI governance maturity in their pricing and coverage terms.

Google Cloud's expansion of its Risk Protection Program to include AI coverage (documented in May 2025) — providing insurance that reflects the specific risk profile of cloud AI deployments — signalled that the insurance market was building the actuarial models to price AI governance risk. The practical implication for enterprise IT leaders: mature AI governance programmes (ISO 42001-certified, with documented conformity assessments and ongoing monitoring) are beginning to deliver measurable insurance premium benefits. The commercial value of governance maturity is no longer limited to regulatory avoidance — it is beginning to appear on the P&L through insurance cost reduction.

PART 6 THE REGULATORY CONVERGENCE OPPORTUNITY: ONE PROGRAMME, THREE FRAMEWORKS

The Convergence Opportunity: Building One Governance Programme for Three Frameworks

The case against separate compliance workstreams

The most inefficient approach to the DORA/NIS2/AI Act regulatory environment is the one that many organisations have defaulted to: three separate workstreams, three separate teams, three separate evidence bases, and three separate audit preparations. This approach is not only inefficient — it creates gaps at the intersections where the frameworks overlap and gaps at the places where they diverge.

The Digital Omnibus proposal from November 2025 signalled that the European Commission itself recognises the convergence challenge and is attempting to address it through a single incident reporting point and aligned breach notification timelines. Pending that legislative resolution, the practical governance approach for organisations subject to multiple frameworks is to build a unified programme that treats the three frameworks as complementary dimensions of a single governance challenge: operational resilience (DORA), cybersecurity (NIS2), and AI accountability (AI Act).

The unified control architecture

Building a unified compliance programme that satisfies DORA, NIS2, and the EU AI Act simultaneously requires a structured approach to identifying overlapping requirements, satisfying the most demanding version of each, and avoiding duplicated effort. The framework that the Clateway feed's compliance practitioners consistently recommended was organised around five shared governance domains:

• Risk management and classification: DORA requires an ICT risk management framework. NIS2 requires a risk management approach for cybersecurity. The AI Act requires risk classification for AI systems and a risk management system for high-risk AI. A unified risk register that covers ICT risk, cybersecurity risk, and AI risk — with consistent methodology for risk identification, assessment, treatment, and residual risk acceptance — satisfies all three frameworks from a single governance structure.

• Incident management and reporting: DORA's 4-hour initial notification, NIS2's 24-hour early warning, and the AI Act's serious incident reporting create a multi-tier notification structure. A unified incident management framework with clear classification criteria that trigger the appropriate notification pathway for each framework — and a single reporting interface for the supervisor notifications — is both more efficient and more compliant than three separate incident management processes.

• Third-party and supply chain governance: DORA's ICT third-party risk management requirements and NIS2's supply chain security obligations both require assessment of vendor security practices. A unified vendor assessment framework that collects the evidence required by both frameworks — including DORA's mandatory contractual provisions and NIS2's supply chain risk assessment — eliminates the duplication of sending multiple questionnaires to the same vendor for different compliance purposes.

• Testing and validation: DORA's digital operational resilience testing (including TLPT for systemically important entities), NIS2's vulnerability assessment requirements, and the AI Act's conformity assessment for high-risk systems all require testing programmes. A unified testing calendar that coordinates penetration testing, adversarial AI testing, business continuity testing, and AI system performance monitoring achieves regulatory coverage more efficiently than separate testing programmes.

• Governance documentation and evidence: All three frameworks require documentation: DORA's ICT risk management framework documentation, NIS2's cybersecurity policy documentation, and the AI Act's technical documentation for high-risk systems and quality management system records. A single documentation repository — ideally in a GRC platform that maps evidence to multiple framework requirements simultaneously — eliminates the need to duplicate documentation creation and maintenance across frameworks.

The governance maturity multiplier

The CSA's December 2025 research finding that governance maturity was the strongest predictor of AI readiness and responsible innovation suggests a governance investment thesis that extends beyond regulatory compliance. Organisations that build mature, unified governance programmes for DORA, NIS2, and the AI Act are not merely avoiding regulatory penalties — they are building the operational capability to deploy AI faster, more safely, and with greater stakeholder confidence than competitors who treat governance as a cost centre.

This thesis is consistent with the insurance market signal, the ISO 42001 procurement differentiator dynamic, and the board visibility opportunity documented throughout the feed. The organisations that will lead in AI adoption over the next three to five years are not those that deploy the most AI fastest. They are those that deploy AI in a way that earns the trust of customers, regulators, and counterparties — and governance maturity is the mechanism through which that trust is built and demonstrated.

PART 7 THE RCEC LEADERSHIP AGENDA FOR REGULATION AS ARCHITECTURE

The Regulatory Governance Agenda: RCEC Applied to DORA, NIS2, and the EU AI Act

The regulatory signal from the 2025–2026 Clateway feed creates a leadership agenda that is more complex than simple compliance management — and more valuable when executed correctly. The RCEC framework structures the necessary actions across three interconnected regulatory frameworks:

Research: Understanding your actual regulatory exposure

• Map your DORA scope with precision: Not all financial entities have the same DORA obligations. Determine which DORA pillar requirements apply at your proportionality tier, which of your systems require TLPT versus basic resilience testing, and whether any of your ICT providers will be designated as Critical Third-Party Providers — which triggers specific contractual and due diligence obligations on your side.

• Assess your NIS2 classification: Determine with legal certainty whether your organisation falls within NIS2 as an essential entity, an important entity, or neither. If you fall within scope, identify which sector classification applies and what the proportionate security measures are for your risk profile. Many organisations in manufacturing, food production, and postal services are still unaware of their NIS2 status.

• Conduct an AI system inventory and risk classification: Identify every AI system your organisation uses, develops, or deploys. For each, determine: does it fall within an Annex III high-risk category? Does it constitute a GPAI model deployment that might make you a 'provider' rather than a 'deployer'? What documentation does your vendor provide for conformity assessment? This inventory does not exist in most organisations' asset management systems and must be created explicitly.

• Map framework overlaps: Document where DORA, NIS2, and the AI Act overlap, and where they diverge. The overlaps are opportunities for efficiency. The divergences are risks: areas where satisfying one framework does not automatically satisfy another, and where gaps in unified coverage create compliance exposure.

Commit: Board-level governance decisions the regulation requires

• Establish a unified regulatory governance programme: Appoint a senior executive owner for the DORA/NIS2/AI Act compliance programme — not three separate workstreams with three separate owners. This person should report to the board, have authority to direct resources across technology, legal, compliance, and operations, and be accountable for the unified programme's evidence base.

• Board training on cybersecurity and AI: NIS2 Article 20 board training is not optional. Document that every member of the management body has completed appropriate cybersecurity and AI risk training. This documentation will be requested by supervisors. The training should not be a single slide in a board meeting — it should be a structured programme covering the specific regulatory obligations applicable to your organisation, the risk landscape your CISO has assessed, and the governance decisions the board needs to make.

• Authorise AI conformity assessment investment: If your organisation deploys high-risk AI systems under Annex III, completing conformity assessments before August 2026 requires qualified external resources, technical documentation creation, and potentially significant engineering time to provide evidence of the system's performance, robustness, and bias mitigation. This investment requires board authorisation because it has material resource implications and cannot be delivered within normal operating budgets at most organisations.

• Commit to ISO 42001 or equivalent AI governance certification: If your organisation provides AI-integrated services to regulated enterprises, or if your own AI deployments are significant enough to warrant formal external validation, commit to an ISO 42001 certification programme with a defined timeline. The competitive advantage of early certification will diminish as adoption becomes widespread — but the compliance infrastructure it builds will remain valuable indefinitely.

Execute: Building the operational capabilities each framework requires

• Implement DORA's mandatory contractual clauses in all ICT vendor agreements: Review every ICT vendor contract against DORA's Article 30 mandatory provisions list: service level objectives, audit rights, data location and portability obligations, business continuity requirements, and exit strategy documentation. Contracts missing these provisions must be renegotiated — which takes time and requires vendor cooperation. Start this process if not already completed.

• Deploy a unified GRC platform for multi-framework evidence management: Manual compliance management across three regulatory frameworks with overlapping requirements is not sustainable. A GRC (Governance, Risk, and Compliance) platform that maps evidence to multiple framework requirements, automates evidence collection, tracks control maturity, and generates supervisor-ready reporting is an operational necessity for organisations subject to DORA and NIS2 simultaneously.

• Build the AI technical documentation library: AI Act technical documentation for high-risk systems must describe the system's intended purpose, performance characteristics, training data and methodology, human oversight mechanisms, accuracy metrics, and risk management approach. For AI systems purchased from third parties, request this documentation from vendors now — the August 2026 deadline makes vendor documentation procurement a time-constrained activity.

• Implement AI literacy training at all levels: The AI Act's Article 4 AI literacy obligation — which entered application in February 2025 — requires that entities ensure sufficient AI literacy among their staff and other persons dealing with AI systems on their behalf. Implement a structured AI literacy programme covering the regulatory landscape, the organisation's AI governance policies, and the specific obligations applicable to employees whose roles involve AI system operation or oversight.

Control: Ongoing governance in a dynamic regulatory environment

• Establish a regulatory monitoring function: The Digital Omnibus, the GPAI Code of Practice updates, the harmonised standards being developed by CEN/CENELEC, and the national AI Act implementation guidance from member states will all materially affect compliance obligations over the next 12 to 24 months. Assign specific responsibility for monitoring these developments, translating them into compliance impacts, and updating the governance programme accordingly.

• Conduct quarterly regulatory evidence reviews: Create a quarterly cycle that reviews: DORA incident classification log completeness, NIS2 supply chain security assessment currency, AI Act technical documentation status for new or modified AI deployments, and board training completion records. These reviews generate the evidence base that supervisors will request and demonstrate continuous compliance rather than point-in-time compliance.

• Test regulatory resilience scenarios: Conduct tabletop exercises that simulate the scenarios regulators will test: a major ICT incident requiring DORA notification within 4 hours; an NIS2-covered cybersecurity incident affecting supply chain operations; an AI system producing discriminatory outputs triggering AI Act serious incident reporting. The organisations that have rehearsed these scenarios will respond more effectively — and demonstrate better governance to supervisors — than those experiencing them for the first time in a real event.

• Report regulatory governance status to the board quarterly: Create a board reporting pack for the unified DORA/NIS2/AI Act governance programme that covers: overall compliance posture, open remediation items and timelines, upcoming regulatory milestones (August 2026 AI Act deadline, TLPT cycle dates, vendor contract renewal reviews), and any material regulatory developments. This reporting closes the board accountability loop that NIS2 and DORA both require.

Conclusion: Regulation Is the Architecture

The regulatory signal from the 2025–2026 Clateway feed points to a governance reality that the most effective IT leaders in European enterprises have already internalised: DORA, NIS2, and the EU AI Act are not compliance exercises that happen after technology decisions are made. They are design constraints that must inform technology decisions from the beginning.

The organisations that treat these frameworks as architectural inputs — governing how systems are built, how vendors are selected, how AI is deployed, and how risks are managed — will find that compliance is largely achieved as a by-product of good operational practice. The organisations that treat them as compliance burdens to be managed separately from the business will find that the compliance cost is high, the evidence base is thin, and the supervisory relationship is adversarial rather than cooperative.

The regulatory landscape will not simplify. The Digital Omnibus will create some harmonisation. Harmonised standards will eventually provide more specific technical guidance. But the fundamental obligation — to demonstrate that your organisation governs its technology risks, cybersecurity posture, and AI deployments with rigour and accountability — is permanent. The frameworks document the expectation. The architecture delivers it.

Five months to August 2, 2026. The most consequential AI governance deadline in European business history is not a future event. It is the current working constraint for every IT leader in an organisation that deploys AI in high-risk categories. The question is whether your governance infrastructure will be ready to demonstrate compliance — or ready to explain why it is not.

Regulation as architecture: build it in, not on.

Key Data Points Referenced in This Article

DORA: Entered full application 17 January 2025. Covers 20 categories of financial entities. Penalties: up to 2% of global annual turnover for financial entities; up to €5M per day for critical ICT third-party providers. 4-hour initial incident notification window for major ICT incidents. Registers of information due to national authorities by 30 April 2025. CTPP designation process launched 2025.

NIS2: Transposition deadline October 17, 2024. Covers 18 sectors, essential and important entities. Board members personally liable for cybersecurity failures. 24-hour early warning requirement for significant incidents. Article 21 supply chain security includes vendor security assessment obligations. Management body must complete cybersecurity and AI training.

EU AI Act: Prohibited practices: enforceable from 2 February 2025. GPAI obligations and EU AI Office: operational from 2 August 2025. GPAI penalty regime: live from 2 August 2025 (up to €35M or 7%, or €15M or 3%). High-risk Annex III compliance deadline: 2 August 2026. High-risk in regulated products: 2 August 2027. Digital Omnibus proposed extension to December 2027 for Annex III — not yet law.

Standards: ISO 42001 (2023): certifiable AI Management System standard, 38 controls, 9 objectives. 76% of organisations plan to pursue it (CSA 2025). GitLab certified September 2025. CSA STAR for AI launched October 2025. AICM (CSA): published July 2025, 2026 CSO Awards winner. NIST CAISI: launched December 2025. AIUC-1: new agentic AI governance standard, emerging 2025-2026.

Governance signal: Governance maturity is the strongest predictor of AI readiness (CSA/Google Cloud, December 2025). Google Cloud acknowledged DORA CTPP status November 2025. Microsoft named Leader in IDC MarketScape for Unified AI Governance Platforms January 2026. Digital Omnibus proposal November 2025: single incident reporting point, aligned notification timelines.

About Clateway

Clateway is a fractional executive leadership practice serving IT leaders across regulated industries in Europe. Through the RCEC methodology — Research, Commit, Execute, Control — Clateway helps organisations make better technology decisions, faster. This article is Part 5 of the Clateway Insights Trend Report 2025–2026, based on 5,000 news signals in the Clateway Media feed from April 2025 to March 2026. For advisory engagements, executive roundtables, or the Clateway Academy fractional leadership programme, visit www.clateway.com.

Topics: Regulation, NIS2, DORA, AI Act

How Clateway can help

• GRC and compliance software with AI – AI-powered GRC software: generate ISO 27001, NIS2, DORA and GDPR policies, run your Statement of Applicability, controls, audit findings and management review…
• NIS2 compliance and readiness – Get NIS2 compliant: readiness assessment, AI-generated NIS2 policies, risk register, supplier security, incident management and board reporting in one platform.
• Technology and cyber board advisory – Independent technology and cyber expertise for boards and supervisory boards: advice on management's plans, NIS2 accountability, AI governance and director…