# Clateway – full text > The full text of Clateway's service, solution and glossary pages and its 18 newest articles. Summary and links: https://clateway.com/llms.txt # Services and solutions ## Fractional CIO services URL: https://clateway.com/services/fractional-cio A fractional CIO is an experienced Chief Information Officer who joins your leadership team part time, typically one to three days a week. You get the strategic judgement of a seasoned technology executive without the cost of a full-time hire. Clateway fractional CIOs own technology strategy, the roadmap and the IT budget, take control of suppliers and contracts, and bring security and compliance up to what customers, auditors and regulators expect. Every engagement runs on the Clateway Insights platform, so the board can see progress, risks and decisions at any time. ### When a fractional CIO is the right choice - IT is outsourced or run by a manager, and the organisation now needs a strategic technology function - You need senior technology leadership, but not five days a week - The board asks for a technology strategy, a cyber risk picture or NIS2 / DORA readiness - IT spend is growing without a clear view of what it delivers - You are preparing to hire a permanent CIO and want the role defined first ### What your fractional CIO delivers - Technology and cyber baseline with maturity scores - Technology strategy and a multi-year IT roadmap - IT budget and investment plan, planned versus actual - Supplier and contract control, including exit plans for critical vendors - Risk register covering cyber, suppliers and delivery - Compliance status for NIS2, DORA, GDPR and ISO 27001 - A monthly board report on progress, risk and compliance ### How an engagement works We start with interviews and a baseline of technology, cyber, suppliers, spend and organisation. Priorities, roadmap, budget and risks are agreed with the board, every commitment with a named owner. Then quick wins, governance rhythm, key hires and supplier decisions follow, with progress visible to everyone. When the time comes, your fractional CIO hands over cleanly to a permanent successor. **What is a fractional CIO?** A fractional CIO is a senior Chief Information Officer who works for your organisation part time, usually one to three days a week, with the same mandate as a full-time CIO: strategy, budget, suppliers, security and the IT organisation. **How much does a fractional CIO cost compared with a full-time CIO?** You pay only for the days you need. For most mid-sized organisations a fractional CIO costs a fraction of a full-time executive salary, bonus and benefits, while bringing broader experience from several organisations and sectors. **What is the difference between a fractional CIO and an interim CIO?** A fractional CIO works part time over a longer period to build and run the technology function. An interim CIO works full time for a defined period to fill a sudden gap or lead a critical change such as a merger, carve-out or turnaround. **Can a fractional CIO help with NIS2 and DORA compliance?** Yes. Clateway fractional CIOs establish the governance, risk register, supplier oversight and reporting that NIS2 and DORA require, and track compliance in the Clateway Insights platform so the board has evidence that stands up to auditors and regulators. --- ## Interim CIO URL: https://clateway.com/services/interim-cio When your CIO leaves suddenly, a merger or carve-out is under way, or a critical programme is off track, you need an experienced leader in seat now. A Clateway interim CIO takes the full mandate from day one. Our interim CIOs stabilise the organisation, take the decisions that were waiting, restore stakeholder confidence and deliver. They also lead the search for and handover to your permanent successor. ### Typical interim CIO assignments - Vacancy cover after the sudden departure of a CIO or IT director - Mergers, acquisitions, carve-outs and post-merger IT integration - Turnaround of a programme, ERP implementation or transformation that is off track - Rapid response to a major cyber incident or failed audit - Preparing the organisation and the role for a permanent CIO ### The first 100 days - Week 1–2: interviews, baseline of technology, cyber, suppliers, spend and organisation - Week 3–6: priorities, roadmap, budget and risk register agreed with the board - Week 6–12: quick wins, governance rhythm, key hires and supplier decisions - Monthly: board report on progress, risk and compliance **How quickly can an interim CIO start?** Clateway can usually propose experienced interim CIO candidates within days and have a leader in seat at short notice, depending on the scope and location. **How long does an interim CIO assignment last?** Most interim CIO assignments run three to twelve months: long enough to stabilise, deliver the critical change and hand over to a permanent CIO. **Does the interim CIO help hire the permanent CIO?** Yes. Defining the role, supporting the search and running a clean handover to the permanent successor is part of every Clateway interim engagement. --- ## Fractional CTO services URL: https://clateway.com/services/fractional-cto Your company has outgrown its first tech lead, or has never had a senior technology executive. A fractional CTO gives you an experienced Chief Technology Officer part time, to make the architecture, platform and hiring decisions that determine how far you can scale. Clateway fractional CTOs work with founders, CEOs and investors on technology strategy, engineering organisation, security and the technology story for your board and investors. ### What a fractional CTO takes on - Architecture and platform choices that scale - Engineering organisation, hiring and delivery rhythm - Security baseline and secure software development - Build versus buy decisions and vendor selection - Investor and board-ready technology story, including due diligence preparation ### Who we work with Scale-ups after a funding round, growth companies building their first platform, private-equity portfolio companies and SMEs that depend on software but do not need a full-time CTO yet. **What does a fractional CTO do?** A fractional CTO is a part-time Chief Technology Officer who owns technology strategy, architecture, engineering leadership and the technology roadmap, typically one to three days a week. **When should a start-up or scale-up hire a fractional CTO?** When technical decisions start to limit growth, when investors ask for a credible technology plan, or when the team has outgrown its first tech lead but a full-time CTO is not yet justified. **Can a fractional CTO prepare us for technical due diligence?** Yes. Clateway fractional CTOs prepare the architecture overview, security posture, technical debt assessment and roadmap that investors and acquirers look for. --- ## Interim CTO URL: https://clateway.com/services/interim-cto There is a gap to fill or a critical change to lead, now. A Clateway interim CTO joins with a full mandate to lead engineering and technology through a vacancy, a platform rebuild, a merger, a carve-out or a turnaround. Our interim CTOs stabilise teams and delivery, take the architecture and supplier decisions that cannot wait, and prepare the organisation for its permanent technology leader. ### Typical interim CTO assignments - Leading engineering after the sudden departure of a CTO - Rescuing a platform rebuild or product programme that is off track - Technology integration after an acquisition, or separation in a carve-out - Interim leadership in private-equity portfolio companies and exit readiness - Search and handover to the permanent CTO **What is the difference between an interim CTO and a fractional CTO?** An interim CTO works full time for a defined period to fill a gap or lead a critical change. A fractional CTO works part time over a longer period. **How long does an interim CTO stay?** Usually three to twelve months, until the critical change is delivered and a permanent CTO has taken over. --- ## Technology and cyber due diligence URL: https://clateway.com/services/technology-due-diligence Before you invest, acquire or merge, you need an independent, fact-based view of the technology you are buying. Clateway technology due diligence looks at architecture, technical debt, cybersecurity, suppliers, IT spend and the team, and turns the findings into risks, costs and a value-creation plan. We work for private-equity and venture investors, corporate acquirers and boards, from a quick red-flag review to a full technology and cyber due diligence, and we stay on afterwards for the 100-day plan if you want us to. ### What we assess - Architecture, scalability and technical debt - Cybersecurity posture, vulnerabilities and incident history - Compliance with NIS2, DORA, GDPR, ISO 27001 and the Cyber Resilience Act - Critical suppliers, contracts, licences and exit options - IT spend and the investment needed after closing - Technology organisation, key people and delivery capability ### What you get - Red flags and deal breakers, early - A risk register with cost estimates for the investment case - Input for the SPA, warranties and price discussion - A 100-day plan and value-creation levers from technology **What is technology due diligence?** Technology due diligence is an independent assessment of a target company's technology, software, security, suppliers and technology organisation before an investment or acquisition, to find risks and costs that affect the deal. **How long does a technology due diligence take?** A red-flag review can be done in one to two weeks; a full technology and cyber due diligence typically takes two to four weeks, depending on the size of the target and access to information. **Do you also support after the deal closes?** Yes. Clateway can provide interim leadership in portfolio companies, a 100-day plan and exit readiness work after closing. --- ## Technology and cyber board advisory URL: https://clateway.com/services/technology-board-advisory Directors carry responsibility for digital and cyber risk. Under NIS2, management is personally accountable. Yet many boards and supervisory boards do not have a technology background at the table. A Clateway board advisor brings independent technology and cyber expertise to your board: an independent view on management's technology plans, the right questions for the audit and risk committee, and briefings on cyber, AI and regulation. ### Who it is for - Supervisory boards and non-executive directors - Newly formed boards, first independent directors, boards after a funding round or ahead of a listing - Audit and risk committees that oversee cyber and IT risk ### Questions every board should be able to answer - What are our five biggest technology and cyber risks, and who owns each one? - If we were hit by ransomware tomorrow, how long would we be down, and have we tested it? - Which obligations under NIS2, DORA or the Cyber Resilience Act apply to us, and are we ready? - Which suppliers could stop our business, and what is our exit plan? - Is our technology spend going to the right things, and how does it compare? - Where should we use AI, and how do we keep it under control? **Why does a board need a technology advisor?** Cyber, AI and digital regulation are now board-level risks. A technology advisor helps directors challenge management's plans, meet their NIS2 and DORA obligations and make informed decisions about technology investment. **Does NIS2 make board members accountable for cybersecurity?** Yes. NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures, to follow training, and it allows them to be held liable for infringements. --- ## CIO roundtables and CxO peer networking URL: https://clateway.com/services/cio-roundtables Clateway runs a programme of private thought-leadership sessions that connects CIOs, CTOs, CISOs and digital leaders across the globe. Conversations to contribute to rather than presentations to sit through. Every session is invite-only and peer-to-peer: virtual boardroom sessions that are easy to join from anywhere, Inside DX Talks with leaders who are driving digital transformation in their own organisations, and in-person executive roundtables to meet your peers face to face. ### Session formats - Virtual boardroom sessions: invite-only online roundtables for CIOs and digital leaders - Inside DX Talks: leaders share how they run digital transformation in their own organisation - In-person executive roundtables, such as our Executive Roundtable in Milan ### Topics technology leaders bring to the table - AI strategy, generative AI and AI governance - Cybersecurity, ransomware resilience and NIS2 - Cloud, architecture and platform modernisation - Vendor management and IT spend - Leadership, operating models and talent **Who can join a Clateway roundtable?** Sessions are invite-only for CIOs, CTOs, CISOs, CDOs and other senior technology and digital leaders. You can express interest on any event page and we will review your request. **Are the roundtables sales events?** No. Sessions are peer-to-peer conversations between technology leaders: conversations to contribute to, not vendor presentations. **Are there CISO roundtables as well?** Yes. Many sessions focus on cybersecurity, resilience and regulation and are joined by CISOs alongside CIOs and CTOs. --- ## GRC and compliance software with AI URL: https://clateway.com/solutions/grc-compliance-software Clateway Insights GRC brings governance, risk and compliance into one workspace. Pick your frameworks, answer a short questionnaire about your organisation, and the AI drafts the complete documentation set: policies, procedures and registers that use your own roles, systems and suppliers. From there you run compliance as a process: the Statement of Applicability, implementation controls, execution tasks, evidence, audit findings and the management review, with verification of every document against the regulation's articles. ### Frameworks supported - ISO 27001:2022 and ISO 27002 - NIS2 - DORA - GDPR - EU Cyber Resilience Act - and other control frameworks and regulations ### What you can do - Generate compliance documents with AI, one section at a time with a consistent document spine - Verify existing documents against regulation articles and see the gaps - Statement of Applicability with justifications and links to risks - Implementation controls, execution tasks and evidence uploads - Audit findings, nonconformities and corrective actions - Management review with risk and audit summaries - Document library with versions, signing and sharing **What is GRC software?** Governance, risk and compliance (GRC) software helps organisations manage policies, risks, controls and audits against frameworks such as ISO 27001, NIS2, DORA and GDPR in one system instead of spreadsheets and documents. **Can AI write ISO 27001 policies?** Clateway Insights drafts ISO 27001 policies and procedures with AI using your organisation's context, roles and systems. Your team reviews, edits and approves every document before it is used. **Is my data used to train AI models?** No. Clateway routes AI requests through zero-data-retention providers or private deployments, and sensitive data can be kept on a private Azure OpenAI deployment. --- ## ISO 27001 risk register and risk assessment URL: https://clateway.com/solutions/iso-27001-risk-register The Clateway risk register follows ISO 27001 clauses 6.1.2, 6.1.3, 8.2 and 8.3. You set your own method (3×3, 4×4 or 5×5 scale, impact dimensions, score bands and risk appetite), and every risk gets an inherent and residual score, an owner, controls and a treatment plan. Instead of starting from a blank sheet, the platform suggests risks from your own data: systems, data sources, business processes, core vendors, known-exploited vulnerabilities and audit findings. Each suggestion comes with scenario, scores, Annex A controls and treatment actions. ### Features - Inherent and residual heat maps with click-to-filter - Risk appetite, score bands and review intervals per level - Treatment plans with actions that become tasks - Formal risk acceptance with justification, end date and role checks - Links to the Statement of Applicability and audit findings - Immutable history of every change - Word risk assessment report, risk treatment plan and Excel export - Import from CSV or Excel **What should an ISO 27001 risk register contain?** For each risk: the asset or process, threat, vulnerability and consequence, owner, likelihood and impact before and after controls, the controls applied, the treatment decision and the review date. Clateway records all of these and keeps the history. **Can I import my existing risk register from Excel?** Yes. Upload a CSV or Excel file, map the columns once and the register imports or updates risks by reference. --- ## NIS2 compliance and readiness URL: https://clateway.com/solutions/nis2-compliance The NIS2 Directive raises cybersecurity obligations for essential and important entities across the EU, and holds management personally accountable. Clateway Insights helps you find out what applies, close the gaps and prove it. Start with a NIS2 readiness assessment, generate the policies and procedures with AI, manage cyber risks and suppliers, run incident management, and give your board the reporting NIS2 expects. ### How Clateway covers NIS2 Article 21 measures - Risk analysis and information security policies: risk register and AI-generated policies - Incident handling: tickets and major incident management with SLAs - Business continuity and crisis management documentation - Supply chain security: vendor risk management, breaches and fourth parties - Vulnerability handling and disclosure: CVE scanning, EPSS and KEV prioritisation - Cyber hygiene, training and effectiveness assessments - Management oversight: board reporting and decision ledger **Who must comply with NIS2?** Medium and large organisations in the sectors listed in Annexes I and II of the directive, such as energy, transport, banking, health, digital infrastructure, ICT service management, manufacturing and digital providers, plus some smaller entities designated by member states. **What are the NIS2 incident reporting deadlines?** An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. **Can Clateway also provide a fractional CIO or CISO for NIS2?** Yes. Clateway Executive Services can provide a fractional CIO or board advisor to lead your NIS2 programme. --- ## DORA compliance for financial entities URL: https://clateway.com/solutions/dora-compliance The Digital Operational Resilience Act (DORA) applies to banks, insurers, investment firms, payment institutions and their critical ICT providers since January 2025. Clateway Insights supports the five DORA pillars in one platform. ### The five DORA pillars in Clateway - ICT risk management: risk register, policies and controls generated and tracked - ICT-related incident management and reporting: tickets, major incidents and SLAs - Digital operational resilience testing: plans, findings and evidence - ICT third-party risk: vendor registry, contract lifecycle, exit plans and fourth parties - Information sharing: threat intelligence and vendor security advisories **When did DORA apply?** DORA has applied since 17 January 2025 to financial entities in the EU and to the ICT third-party service providers that serve them. **What is the DORA register of information?** A register of all contractual arrangements with ICT third-party service providers, which financial entities must maintain and provide to their competent authority. --- ## EU Cyber Resilience Act compliance URL: https://clateway.com/solutions/cyber-resilience-act-compliance The EU Cyber Resilience Act (CRA) sets cybersecurity requirements for products with digital elements placed on the EU market, with vulnerability reporting obligations from September 2026 and full application from December 2027. Clateway Product Security gives manufacturers one place for the CRA evidence: every product and version, its software bill of materials, matched security advisories, threats and mitigations, pen tests, conformity documents and the requirement checklist. ### Features - Product and version registry with EU market placement dates - CycloneDX SBOM import with quality scoring and comparison - CSAF advisory feeds matched against your components - AI threat modelling from the SBOM with MITRE ATT&CK techniques - Pen test reports and conformity documentation - CRA requirement checklist and evidence bundle **When does the Cyber Resilience Act apply?** The CRA entered into force in December 2024. Reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026, and the main obligations from 11 December 2027. **Does the CRA require an SBOM?** Yes. Manufacturers must identify and document the components of their products, including by drawing up a software bill of materials in a commonly used, machine-readable format. --- ## Vulnerability management URL: https://clateway.com/solutions/vulnerability-management Clateway scans the technologies and versions in your architecture against the NVD and tells you which CVEs matter: exploit probability from EPSS, known exploitation from CISA KEV, MITRE ATT&CK mapping and the criticality of the affected system. SaaS platforms are patched by their vendor, so instead of noise Clateway watches their security bulletins and tells you which advisories need action, which need verifying and which the vendor already fixed. ### Features - CVE scanning by technology and installed version (CPE matching) - Prioritisation with CVSS, EPSS, CISA KEV and system criticality - SLA targets per severity with compliance reporting - Scheduled scans with e-mail notifications - GitHub Dependabot alert sync - SaaS vendor advisory watch with AI triage - CVE news and AI news summaries per vulnerability - Incidents raised in Clateway Tickets or ServiceNow **What is EPSS?** The Exploit Prediction Scoring System (EPSS) from FIRST estimates the probability that a vulnerability will be exploited in the next 30 days, which helps you fix the CVEs that attackers actually use first. **How is this different from a network vulnerability scanner?** Clateway works from your architecture: the systems, technologies and versions you run. It needs no agents or network access, and links every CVE to an owner, a system and a business criticality. --- ## Vendor and third-party risk management URL: https://clateway.com/solutions/third-party-risk-management Your suppliers are part of your attack surface and your resilience. Clateway brings every vendor into one registry with a risk score built from criticality, breaches, adverse media, fourth parties and contract status. Contract lifecycle management tells you when notice periods start, and the Vendor & Solution Marketplace helps you compare alternatives when it is time to switch. ### Features - Vendor registry linked to the systems that depend on each vendor - Weighted risk overview: criticality, breaches, adverse media, fourth parties, contract - Breach history and adverse media monitoring - Fourth-party visibility - Contract lifecycle with notice periods, auto-renewal and SLAs - Alerts for renewals and new risk events - Supports NIS2 supply chain security and the DORA register of information **What is third-party risk management?** Third-party risk management (TPRM) is the process of identifying, assessing and monitoring the risks that suppliers, service providers and their own suppliers pose to your organisation. --- ## IT vendor selection and software comparison URL: https://clateway.com/solutions/vendor-selection Choosing the right technology vendor is one of the most expensive decisions a CIO makes. The Clateway Vendor & Solution Marketplace lists technology vendors by category with their products, key features, strengths and weaknesses, alternatives and implementation partners, and reviews from technology leaders. Inside Clateway Insights you can go further: AI vendor analysis, side-by-side comparison, leadership and documentation research, and an assistant that answers questions about a vendor. ### How to use it - Browse vendors by category and shortlist - Compare features, strengths, weaknesses and certifications - Find implementation partners per vendor and country - Read reviews by technology leaders - Track the selected vendor in your vendor registry and contract lifecycle **Who writes the vendor reviews?** Reviews on the marketplace are written by Clateway members: technology leaders who use or have selected the vendor. --- ## Enterprise architecture and application portfolio management URL: https://clateway.com/solutions/enterprise-architecture-tool Clateway Architecture gives you a living picture of your landscape: every system with its owner, lifecycle, criticality, hosting, technologies and versions, integrations, business processes, data sources and cost. Because it is connected to security, vendors and budget, the same registry drives vulnerability scanning, vendor risk and planned-versus-actual spend per system. ### Features - System registry and application portfolio with lifecycle and criticality - Integrations with sign-in method, credential owner and rotation - Business processes with CIA ratings and AI suggestions - Data sources with classification and personal data flags - Architecture principles and diagrams - Technology versions and end-of-life tracking - Cost and planned budget per system - AI-generated architecture documents **What is an enterprise architecture tool?** An enterprise architecture (EA) tool documents an organisation's applications, technologies, data, processes and how they connect, so leaders can plan change, manage risk and control cost. --- ## IT strategy and portfolio planning URL: https://clateway.com/solutions/it-strategy-planning Strategy fails in execution. Clateway Strategy Builder connects the board's goals to OKRs, projects, epics and squads, with budgets, delivery signals and a decision ledger, so you can see from the boardroom to the backlog whether the strategy is on track. Squad backlogs sync live from Jira and Azure DevOps, weekly board signals show health per squad and project, and the Obeya room puts strategy, delivery and risk on one wall. ### Features - Goals, themes, OKRs, projects and epics - Squads, team members, allocation and burn rate - Budget with planned versus actual, purchase orders and cloud costs - Weekly board signals per squad and project - Jira and Azure DevOps backlog sync with sprints and velocity - Obeya visual management room and management meetings - Baseline capability assessments and reassessments - Roadmap builder and board presentations **Does Clateway replace Jira or Azure DevOps?** No. Clateway reads your Jira and Azure DevOps backlogs and shows progress, velocity and risk in the context of the strategy; teams keep working in their own tools. --- ## IT incident management and service desk URL: https://clateway.com/solutions/it-incident-management Clateway Tickets handles incidents and service requests with the discipline of an ITSM tool and the simplicity of a modern app: impact × urgency priorities, SLA clocks on business hours, major incidents with child incidents, and a branded self-service portal for your colleagues. Already on ServiceNow? Tickets sync both ways, so teams can work where they prefer. ### Features - Incidents and service requests with numbering, categories and resolution codes - Priority matrix and SLA policies with warnings and breaches - Major incident management with known issues on the portal - Self-service support portal on your own subdomain - Squads as assignment groups - Two-way ServiceNow sync - CVE incidents raised by AI agents after approval **Can Clateway Tickets replace ServiceNow?** For many mid-sized organisations, yes. Clateway Tickets covers incidents, requests, SLAs, major incidents and a self-service portal; organisations that keep ServiceNow can sync tickets both ways. --- ## AI agents for IT, security and compliance URL: https://clateway.com/solutions/ai-agents-for-it Clateway's AI workforce gives your team colleagues that never sleep: agents with a role, persona, skills and access to the sources you choose, such as repositories, backlogs, architecture, vulnerabilities, vendors, the risk register, documents and meetings. Agents work on request, on a schedule or when an event happens, and every change they propose, from a task to a ServiceNow incident or an e-mail, waits for a person's approval. Every data access is written to an immutable audit log. ### Ready-made agent roles - Information Security Officer and SOC Analyst - Red Team Tester and Vulnerability Incident Coordinator - Architecture Reviewer and Enterprise / Cloud Architect - Privacy Officer, Compliance Officer and Internal Auditor - Vendor & Contract Manager and FinOps analyst - Delivery Coach, PMO, Product Owner Assistant and Strategy Analyst - AI Governance and Business Continuity ### Governed by design - Actions need approval by a person - Agents only read what the person who gives the task may read - Immutable per-tool-call audit log - Private AI routing for personal and company data - Company kill switch and rate limits **Can AI agents change data without approval?** No. Agents propose actions; nothing changes until the person who gave the task, the agent's owner or a company admin approves it. --- ## AI governance for the enterprise URL: https://clateway.com/solutions/ai-governance Every AI request in Clateway passes one gateway that applies your company's rules: guardrails, private routing of sensitive data, zero-data-retention providers, rate limits and a company-wide AI switch, and every request is logged. That gives boards and CISOs the control they ask for, and teams the AI tools they want. ### Controls - Company guardrails with an AI wizard and a test chat - Privacy-aware routing: sensitive data to a private Azure OpenAI deployment - Bring your own AI provider keys - AI activity log per person and per company - Audit log of every AI agent data access - AI rate limits and a company kill switch **What is AI governance?** AI governance is the set of policies, controls and oversight that make sure an organisation uses AI lawfully, safely and in line with its values, including data protection, transparency, human oversight and accountability. --- ## Fractional CIO inhuren URL: https://clateway.com/nl/diensten/fractional-cio Een fractional CIO is een ervaren Chief Information Officer die parttime deel uitmaakt van uw directie, meestal één tot drie dagen per week. U krijgt het strategisch inzicht van een senior IT-bestuurder zonder de kosten van een fulltime aanstelling. Een fractional CIO van Clateway is eigenaar van de IT-strategie, de roadmap en het IT-budget, krijgt grip op leveranciers en contracten, en brengt informatiebeveiliging en compliance op het niveau dat klanten, auditors en toezichthouders verwachten. Elke opdracht loopt via het Clateway Insights-platform, zodat de directie en de raad van commissarissen voortgang, risico's en besluiten altijd kunnen zien. ### Wanneer een fractional CIO de juiste keuze is - IT is uitbesteed of wordt door een IT-manager geleid, en de organisatie heeft nu een strategische IT-functie nodig - U heeft senior IT-leiderschap nodig, maar niet vijf dagen per week - De directie of RvC vraagt om een IT-strategie, een beeld van de cyberrisico's of NIS2-gereedheid - De IT-kosten groeien zonder helder beeld van wat ze opleveren - U wilt eerst de rol scherp hebben voordat u een vaste CIO werft ### Wat uw fractional CIO oplevert - Nulmeting van technologie en cybersecurity met volwassenheidsscores - IT-strategie en een meerjarige roadmap - IT-budget en investeringsplan, gepland tegenover werkelijk - Grip op leveranciers en contracten, met exitplannen voor kritieke leveranciers - Risicoregister voor cyber, leveranciers en projecten - Compliancestatus voor NIS2, DORA, AVG en ISO 27001 - Een maandelijkse rapportage voor directie en RvC ### Hoe een opdracht verloopt We beginnen met gesprekken en een nulmeting van technologie, cyber, leveranciers, kosten en organisatie. Prioriteiten, roadmap, budget en risico's worden met de directie vastgesteld, elke afspraak met een benoemde eigenaar. Daarna volgen quick wins, een vast governance-ritme, sleutelaanstellingen en leveranciersbesluiten, met voortgang die voor iedereen zichtbaar is. Als het moment daar is, draagt uw fractional CIO zorgvuldig over aan een vaste opvolger. **Wat is een fractional CIO?** Een fractional CIO is een senior Chief Information Officer die parttime voor uw organisatie werkt, meestal één tot drie dagen per week, met hetzelfde mandaat als een fulltime CIO: strategie, budget, leveranciers, beveiliging en de IT-organisatie. **Wat is het verschil tussen een fractional CIO en een interim CIO?** Een fractional CIO werkt parttime en voor langere tijd om de IT-functie op te bouwen en te leiden. Een interim CIO werkt fulltime voor een afgebakende periode, bijvoorbeeld bij een plotselinge vacature, een fusie, een carve-out of een turnaround. **Kan een fractional CIO helpen met NIS2 en de Cyberbeveiligingswet?** Ja. Een fractional CIO van Clateway richt de governance, het risicoregister, het leveranciersbeheer en de rapportage in die NIS2 vraagt, en legt de compliance vast in Clateway Insights, zodat u bewijs heeft dat standhoudt bij auditors en toezichthouders. --- ## Interim CIO URL: https://clateway.com/nl/diensten/interim-cio Vertrekt uw CIO onverwacht, loopt er een fusie of carve-out, of ligt een kritiek programma uit koers? Dan heeft u nu een ervaren leider nodig. Een interim CIO van Clateway neemt vanaf dag één het volledige mandaat. Onze interim CIO's brengen rust in de organisatie, nemen de besluiten die bleven liggen, herstellen het vertrouwen van stakeholders en leveren resultaat. Ze begeleiden ook de werving van en de overdracht aan uw vaste opvolger. ### Typische interim-opdrachten - Waarnemen na het plotselinge vertrek van een CIO of IT-directeur - Fusies, overnames, carve-outs en IT-integratie na een overname - Turnaround van een programma, ERP-implementatie of transformatie die uit koers ligt - Snel ingrijpen na een groot cyberincident of een negatieve audit - De organisatie en de rol voorbereiden op een vaste CIO ### De eerste 100 dagen - Week 1–2: gesprekken en een nulmeting van technologie, cyber, leveranciers, kosten en organisatie - Week 3–6: prioriteiten, roadmap, budget en risicoregister vastgesteld met de directie - Week 6–12: quick wins, governance-ritme, sleutelaanstellingen en leveranciersbesluiten - Maandelijks: rapportage over voortgang, risico's en compliance **Hoe snel kan een interim CIO starten?** Clateway kan meestal binnen enkele dagen ervaren kandidaten voorstellen en op korte termijn een leider laten starten, afhankelijk van de opdracht en de locatie. **Hoe lang duurt een interim-opdracht?** De meeste opdrachten duren drie tot twaalf maanden: lang genoeg om te stabiliseren, de kritieke verandering te realiseren en over te dragen aan een vaste CIO. --- ## Fractional CTO URL: https://clateway.com/nl/diensten/fractional-cto Uw bedrijf is de eerste tech lead ontgroeid, of heeft nooit een senior technologiebestuurder gehad. Een fractional CTO geeft u parttime een ervaren Chief Technology Officer voor de architectuur-, platform- en wervingsbeslissingen die bepalen hoe ver u kunt groeien. Fractional CTO's van Clateway werken met oprichters, CEO's en investeerders aan technologiestrategie, de engineeringorganisatie, security en het technologieverhaal voor directie en investeerders. ### Waar een fractional CTO verantwoordelijk voor is - Architectuur- en platformkeuzes die meeschalen - Engineeringorganisatie, werving en opleverritme - Security-basis en veilige softwareontwikkeling - Make-or-buy-beslissingen en leverancierskeuze - Een technologieverhaal voor directie en investeerders, inclusief voorbereiding op due diligence **Wat doet een fractional CTO?** Een fractional CTO is een parttime Chief Technology Officer die eigenaar is van technologiestrategie, architectuur, engineeringleiderschap en de technologieroadmap, meestal één tot drie dagen per week. **Wanneer heeft een scale-up een fractional CTO nodig?** Als technische keuzes de groei gaan remmen, als investeerders om een geloofwaardig technologieplan vragen, of als het team de eerste tech lead is ontgroeid maar een fulltime CTO nog niet nodig is. --- ## Interim CTO URL: https://clateway.com/nl/diensten/interim-cto Er is een gat te vullen of een kritieke verandering te leiden, en wel nu. Een interim CTO van Clateway start met volledig mandaat om engineering en technologie te leiden tijdens een vacature, een herbouw van het platform, een overname, een carve-out of een turnaround. ### Typische opdrachten - Engineering leiden na het plotselinge vertrek van een CTO - Een platformherbouw of productprogramma dat uit koers ligt weer op de rails krijgen - Technologie-integratie na een overname of ontvlechting bij een carve-out - Interim-leiderschap in portfoliobedrijven van private equity en exit-gereedheid - Werving van en overdracht aan de vaste CTO **Wat is het verschil tussen een interim CTO en een fractional CTO?** Een interim CTO werkt fulltime voor een afgebakende periode om een gat te vullen of een kritieke verandering te leiden. Een fractional CTO werkt parttime en voor langere tijd. --- ## Technische en cyber due diligence URL: https://clateway.com/nl/diensten/technische-due-diligence Voordat u investeert, overneemt of fuseert, wilt u een onafhankelijk en feitelijk beeld van de technologie die u koopt. De technische due diligence van Clateway kijkt naar architectuur, technische schuld, cybersecurity, leveranciers, IT-kosten en het team, en vertaalt de bevindingen naar risico's, kosten en een plan voor waardecreatie. ### Wat we beoordelen - Architectuur, schaalbaarheid en technische schuld - Cybersecurity, kwetsbaarheden en incidenthistorie - Compliance met NIS2, DORA, AVG, ISO 27001 en de Cyber Resilience Act - Kritieke leveranciers, contracten, licenties en exitmogelijkheden - IT-kosten en de investeringen die na closing nodig zijn - Technologieorganisatie, sleutelpersonen en opleverkracht ### Wat u krijgt - Red flags en dealbreakers, vroeg in het proces - Een risicoregister met kostenramingen voor de investeringscase - Input voor de koopovereenkomst, garanties en prijsonderhandeling - Een 100-dagenplan en waardehefbomen uit technologie **Hoe lang duurt een technische due diligence?** Een red-flag review kan in één tot twee weken; een volledige technische en cyber due diligence duurt meestal twee tot vier weken, afhankelijk van de omvang van het doelbedrijf en de beschikbare informatie. --- ## Technologie- en cyberadvies voor bestuur en RvC URL: https://clateway.com/nl/diensten/technologie-advies-rvc Bestuurders zijn verantwoordelijk voor digitale en cyberrisico's. Onder NIS2 is het bestuur persoonlijk aanspreekbaar. Toch heeft lang niet elke raad van bestuur of raad van commissarissen technologische kennis aan tafel. Een adviseur van Clateway brengt onafhankelijke technologie- en cyberexpertise in uw bestuur: een onafhankelijke blik op de IT-plannen van het management, de juiste vragen voor de audit- en risicocommissie, en briefings over cyber, AI en regelgeving. ### Vragen die elk bestuur moet kunnen beantwoorden - Wat zijn onze vijf grootste technologie- en cyberrisico's, en wie is eigenaar van elk ervan? - Als we morgen getroffen worden door ransomware, hoe lang liggen we dan plat, en hebben we dat getest? - Welke verplichtingen uit NIS2, DORA of de Cyber Resilience Act gelden voor ons, en zijn we er klaar voor? - Welke leveranciers kunnen ons bedrijf stilleggen, en wat is ons exitplan? - Waar zetten we AI in, en hoe houden we dat onder controle? **Maakt NIS2 bestuurders aansprakelijk voor cybersecurity?** Ja. NIS2 verplicht het bestuur om maatregelen voor cyberrisicobeheer goed te keuren en erop toe te zien, om training te volgen, en maakt het mogelijk bestuurders aansprakelijk te stellen bij inbreuken. --- ## CIO-rondetafels en peer-netwerk URL: https://clateway.com/nl/diensten/cio-rondetafels Clateway organiseert besloten thought-leadershipsessies die CIO's, CTO's, CISO's en digitale leiders wereldwijd met elkaar verbinden. Gesprekken waar u aan bijdraagt, geen presentaties waar u naar luistert. Alle sessies zijn op uitnodiging en tussen vakgenoten: virtuele boardroomsessies die u overal kunt volgen, Inside DX Talks met leiders die de digitale transformatie in hun eigen organisatie leiden, en fysieke executive roundtables om vakgenoten persoonlijk te ontmoeten. ### Onderwerpen die op tafel komen - AI-strategie, generatieve AI en AI-governance - Cybersecurity, weerbaarheid tegen ransomware en NIS2 - Cloud, architectuur en modernisering - Leveranciersmanagement en IT-kosten - Leiderschap, operating models en talent **Wie kan deelnemen aan een rondetafel van Clateway?** De sessies zijn op uitnodiging voor CIO's, CTO's, CISO's, CDO's en andere senior technologie- en digitale leiders. Via elke eventpagina kunt u uw interesse aangeven. --- ## NIS2 compliance en gereedheid URL: https://clateway.com/nl/oplossingen/nis2-compliance De NIS2-richtlijn verhoogt de cybersecurityverplichtingen voor essentiële en belangrijke entiteiten in de hele EU en maakt het bestuur persoonlijk aanspreekbaar. In Nederland wordt NIS2 omgezet in de Cyberbeveiligingswet (Cbw), in België in de NIS2-wet. Clateway Insights helpt u bepalen wat voor u geldt, de gaten te dichten en dat aan te tonen. Begin met een NIS2-gereedheidsscan, laat beleid en procedures met AI opstellen, beheer cyberrisico's en leveranciers, voer incidentmanagement uit en geef uw bestuur de rapportage die NIS2 verwacht. ### Zo dekt Clateway de maatregelen van artikel 21 - Risicoanalyse en informatiebeveiligingsbeleid: risicoregister en beleid opgesteld met AI - Incidentafhandeling: tickets en major incident management met SLA's - Bedrijfscontinuïteit en crisisbeheer - Beveiliging van de toeleveringsketen: leveranciersrisico's, datalekken en vierde partijen - Kwetsbaarhedenbeheer: CVE-scans met EPSS- en KEV-prioritering - Cyberhygiëne, training en effectiviteitsmetingen - Bestuurlijk toezicht: bestuursrapportage en besluitenregister **Wat zijn de meldtermijnen onder NIS2?** Een vroegtijdige waarschuwing binnen 24 uur na kennisname van een significant incident, een incidentmelding binnen 72 uur en een eindrapport binnen een maand. **Valt mijn organisatie onder NIS2?** NIS2 geldt voor middelgrote en grote organisaties in de sectoren uit bijlage I en II van de richtlijn, zoals energie, vervoer, bankwezen, zorg, digitale infrastructuur, ICT-dienstbeheer, maakindustrie en digitale aanbieders, plus enkele kleinere organisaties die een lidstaat aanwijst. --- ## GRC- en compliancesoftware met AI URL: https://clateway.com/nl/oplossingen/grc-software Clateway Insights GRC brengt governance, risk en compliance samen in één werkomgeving. Kies uw normenkaders, beantwoord een korte vragenlijst over uw organisatie, en de AI stelt de volledige documentatie op: beleid, procedures en registers met uw eigen rollen, systemen en leveranciers. Daarna voert u compliance uit als proces: de Verklaring van Toepasselijkheid (SoA), maatregelen, taken, bewijs, auditbevindingen en de directiebeoordeling, met een toetsing van elk document aan de artikelen van de regelgeving. ### Ondersteunde normenkaders - ISO 27001:2022 en ISO 27002 - NIS2 en de Cyberbeveiligingswet - DORA - AVG (GDPR) - Cyber Resilience Act **Wordt mijn data gebruikt om AI-modellen te trainen?** Nee. Clateway stuurt AI-verzoeken via aanbieders zonder dataretentie of via private deployments, en gevoelige gegevens kunnen op een private Azure OpenAI-omgeving blijven. --- ## ISO 27001 risicoregister en risicoanalyse URL: https://clateway.com/nl/oplossingen/iso-27001-risicoregister Het risicoregister van Clateway volgt ISO 27001, hoofdstuk 6.1.2, 6.1.3, 8.2 en 8.3. U kiest uw eigen methode (schaal 3×3, 4×4 of 5×5, impactdimensies, scoregrenzen en risicobereidheid) en elk risico krijgt een bruto- en nettoscore, een eigenaar, maatregelen en een behandelplan. In plaats van met een leeg blad te beginnen, stelt het platform risico's voor op basis van uw eigen gegevens: systemen, databronnen, bedrijfsprocessen, kernleveranciers, actief misbruikte kwetsbaarheden en auditbevindingen. ### Functies - Heatmaps voor bruto- en nettorisico - Risicobereidheid en reviewtermijnen per niveau - Behandelplannen met acties die taken worden - Formele risicoacceptatie met onderbouwing en einddatum - Koppeling met de Verklaring van Toepasselijkheid en auditbevindingen - Word-rapportage, behandelplan en Excel-export - Import uit CSV of Excel **Kan ik mijn bestaande risicoregister uit Excel importeren?** Ja. Upload een CSV- of Excelbestand, koppel de kolommen één keer en het register importeert of werkt risico's bij op referentie. --- ## DORA compliance voor financiële instellingen URL: https://clateway.com/nl/oplossingen/dora-compliance De Digital Operational Resilience Act (DORA) geldt sinds 17 januari 2025 voor banken, verzekeraars, beleggingsondernemingen, betaalinstellingen en hun kritieke ICT-dienstverleners. Clateway Insights ondersteunt de vijf pijlers van DORA in één platform. ### De vijf pijlers van DORA in Clateway - ICT-risicobeheer: risicoregister, beleid en maatregelen - Beheer en melding van ICT-incidenten: tickets, major incidents en SLA's - Testen van digitale operationele weerbaarheid: plannen, bevindingen en bewijs - Risico's van ICT-derden: leveranciersregister, contractbeheer, exitplannen en vierde partijen - Informatie-uitwisseling: dreigingsinformatie en securityadviezen van leveranciers **Wat is het register van informatie onder DORA?** Een register van alle contractuele afspraken met ICT-dienstverleners, dat financiële entiteiten moeten bijhouden en aan hun toezichthouder moeten verstrekken. # Glossary ## What is NIS2? URL: https://clateway.com/glossary/nis2 NIS2 (Directive (EU) 2022/2555) is the EU law that sets cybersecurity risk-management and incident-reporting obligations for medium and large organisations in critical sectors, and makes their management bodies accountable for cybersecurity. NIS2 replaced the original NIS Directive and widened its scope considerably: it now covers essential and important entities in sectors such as energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, ICT service management, public administration, space, postal services, waste management, chemicals, food, manufacturing and digital providers. Member states had to transpose the directive into national law by 17 October 2024; the national laws set the supervisory authority, registration duties and fines. Fines can reach €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important entities. Core obligations: - Cybersecurity risk-management measures (Article 21): policies, incident handling, business continuity, supply chain security, secure development, vulnerability handling, cryptography, access control, training - Incident reporting (Article 23): early warning within 24 hours, notification within 72 hours, final report within one month - Management bodies approve and oversee the measures, follow training and can be held liable (Article 20) - Registration with the national authority ## What is DORA (Digital Operational Resilience Act)? URL: https://clateway.com/glossary/dora DORA (Regulation (EU) 2022/2554) is the EU regulation that requires financial entities to manage ICT risk, report major ICT incidents, test their digital operational resilience and control their ICT third-party providers; it has applied since 17 January 2025. DORA applies to banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and other financial entities, and brings critical ICT third-party providers, such as large cloud providers, under direct EU oversight. Because it is a regulation, DORA applies directly in every member state. Detailed rules are set in regulatory and implementing technical standards, for example on the ICT risk-management framework, incident classification and the register of information. The five pillars: - ICT risk management - ICT-related incident management, classification and reporting - Digital operational resilience testing, including threat-led penetration testing for significant entities - ICT third-party risk management and the register of information - Information and intelligence sharing ## What is the Cyber Resilience Act (CRA)? URL: https://clateway.com/glossary/cyber-resilience-act The Cyber Resilience Act (Regulation (EU) 2024/2847) sets mandatory cybersecurity requirements for hardware and software products with digital elements sold in the EU, covering their whole lifecycle from design to end of support. Manufacturers must design products to be secure, handle vulnerabilities for the support period, provide security updates, document the components of the product (including a software bill of materials) and carry out a conformity assessment before placing the product on the market with a CE marking. The CRA entered into force on 10 December 2024. Reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026, and the main obligations from 11 December 2027. ## What is the EU AI Act? URL: https://clateway.com/glossary/eu-ai-act The EU AI Act (Regulation (EU) 2024/1689) is the EU law that regulates artificial intelligence by risk: it bans unacceptable-risk practices, sets strict requirements for high-risk AI systems and adds transparency duties for certain AI, including general-purpose AI models. The AI Act entered into force on 1 August 2024 and applies in stages: the prohibitions and AI literacy duty from 2 February 2025, the rules for general-purpose AI models from 2 August 2025, and most other obligations from August 2026 onwards, with some high-risk deadlines later. Organisations that use AI (deployers) have duties too, for example human oversight, using high-risk systems according to their instructions and informing people when they interact with AI. ## What is the GDPR? URL: https://clateway.com/glossary/gdpr The GDPR (Regulation (EU) 2016/679) is the EU law that governs how organisations collect, use, store and protect personal data, and gives people rights over their data. It requires a lawful basis for every processing activity, data protection by design and by default, records of processing, data processing agreements with processors, security of processing, breach notification to the authority within 72 hours where required, and data protection impact assessments for high-risk processing. ## What is ISO 27001? URL: https://clateway.com/glossary/iso-27001 ISO/IEC 27001 is the international standard for an information security management system (ISMS): a risk-based way to manage information security that an organisation can be certified against. The 2022 edition has management system clauses 4 to 10 (context, leadership, planning including risk assessment and treatment, support, operation, performance evaluation and improvement) and Annex A with 93 controls in four themes: organisational, people, physical and technological. Certification requires a risk assessment, a risk treatment plan, a Statement of Applicability, internal audits and a management review, followed by an external certification audit. ## What is a Statement of Applicability (SoA)? URL: https://clateway.com/glossary/statement-of-applicability A Statement of Applicability is the ISO 27001 document that lists every Annex A control, states whether it is applied or excluded, gives the justification and records its implementation status. Clause 6.1.3 of ISO 27001 requires it. Auditors use the SoA to trace each control back to the risks it treats and forward to the evidence that it works, so a good SoA links controls to the risk register. ## What is a risk register? URL: https://clateway.com/glossary/risk-register A risk register is the record of an organisation's identified risks, with for each risk its owner, likelihood and impact, the controls in place, the treatment decision and the next review date. In information security a risk is usually described as a scenario: a threat that exploits a vulnerability of an asset, with a consequence. Scoring it before controls gives the inherent risk, after controls the residual risk, which is compared with the risk appetite to decide whether to mitigate, transfer, avoid or accept it. ## What is Risk appetite? URL: https://clateway.com/glossary/risk-appetite Risk appetite is the amount of risk an organisation is willing to accept in pursuit of its objectives, set by its board and used to decide which risks need treatment. In a risk register it is usually expressed as the highest acceptable residual score; risks above it need a treatment plan or a formal acceptance by someone with the authority to accept that level of risk. ## What is GRC (governance, risk and compliance)? URL: https://clateway.com/glossary/grc GRC (governance, risk and compliance) is the integrated way an organisation sets direction and accountability, manages its risks and meets its legal, regulatory and contractual obligations. GRC software replaces spreadsheets and scattered documents with one place for policies, risks, controls, evidence, audits and reporting across frameworks such as ISO 27001, NIS2, DORA and GDPR. ## What is third-party risk management (TPRM)? URL: https://clateway.com/glossary/third-party-risk-management Third-party risk management (TPRM) is the process of identifying, assessing, monitoring and reducing the risks that suppliers and service providers bring to an organisation, from cyber and data risks to operational and financial dependency. NIS2 (supply chain security) and DORA (ICT third-party risk) make it a legal requirement for many organisations. Good TPRM ties each supplier to the business services and systems that depend on it, so its criticality, contract, breaches and exit plan are clear. ## What is Fourth-party risk? URL: https://clateway.com/glossary/fourth-party-risk Fourth-party risk is the risk that comes from the suppliers of your suppliers: a failure or breach at a subcontractor of one of your vendors that affects your organisation. A common example is a cloud or software provider that many of your vendors rely on. DORA asks financial entities to understand such subcontracting chains for ICT services that support critical functions. ## What are CVE and CVSS? URL: https://clateway.com/glossary/cve A CVE (Common Vulnerabilities and Exposures) is the public identifier of a known security vulnerability, such as CVE-2021-44228, and CVSS is the 0–10 score that rates its technical severity. CVE identifiers are assigned by CVE Numbering Authorities and published in the CVE list; the US National Vulnerability Database (NVD) adds CVSS scores and the affected products as CPE names. CVSS measures severity, not likelihood, so it is best combined with exploit data such as EPSS and the CISA KEV catalogue. ## What is EPSS (Exploit Prediction Scoring System)? URL: https://clateway.com/glossary/epss EPSS (Exploit Prediction Scoring System) is a model from FIRST that estimates, for every published CVE, the probability that it will be exploited in the wild in the next 30 days. Only a small share of published vulnerabilities is ever exploited. Prioritising by EPSS together with CVSS and the business criticality of the affected system lets teams fix the vulnerabilities attackers actually use first. ## What is the CISA KEV catalogue? URL: https://clateway.com/glossary/cisa-kev The CISA Known Exploited Vulnerabilities (KEV) catalogue is the US Cybersecurity and Infrastructure Security Agency's list of vulnerabilities with evidence of active exploitation. US federal agencies must remediate KEV entries by set deadlines; many organisations elsewhere use the catalogue as a strong signal to fix a vulnerability first. ## What is an SBOM (software bill of materials)? URL: https://clateway.com/glossary/sbom An SBOM (software bill of materials) is a machine-readable list of all components, libraries and versions a piece of software is built from, used to find which products are affected by a vulnerability. Common formats are CycloneDX and SPDX. The Cyber Resilience Act requires manufacturers to draw up an SBOM for their products; matching SBOM components against security advisories and CVEs shows quickly where action is needed. ## What is CSAF (Common Security Advisory Framework)? URL: https://clateway.com/glossary/csaf CSAF (Common Security Advisory Framework) is the OASIS standard for publishing security advisories in a machine-readable JSON format, so tools can automatically tell which products and versions are affected. Vendors publish CSAF feeds with their advisories; CSAF VEX documents state whether a product is actually affected by a vulnerability in one of its components. ## What is a fractional CIO? URL: https://clateway.com/glossary/fractional-cio A fractional CIO is an experienced Chief Information Officer who works for an organisation part time, typically one to three days a week, with the full mandate for IT strategy, budget, suppliers, security and the IT organisation. Organisations choose a fractional CIO when they need senior technology leadership but not a full-time executive: a mid-sized company whose IT is outsourced, a growing organisation preparing its first CIO role, or a business facing NIS2, DORA or a major transformation. ## What is an interim CIO? URL: https://clateway.com/glossary/interim-cio An interim CIO is an experienced Chief Information Officer who joins full time for a defined period to fill a sudden vacancy or lead a critical change, such as a merger, carve-out, turnaround or recovery after an incident. Interim CIOs start at short notice, take decisions from day one and usually stay three to twelve months, handing over to a permanent successor. ## What is a fractional CTO? URL: https://clateway.com/glossary/fractional-cto A fractional CTO is a part-time Chief Technology Officer who owns technology strategy, architecture and engineering leadership for a company that does not yet need, or cannot yet justify, a full-time CTO. Scale-ups, start-ups after a funding round and private-equity portfolio companies are typical clients: the fractional CTO makes the architecture and hiring decisions that determine how far the platform can scale, and prepares the technology story for investors. ## What is an interim CTO? URL: https://clateway.com/glossary/interim-cto An interim CTO is an experienced Chief Technology Officer who leads engineering and technology full time for a defined period, for example during a vacancy, a platform rebuild, an acquisition or a carve-out. The interim CTO stabilises teams and delivery, takes the architecture and supplier decisions that cannot wait, and prepares the organisation for its permanent technology leader. ## What is Technology due diligence? URL: https://clateway.com/glossary/technology-due-diligence Technology due diligence is an independent assessment of a target company's technology, software, cybersecurity, suppliers and technology organisation before an investment or acquisition, to find the risks and costs that affect the deal. It typically covers architecture and scalability, technical debt, security posture and incidents, compliance, licences and critical contracts, IT spend and the team, and ends with red flags, cost estimates and a 100-day plan. ## What is Enterprise architecture? URL: https://clateway.com/glossary/enterprise-architecture Enterprise architecture is the discipline of documenting and designing how an organisation's business processes, data, applications and technology fit together, so that change can be planned and its risks and costs controlled. Application portfolio management is part of it: the register of all applications with their owner, lifecycle, criticality, cost and integrations, used to decide what to invest in, migrate or retire. ## What are OKRs (objectives and key results)? URL: https://clateway.com/glossary/okr OKR (objectives and key results) is a goal-setting method in which an objective describes what you want to achieve and two to five measurable key results describe how you will know you achieved it. In technology organisations OKRs connect the strategy to the work of squads and projects; progress on key results is reviewed regularly, often quarterly. ## What is an Obeya room? URL: https://clateway.com/glossary/obeya An Obeya (Japanese for 'big room') is a visual management space, physical or digital, where leaders see strategy, delivery, risks and decisions together on one wall and steer them in short, regular meetings. The method comes from the Toyota Production System. A digital Obeya keeps the panels live from the systems where the work happens, so meetings discuss decisions instead of collecting status. ## What is Major incident management? URL: https://clateway.com/glossary/major-incident-management Major incident management is the ITSM process for the highest-impact incidents: a dedicated manager and team, fast communication to stakeholders, child incidents linked to one major incident, and a review afterwards. Under NIS2 and DORA, significant or major incidents also have external reporting deadlines, so the process must classify incidents quickly and keep a timeline. ## What is AI governance? URL: https://clateway.com/glossary/ai-governance AI governance is the set of policies, roles, controls and oversight that make sure an organisation uses AI lawfully, safely, transparently and in line with its values. In practice it covers an inventory of AI use, risk assessment, data protection and confidentiality, guardrails, human oversight, logging and audit, vendor due diligence and compliance with the EU AI Act. # Articles ## Shadow AI Policy: A Vendor-Neutral Guide for CIOs That Actually Reduces Risk URL: https://clateway.com/articles/shadow-ai-policy Published: 2026-10-20 · Clateway Technology Council Key takeaways: A shadow AI policy that works: why bans fail, the five rules that matter, and a 90-day rollout CIOs can run without buying another tool. **Bottom line:** most employees already use AI tools their company has not approved, and bans do not stop them. A shadow AI policy works when it gives people a sanctioned, faster route, sets a short list of hard data rules, and measures usage instead of guessing. This guide gives CIOs a vendor-neutral structure and a 90-day rollout. #### What is shadow AI, and why does it need its own policy? Shadow AI is any AI tool, feature or model that staff use for work without IT, security or legal approval. That covers consumer chatbots on personal accounts, AI features switched on inside already-approved SaaS, browser extensions that read the screen, and, increasingly, AI agents that individuals connect to company data. It differs from classic shadow IT in one important way. An unapproved file-sharing app stores data somewhere you do not control. An AI tool processes the data, may keep it in logs or use it for training, and gives back output that ends up in contracts, code and customer emails. The risk is not only where data sits, but what happens to it next and who relies on the result. The numbers show this is now normal behaviour, not an edge case: FindingSource and date 66% of office professionals used AI tools at work they believed were not permitted; 34% entered customer data into public AI tools[PagerDuty Shadow AI Survey](https://www.pagerduty.com/newsroom/shadow-ai-workplace-survey-2026/), 1,250 respondents, June 2026 81% of employees and 88% of security leaders use unapproved AI tools; 45% of workers find workarounds to blocked apps[UpGuard, The State of Shadow AI](https://www.upguard.com/resources/the-state-of-shadow-ai), 1,500 respondents One in five breached organisations reported a breach due to shadow AI; high shadow AI use added USD 670,000 to average breach cost[IBM Cost of a Data Breach 2025](https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls), July 2025 Only 37% of organisations have policies to manage AI or detect shadow AI; of those with AI policies, 34% audit for unsanctioned AIIBM Cost of a Data Breach 2025 Only 38% of organisations have a formal, comprehensive AI policy[ISACA 2026 AI Pulse Poll](https://www.isaca.org/resources/ai-pulse-poll), 3,400+ professionals, May 2026 A generic acceptable use policy cannot answer the questions staff face every day: may I paste this customer email into a chatbot? Is the AI summary in our meeting tool allowed? Can I connect an agent to my mailbox? That is why the shadow AI policy has to be a separate, short and practical document. #### Why banning AI tools makes shadow AI worse The instinctive response is to block the big chatbot domains. The evidence says it mostly removes visibility. UpGuard found 45% of workers find workarounds to blocked applications, and PagerDuty found 77% of office professionals feel AI restrictions limit their career growth, with 75% likely to look for a job offering better AI skills development. There is also a fairness problem. In the same PagerDuty survey, 81% of respondents believe leadership operates under different AI rules than everyone else. A policy that executives ignore will not be followed by anyone else. The lesson for CIOs: treat shadow AI as unmet demand. Every unapproved tool is a requirement your sanctioned stack has not met yet. #### The five rules every shadow AI policy needs Most published templates run to ten or more sections and are written to sell a monitoring product. Staff will remember five rules. Put everything else in an appendix. ##### 1. Three tool tiers, published on one page - **Approved:** enterprise AI tools with a data processing agreement, no training on your data, SSO and logging. Use freely within the data rules. - **Allowed with limits:** tools approved for specific roles or data classes, for example a coding assistant for engineering only. - **Not allowed:** tools with no contract, unclear retention or training on user inputs. Keep the list live and searchable. A tier list that is updated quarterly is out of date in a month. ##### 2. A short list of data that never goes into unapproved AI Name the classes plainly: customer personal data, health data, credentials and secrets, source code, unreleased financial results, M&A and legal matters, and anything under a confidentiality agreement. Link each class to the reason ([GDPR](https://clateway.com/glossary/gdpr), contract, market rules) so the rule makes sense. ##### 3. A fast request route with a service level Give staff a simple form to request a new tool and commit to an answer, for example within ten working days. Without a deadline, the request route becomes another reason to use the tool anyway. ##### 4. Humans own the output AI output used in customer communication, code, contracts or decisions about people must be reviewed by a named person. This is the same principle we apply to agents in Human in the Loop for AI Agents: the riskier the action, the stronger the approval. ##### 5. Report without blame Make it easy to report a mistake, such as pasting the wrong file into a chatbot, and promise no penalty for prompt self-reporting. Early reports are what turn a possible breach into a minor incident. #### How to find shadow AI without buying another tool You already hold most of the data you need: - **Identity provider logs:** "Sign in with Google/Microsoft" consent grants to AI apps show who connected what. - **Expense and card data:** individual AI subscriptions are a reliable signal of unmet demand. - **Web proxy or DNS logs:** traffic to known AI domains gives volume by department. - **SaaS admin consoles:** check which embedded AI features are switched on by default in tools you already pay for. - **A short, anonymous survey:** ask what people use and why. The "why" tells you which approved tool to offer first. Dedicated discovery products can help at scale, but start with these sources. They answer the first board question, "how big is this?", within a few weeks. #### A 90-day shadow AI policy rollout PhaseDaysWhat happensOutput Discover1 to 30Pull the five data sources above, run the survey, list the top 10 tools by usageShadow AI baseline by department Offer and amnesty31 to 60Approve or replace the most used tools, publish the tier list and five rules, announce a no-penalty amnesty for disclosing current useApproved AI stack, published policy Enforce and measure61 to 90Block only the "not allowed" tier, start quarterly audits, report metrics to the boardFirst shadow AI dashboard Track four metrics: share of AI usage on approved tools, number of open tool requests and average decision time, data-rule incidents reported, and percentage of staff who completed AI literacy training. #### How the EU AI Act and GDPR connect to shadow AI For European organisations, shadow AI is also a compliance question. The [EU AI Act](https://clateway.com/glossary/eu-ai-act) requires deployers to take measures to support AI literacy among staff who use AI systems on their behalf ([Article 4](https://artificialintelligenceact.eu/article/4/), applicable since 2 February 2025, since amended). You cannot show literacy measures for tools you do not know exist. Under GDPR, personal data pasted into an unapproved AI service may mean a processor relationship with no contract, no record and no transfer assessment. A tier list with signed agreements is the simplest way to close that gap. For the agent side of the Act, see our guide to the EU AI Act and AI agents. #### Frequently asked questions ##### What should a shadow AI policy include? At minimum: scope (staff, contractors, personal devices), a three-tier tool list, the data classes that never go into unapproved AI, a request route with a deadline, human review of AI output, and a no-blame reporting route. Keep the core to one page. ##### Is shadow AI the same as shadow IT? No. Shadow IT is mainly about unapproved storage and access. Shadow AI adds processing, possible model training on your data and output that people rely on, so the policy must cover data inputs and use of the results. ##### Should we block ChatGPT and other public chatbots? Block only tools in your "not allowed" tier, and only after you offer an approved alternative. Blocking without an alternative pushes use to personal devices, where you have no visibility at all. ##### How do AI agents change shadow AI? Agents act, not only answer. An employee who connects an unapproved agent to email or a CRM gives it standing access to company data. Extend the tier list to agents and apply the controls in our AI agent governance framework. ##### Who should own the shadow AI policy? The CIO or CISO usually owns it, with legal, privacy and HR as co-signers. Ownership matters less than one named person who decides tool requests on time. #### Next steps for CIOs - Pull identity and expense data this month to size shadow AI in your organisation. - Publish a one-page tier list and the five rules before you block anything. - Fund the approved AI stack as a line item in your 2027 plan; our AI budget planning guide shows how to size it. - Report the four metrics to the board each quarter. Image alt text suggestions: "Shadow AI policy three-tier tool list: approved, allowed with limits, not allowed"; "90-day shadow AI policy rollout timeline for CIOs"; "Chart of employees using unapproved AI tools, 2025 to 2026 surveys". --- ## AI Agent Audit Trail: What to Log So You Can Explain Every Action URL: https://clateway.com/articles/ai-agent-audit-trail Published: 2026-10-20 · Clateway Technology Council Key takeaways: What an AI agent audit trail must capture to explain any action: identity, delegation, tool calls, approvals, retention and tamper-evidence. **Bottom line:** an AI agent audit trail must let you answer four questions about any action, months later: which agent did it, for whom, why, and who approved it? That takes more than application logs. You need one connected trace per task covering prompts, tool calls, data retrieved, identities and approvals. Store it tamper-evident, keep it for at least six months (longer where your regulator expects it), and protect it like the sensitive data it contains. #### Why agents need a different kind of audit trail Traditional audit logs record that a user changed a record. An agent gets there through a chain: it reads a ticket, retrieves three documents, calls a model twice, invokes two tools and then changes the record. If you only log the last step, you can't tell whether the agent did what it was asked or what a hidden instruction in one of those documents told it to do. The Cloud Security Alliance makes the point in its guide to [AI incident response](https://cloudsecurityalliance.org/blog/2026/08/14/when-the-playbook-breaks-ai-incident-response-for-systems-that-don-t-behave-like-anything-else) (14 August 2026): "there is no response without logging". Isolated events without correlation "risk obscuring the full causal chain of an attack". Agents are also non-deterministic. You can't re-run an incident and expect the same result, so forensics depend on **replaying the record**. The evidence that this gap is real: in CERT-In's advisory of 15 October 2026, none of the organisations whose systems were reached by AI agents had detected it ([The Hacker News, 16 October 2026](https://thehackernews.com/2026/10/cert-in-warns-ai-agents-accessed.html)). #### What an AI agent audit trail must capture | Field group | What to record | Why it matters | |---|---|---| | **Identity** | Agent ID and version, the human or system that delegated the task, the credential used | Attribution; see AI agent identity management | | **Intent** | The task or instruction received, its source and the autonomy level | Shows what the agent was supposed to do | | **Model calls** | Model and version, system prompt version, token counts, finish reason | Reproducibility, cost, drift | | **Retrieval** | Queries sent and document IDs returned | Shows what content could have steered the agent | | **Tool calls** | Tool name, arguments, result status, target system and records touched | The actual actions and their blast radius | | **Approvals** | Reviewer identity, timestamp, what they saw, decision | Proves human oversight worked; see human in the loop for AI agents | | **Guardrails** | Refusals, blocked actions, policy hits | Early warning of goal hijack attempts | | **Correlation** | Trace ID linking every step, parent and child agents | Rebuilds the full chain across agents | Okta's guidance on [least privilege for AI agents](https://www.okta.com/identity-101/how-to-implement-least-privilege-for-ai-agents/) adds one important point: each approval record should hold the reviewer's identity, the timestamp, the decision context and the agent's original request. Together these form a complete chain of custody. #### Use OpenTelemetry GenAI conventions as the backbone You don't have to invent a schema. The [OpenTelemetry semantic conventions for generative AI](https://opentelemetry.io/blog/2026/genai-observability/) (OpenTelemetry blog, 14 May 2026) define a standard trace shape. A top-level invoke_agent span has child chat spans for each model call and execute_tool spans for each tool call. Attributes such as gen_ai.request.model, gen_ai.usage.input_tokens and gen_ai.response.finish_reasons are standardised. Popular coding agents already emit this telemetry. Two caveats: - **Content capture is off by default.** By default only metadata is recorded. Prompts, tool arguments and results are captured only when you switch them on. Decide deliberately which agents need content capture for audit, and redact where you can. - **Observability is not an audit trail.** Traces built for debugging are often sampled, short-lived and editable. An audit trail must be complete for in-scope actions, tamper-evident and kept under a retention policy. Send the audit-relevant spans to a separate, append-only store. #### How long to keep AI agent logs - **[EU AI Act](https://clateway.com/glossary/eu-ai-act):** deployers of high-risk AI systems must keep the logs the system generates automatically for at least six months (Article 26(6)), and providers have matching duties under Articles 12 and 19. For Annex III uses this applies from 2 December 2027; see EU AI Act and AI agents. - **CERT-In (India):** keep API logs for at least 180 days, and keep a tamper-resistant log of agent actions, at least for actions touching production systems and data. - **Sector rules** (financial services, health, public sector) often require longer retention. Use the longest one that applies. #### Balancing the audit trail with privacy Agent prompts and retrieved documents often contain personal data, so a full audit trail is a personal-data store in its own right. CSA's advice: don't stop logging; treat interaction logs as **sensitive-data archives**. Apply strict access control, time-bound retention, and redaction or masking where you can. A log you can't legally keep is as useless in an investigation as one you never collected. Record the purpose and retention in your [GDPR](https://clateway.com/glossary/gdpr) records, and reuse that analysis in any AI Act impact assessment. #### Make the audit trail tamper-evident - Write audit events to append-only or write-once storage, separate from the agent's own runtime. - Never give the agent's identity permission to delete or edit its own logs. - Hash-chain or sign batches of events so gaps and edits can be seen. - Alert when logging stops. A silent agent is a finding in itself. #### Frequently asked questions ##### What is an AI agent audit trail? It is a complete, tamper-evident record of what an AI agent did, for whom and why. It covers the instruction, model calls, data retrieved, tool calls, approvals and results, all linked by one trace ID so the whole chain can be rebuilt later. ##### Do we need to log full prompts and responses? For high-impact agents, usually yes, because without content you can't prove whether an action came from the user or from injected text. For low-risk agents, metadata may be enough. Decide per autonomy level and redact personal data where possible. ##### How long should AI agent logs be kept? At least six months for high-risk systems under the EU AI Act, and at least 180 days for API logs under CERT-In guidance. Sector regulation may require more. Set retention per agent class and delete on schedule. ##### Is an observability platform enough for an AI agent audit trail? Not on its own. Observability tools are built for debugging and often sample or overwrite data. Use them to collect telemetry, then send audit-relevant events to an append-only store with access control and fixed retention. --- Part of Clateway's agent governance series. Next: AI agent incident response. --- ## Human in the Loop for AI Agents: Which Actions Need Approval URL: https://clateway.com/articles/human-in-the-loop-ai-agents Published: 2026-10-18 · Clateway Technology Council Key takeaways: Human in the loop for AI agents: the five actions that need approval and how to design approvals people actually review. **Bottom line:** "Human in the loop" is not a control until you can say which actions stop for a decision, who decides, and what evidence they see. Let AI agents read, analyse and prepare freely; put an independent approval in front of the five action types that move money, destroy data, change privileges, expose sensitive information or delegate authority. Then design the approval itself so a busy person can actually say no. This piece follows our AI agent governance framework, which sets controls by autonomy level. Here we zoom in on the one control every level relies on: the approval step. #### Why "human in the loop" is no longer specific enough A chatbot that gives a bad answer creates a problem you may still catch. An agent with credentials turns the same bad decision into an API call, a deleted resource or a payment before anyone notices. As a CIO.com contributor put it on 29 September 2026, the question is not whether there is a human in the loop but exactly where that human sits ([CIO.com, 2026-09-29](https://www.cio.com/article/4227762/5-things-i-would-never-let-an-ai-agent-do-without-a-second-approval.html)). The risk lists agree. The [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) (December 2025) names tool misuse (ASI02), identity and privilege abuse (ASI03) and human-agent trust exploitation (ASI09): people over-trusting what an agent tells them. That last one matters for approvals. An approval screen that repeats the agent's own summary is exactly where over-trust happens. Regulation points the same way, with a delay. Article 14 of the [EU AI Act](https://clateway.com/glossary/eu-ai-act) requires high-risk systems to let overseers understand the system, stay aware of automation bias, override its output and stop it safely ([AI Act, Art. 14](https://artificialintelligenceact.eu/article/14/)). The Digital Omnibus (Regulation 2026/1744, in force since 27 July 2026) moved those high-risk duties to 2 December 2027 for Annex III uses and 2 August 2028 for Annex I products ([ActuIA, 2026-10-06](https://www.actuia.com/en/news/ai-act-obligations-in-force-and-delays-under-omnibus-2026-1744/)). Brookings notes that for about the next 16 months, the controls on agents in high-stakes areas will be organisational rather than statutory ([Brookings, 2026-10-12](https://www.brookings.edu/articles/shaping-global-governance-of-ai-agents/)). So the approval design is up to you, for now. #### The five actions that always need a second decision Let agents search, summarise, correlate, recommend and prepare. Stop them, every time, before these five: | Action | Example | What the approver must see | |---|---|---| | **Move money** | Pay a supplier invoice | Amount → recipient → source account → the instruction that triggered it | | **Delete or overwrite production data** | "Clean up stale resources" | The exact items, their dependencies, the blast radius, whether it can be undone | | **Change privileges** | Add a role, rotate a credential, edit a policy | Who gets what access, for how long, and who asked | | **Expose sensitive information** | Email an attachment, fill a vendor ticket | What data, its classification, the recipient, the destination system | | **Create or delegate authority** | Hand a task to another agent with broader credentials | The authority passed on, to whom, for how long, and whether it can be passed again | These categories come from the CIO.com analysis above and map directly onto OWASP ASI02, ASI03 and ASI07. The rule behind them is old: **the party that prepares a consequential action must not be the party that releases it.** Finance calls it segregation of duties. For agents it means one agent must never propose an action, get the access to perform it, approve that access and then carry it out. That isn't autonomy. It's self-authorisation. #### Design the approval, not just the checkpoint Most failed human-in-the-loop controls don't fail because the checkpoint is missing. They fail because the approver can't make a real decision. Four design rules fix that. ##### 1. Build the approval screen from the action, not from the agent's explanation If the agent writes the text the approver reads, "Send requested information to vendor" can hide something very different. Build the approval card from the actual tool call: destination, data classification, parameters, scope. Show the agent's reasoning next to that, never instead of it. ##### 2. Approve the specific action, never the workflow "Approve the payment workflow" can't be reviewed. "Pay €4,200 to supplier X from account Y because of invoice Z" can. Each approval should cover one concrete, bounded action with a short expiry. If the parameters change while the approval waits, cancel it and ask again. ##### 3. Put the limit outside the agent Agents "can misinterpret or work around embedded rules", according to the AWS Reimagine 2026 study of 154 executives at 128 organisations ([Help Net Security, 2026-09-28](https://www.helpnetsecurity.com/2026/09/28/ai-agent-security-governance-aws-report/)). The approval gate belongs in the tool layer, an authorisation service or a policy engine the agent can't change. Don't put it in the prompt. ##### 4. Budget for attention Every approval costs a person's attention. Ask too often and people click "approve" without reading. That is automation bias, the same risk Article 14(4)(b) warns about. Keep the stops for the five categories above, batch low-risk items into a daily review, and track approval metrics like any other control. #### A second approval doesn't always mean a second person Putting a person in front of every agent action would kill the value of automation. The second decision can also come from: - **A deterministic policy engine**, e.g. "payments over €1,000 to new beneficiaries are blocked", which the agent can't change. - **A transaction-control system** that already exists in finance or IAM. - **A person**, kept for actions that are irreversible, unusual or above a threshold. The AWS study recommends treating new agents "like probation for a new hire": start with human approval, widen autonomy only after the agent proves reliable, and keep the option to narrow it again ([Help Net Security, 2026-09-28](https://www.helpnetsecurity.com/2026/09/28/ai-agent-security-governance-aws-report/)). Brookings makes the same case for setting scope limits and the actions that need human intervention in advance, backed by traceable evidence ([Brookings, 2026-10-12](https://www.brookings.edu/articles/shaping-global-governance-of-ai-agents/)). #### How to measure whether your approvals work An approval control that nobody measures turns into a rubber stamp. Track four numbers per agent, every month: - **Approval rate**: share of requests approved. Close to 100% for months suggests rubber-stamping or a gate that can be relaxed. - **Median time to decision**: rising times mean too many requests or poor context on the approval card. - **Rejection reasons**: classified, so the agent's scope or prompts can be fixed. - **Bypass attempts**: actions blocked because they skipped the gate. Even one is worth investigating. Use these numbers to decide when an agent moves up or down an autonomy level in your governance framework. #### A 30-day starting plan - **Week 1:** List every agent and every tool it can call. Mark each tool against the five categories. - **Week 2:** Move approval gates for those tools out of prompts and into the tool or authorisation layer. - **Week 3:** Redesign the approval cards so they show the actual action: who, what, where, how much, whether it can be undone. - **Week 4:** Start the four metrics and set a quarterly review that can widen or narrow each agent's autonomy. #### Frequently asked questions ##### What does human in the loop mean for AI agents? It means a named person or an independent control must approve certain agent actions before they run. For agents, it should be defined per action type (payments, deletions, privilege changes, data sharing, delegation), not as a general promise of oversight. ##### Which AI agent actions should require human approval? At minimum: moving money, deleting or overwriting production data, changing access rights, sharing sensitive data outside a trust boundary, and creating or delegating privileged authority. Low-risk actions that are bounded, logged and reversible can usually run on their own. ##### Does the EU AI Act require human oversight of AI agents? Article 14 requires effective human oversight of high-risk AI systems, including the ability to override and stop them. After the Digital Omnibus, those duties apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I). Agents outside high-risk uses are not directly covered, but Article 14 is a sound design reference. ##### How do you avoid approval fatigue? Gate only consequential actions, use policy engines for rule-based decisions, batch low-risk reviews, and watch approval rates and decision times. A gate that is approved 100% of the time is either redundant or ignored. ##### Can another AI agent act as the approver? Only if it is truly independent: separate credentials, separate instructions, and no way for the requesting agent to influence it. For irreversible or high-value actions, keep a person as the final approver. --- Suggested images (alt text): - Hero: "Flow diagram showing an AI agent's proposed action stopping at an approval gate before reaching production systems" - Table graphic: "Five AI agent actions that need human approval: money, data deletion, privileges, sensitive data, delegation" - Metrics graphic: "Dashboard tiles showing approval rate, time to decision, rejection reasons and bypass attempts for an AI agent" --- ## AI Agent Governance Framework: How to Control Agents by Autonomy Level URL: https://clateway.com/articles/ai-agent-governance-framework Published: 2026-10-20 · Clateway Technology Council Key takeaways: A four-level AI agent governance framework for IT leaders: classify agents by autonomy, govern embedded SaaS agents and meet EU AI Act dates. **Bottom line:** AI agents are arriving faster through software you already bought than through projects you approved. One governance policy for every agent fails both ways: simple agents get slowed down and risky ones slip through. An AI agent governance framework that works sorts agents by autonomy level, gives each one its own identity and a named owner, and enforces controls at runtime, not only in policy documents. #### Why AI agent governance is now a board-level question Three data points explain why IT leaders are being asked about agents this quarter: - **Agents are coming built in.** Gartner predicted in August 2025 that up to [40% of enterprise applications will include task-specific AI agents by the end of 2026](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025), up from less than 5% in 2025. A CRM, [ITSM](https://clateway.com/glossary/major-incident-management) or HR suite you approved two years ago can gain the ability to act through an ordinary release. - **Projects get stopped.** Gartner also expects [over 40% of agentic AI projects to be cancelled by the end of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) because of rising costs, unclear business value or weak risk controls (June 2025). - **The governance gap shows up in production.** In May 2026 Gartner predicted that [by 2027, 40% of enterprises will demote or decommission autonomous AI agents](https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure) because of governance gaps found only after incidents. Identity teams feel this already. A January 2026 Cloud Security Alliance survey of nearly 400 IT and security professionals found that [79% had low to moderate confidence](https://cloudsecurityalliance.org/press-releases/2026/01/27/79-of-it-pros-feel-ill-equipped-to-prevent-attacks-via-nhi-csa-oasis-survey-finds) in defending against attacks that use non-human identities, and more than 16% did not track the creation of new AI-related identities (as reported by [TechTarget, September 2026](https://www.techtarget.com/data-technologies/tip/How-to-control-agentic-AI-access-to-enterprise-data)). #### The blind spot: approved software that quietly turns agentic Most [AI governance](https://clateway.com/glossary/ai-governance) programmes were built around a front door: a team asks to use a model or tool, and a review board approves or rejects it. Agents do not always use that door. Vendors switch on agent features in existing licences, business users connect assistants to mailboxes and ticket queues, and suppliers embed their own engineers to build agents for you. That last route has its own risk. In September 2026 Gartner warned that [70% of enterprises will abandon agentic AI systems built with vendor assistance by 2028](https://www.theregister.com/ai-and-ml/2026/09/30/7-in-10-enterprises-expected-to-abandon-vendor-built-agentic-ai-by-2028/5300021) when customers lack the knowledge and control to maintain them once the vendor leaves. Gartner's advice: agree governance, IP ownership, knowledge transfer and an exit strategy from day one. The practical answer is to trigger a review on **capability change**, not only on purchase. If a product gains write access, the ability to send messages or the ability to change configurations, it goes back through governance, even when the contract and the vendor stay the same. #### A four-level AI agent governance framework Gartner's May 2026 guidance warns against binary governance ("locked down or fully trusted"). It proposes proportional controls across four autonomy levels. We have turned it into a working checklist: | Level | What the agent can do | Typical use | Minimum controls | |---|---|---|---| | 1. Observe | Read-only access to defined sources; output only to the requester | Summarising documents, search, explaining code | Scoped data access, user authentication, usage logging, basic security testing | | 2. Advise | Drafts and recommends; humans carry out every action | E-mail drafts, reports, decision support | Level 1 plus accuracy and hallucination testing, domain quality checks, user training against automation bias | | 3. Act with approval | Writes data, sends messages or changes configurations after explicit human approval | Ticket updates, customer replies, config changes | Level 2 plus approval workflows with audit trails, security testing, agent-specific incident response, monitoring for approval fatigue | | 4. Act autonomously | Acts on its own within guardrails; humans review exceptions and outcomes | High-volume operations, remediation | Level 3 plus continuous monitoring, enforced guardrails, fast rollback, circuit breakers and a named owner for agent behaviour | The value of the table is speed. Most agents in a typical portfolio sit at Levels 1 and 2. Keeping their controls light removes the reason teams build "shadow agents" to get around a slow review, so the governance effort goes to the few Level 3 and 4 agents that can do real damage. #### Five controls to put in place before an agent touches production data Policies set intent; runtime controls make it real. Drawing on a [NIST concept paper on AI agent identity (February 2026)](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd) and current practice, these five controls give the most protection for the effort: - **One identity per agent.** No shared service accounts. Every production agent gets its own identity that can be attributed, using standards your identity team already knows (OAuth 2.x, OpenID Connect, SCIM for lifecycle management). - **A named human owner.** Every agent has an accountable person who approves its scope and answers for its behaviour. - **Short-lived, task-scoped credentials.** Replace standing API keys with tokens limited to one task, resource and action, and make sure you can revoke a misbehaving agent within minutes. - **Delegation you can prove.** When an agent acts for a user, the record shows both the person who authorised it and the agent that acted. The IETF [Identity Assertion Authorization Grant draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) is one emerging way to do this. - **Tamper-evident audit records.** Log what the agent was allowed to do, what it did and which resources it touched, so incident response can rebuild the chain in hours, not weeks. #### How the EU AI Act timeline affects your agent roadmap For European organisations, the regulatory clock moved but did not stop. Under the Digital Omnibus on AI agreed in May 2026, high-risk obligations for stand-alone Annex III systems (such as recruitment and credit scoring) move from 2 August 2026 to **2 December 2027**, and to **2 August 2028** for AI embedded in regulated products ([Gibson Dunn, 27 May 2026](https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/); see also the [European Commission AI Act timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act)). The Article 50 transparency duties, including telling people they are dealing with an AI system, have applied since 2 August 2026. The extra time is useful because building an agent inventory, classifying agents and wiring identity controls takes several quarters. An agent that screens candidates or approves credit is likely to be high-risk whatever its autonomy level, so record the regulatory classification next to the autonomy level in your agent register. #### A 90-day plan for IT leaders - **Days 1–30: inventory.** Ask your top 20 SaaS vendors which agent features are live or planned in your tenant, and list the agents your own teams have built. Record owner, data accessed and autonomy level. - **Days 31–60: classify and close the gaps.** Apply the four-level table. Move Level 3 and 4 agents off shared accounts and long-lived keys first. - **Days 61–90: make it routine.** Add a "capability change" trigger to vendor management, add agent scenarios to incident response playbooks, and report the agent register to the risk committee every quarter. For wider context on the trends shaping IT agendas this year, see our briefing [6 Trends Shaping IT in 2026](https://clateway.com/newsletters/clateway-insights-6-trends-shaping-it-in-2026). #### Frequently asked questions ##### What is an AI agent governance framework? It is the set of policies, roles and technical controls that decide what AI agents may access and do, who is accountable for them and how their actions are monitored. Effective frameworks scale controls to each agent's autonomy instead of applying one rule to all. ##### How is AI agent governance different from general AI governance? General AI governance focuses on models and outputs: bias, accuracy, acceptable use. Agent governance adds **actions**. Agents hold credentials, call systems and change data, so identity, authorisation, rollback and audit become central. ##### Who should own AI agent governance? Shared ownership works best: the CIO or CISO owns the framework and controls, a named business owner is accountable for each agent, and legal and risk teams own the regulatory classification. A single register connects all three. ##### Do agents embedded in SaaS products need governing? Yes. They act with your data and your users' authority. Treat a vendor release that adds write or send capabilities as a change that needs review, just like a new purchase. ##### Does the EU AI Act delay mean we can wait? No. High-risk obligations now start in December 2027 (Annex III) and August 2028 (Annex I), but transparency duties already apply, and the inventory and identity work behind compliance takes months. --- ## AI and Cybersecurity: The Growing Threat of AI-Powered Identity Fraud URL: https://clateway.com/articles/ai-and-cybersecurity-the-growing-threat-of-ai-powered-identity-fraud Published: 2026-10-09 · Clateway Technology Council Key takeaways: Artificial intelligence is revolutionizing identity fraud, enabling sophisticated attacks through deepfakes, voice cloning, and automated social engineering. This article explores the evolving threat landscape and provides actionable strategies for enterprise security leaders to defend against AI-powered identity fraud. The cybersecurity landscape faces a challenge as artificial intelligence transforms from a protective tool into a weapon of choice for sophisticated threat actors. Identity fraud, once limited by human capabilities and technical constraints, now operates at machine speed with unprecedented sophistication. For enterprise security leaders, understanding and defending against AI-powered identity fraud has become a critical issue that demands immediate attention and strategic investment. #### The New Face of Digital Deception AI-powered deepfakes and voice cloning technologies have fundamentally altered the threat landscape. These tools, once requiring specialized expertise and significant resources, are now accessible through user-friendly applications and cloud-based services. Threat actors can generate convincing video and audio content of executives, employees, or trusted partners within minutes rather than weeks. The implications extend far beyond simple impersonation. Sophisticated social engineering attacks now leverage AI-generated content to bypass traditional verification methods. An attacker can clone a CEO's voice from publicly available conference recordings, then use that synthetic voice to authorize fraudulent wire transfers or request sensitive information from employees. The psychological impact of hearing a familiar voice creates a false sense of security that traditional training programs have not adequately addressed. Recent incidents demonstrate the scale of this threat. Financial institutions report attempted fraud using AI-generated executive voices, while technology companies face deepfake video calls designed to extract proprietary information. The authenticity of these synthetic media often goes beyond human ability to detect deception through a conventional observation. #### Automation Amplifies Attack Scale Machine learning algorithms have enabled threat actors to automate identity theft operations at unprecedented scale. Traditional identity fraud required manual research, individual targeting, and human intervention at multiple stages. AI-powered systems can now process vast datasets of personal information, identify vulnerable targets, and execute coordinated attacks across thousands of potential victims simultaneously. These automated systems excel at pattern recognition and adaptation. They analyze successful attack vectors, refine their approaches based on defensive responses, and continuously evolve their techniques. The result is a dynamic threat environment where traditional reactive security measures consistently lag behind attacker capabilities. **Data brokers and leaked databases** provide the raw material for these AI-driven operations. Machine learning algorithms correlate information across multiple sources, building comprehensive profiles that enable highly targeted attacks. The sophistication of these profiles often exceeds what human analysts could achieve manually, creating attack vectors that traditional security frameworks struggle to anticipate. #### The Inadequacy of Traditional Verification Conventional identity verification methods face fundamental limitations when confronted with AI-generated fraud. Knowledge-based authentication, which relies on personal information questions, becomes vulnerable when attackers possess comprehensive data profiles generated through automated analysis. Voice recognition systems, designed to authenticate based on vocal characteristics, struggle to distinguish between genuine voices and high-quality AI clones. Document-based verification faces similar challenges as AI tools become capable of generating convincing synthetic documents. Traditional fraud detection systems, trained on historical patterns of human behavior, fail to recognize the novel signatures of AI-generated attacks. The speed and scale at which these attacks operate often overwhelm manual review processes, creating gaps in detection coverage. Biometric systems, once considered highly secure, now face potential compromise through sophisticated spoofing techniques. While not yet widespread, emerging capabilities in synthetic biometric generation suggest that even these advanced authentication methods may require enhancement to maintain effectiveness against AI-powered threats. #### Building Multi-Layered AI-Powered Defenses Effective defense against AI-powered identity fraud requires equally sophisticated countermeasures. Multi-layered authentication systems that combine multiple verification factors create resilience against individual component failures. These systems should incorporate behavioral biometrics, device fingerprinting, and contextual analysis alongside traditional authentication methods. AI-powered defense systems offer the capability to match the speed and sophistication of AI-driven attacks. Machine learning algorithms can analyze communication patterns, detect anomalies in user behavior, and identify synthetic content markers that human reviewers might miss. These systems continuously learn from new attack patterns, adapting their detection capabilities as threats evolve. Real-time detection systems represent a critical component of modern defense strategies. These platforms analyze incoming communications, transaction requests, and authentication attempts for indicators of AI-generated content. Advanced systems can identify subtle artifacts in synthetic media, unusual timing patterns in automated attacks, and behavioral inconsistencies that suggest non-human interaction. #### Regulatory Compliance in an Evolving Landscape The rapid evolution of AI fraud techniques creates significant challenges for regulatory compliance. Existing frameworks often assume traditional threat models that AI-powered attacks can circumvent. Organizations must interpret compliance requirements through the lens of emerging threats while maintaining adherence to established standards. Documentation and audit trails become more complex when dealing with AI-powered attacks. Traditional forensic analysis may prove insufficient when investigating incidents involving synthetic media or automated attack systems. Organizations need enhanced logging capabilities and specialized analysis tools to meet regulatory expectations for incident response and investigation. Legal frameworks struggle to keep pace with technological advancement. The use of AI-generated evidence in legal proceedings raises questions about authenticity and admissibility that existing precedents may not adequately address. Security leaders must work closely with legal counsel to ensure that their defensive measures align with evolving regulatory interpretations. #### Transforming Employee Training Programs Traditional security awareness training requires fundamental updates to address AI-powered threats. Employees need specific guidance on recognizing synthetic media, understanding the limitations of voice and video authentication, and implementing additional verification steps for high-risk transactions. Training programs must address the psychological aspects of AI-generated deception. The convincing nature of deepfakes and voice clones can overcome natural skepticism, making it essential to establish verification protocols that do not rely solely on human perception. Employees should understand that familiar voices and faces in digital communications may not guarantee authenticity. Simulation exercises using AI-generated content can provide valuable hands-on experience. These controlled scenarios help employees recognize subtle indicators of synthetic media while reinforcing the importance of following established verification procedures regardless of apparent authenticity. #### Embracing Zero-Trust Architecture Zero-trust architecture becomes essential in an environment where traditional identity indicators may be compromised. This approach assumes that no communication or authentication attempt is inherently trustworthy, regardless of apparent source or credentials. Every access request undergoes verification through multiple independent channels. Implementation of zero-trust principles requires careful balance between security and operational efficiency. Organizations must design systems that provide robust verification without creating excessive friction for legitimate users. This often involves intelligent risk assessment that applies appropriate verification levels based on context and potential impact. The zero-trust model extends beyond technical controls to encompass organizational culture and processes. Security policies must reflect the assumption that any identity claim may be fraudulent, while providing clear procedures for verification and escalation when suspicious activity is detected. #### Strategic Recommendations for Enterprise Leaders Enterprise security leaders should prioritize investment in AI-powered detection capabilities while maintaining awareness of emerging attack techniques. Regular assessment of existing authentication systems against AI-powered threats can identify vulnerabilities before they are exploited. Collaboration with industry peers and security researchers provides valuable intelligence on evolving attack methods. Organizations should establish clear incident response procedures specifically designed for AI-powered identity fraud. These procedures must account for the unique characteristics of synthetic media attacks and the potential for rapid escalation across multiple targets. Regular testing and refinement of these procedures ensures readiness when incidents occur. The fight against AI-powered identity fraud requires continuous adaptation and investment. As artificial intelligence continues to evolve, so too must the defensive strategies that protect enterprise assets and reputation. The organizations that recognize this challenge early and invest appropriately in advanced defensive capabilities will be best positioned to maintain security in an increasingly complex threat environment. This content is advisory and overseen by one of our technology leaders and editors and should be reviewed by qualified cybersecurity professionals and legal counsel before implementation. Security strategies should be tailored to specific organizational requirements and risk profiles. --- ## Weekly Technology Insights - October 2026 URL: https://clateway.com/articles/weekly-technology-insights-october-2026 Published: 2026-10-09 · Clateway Technology Council Key takeaways: A comprehensive roundup of this week's most important technology trends and strategic insights for business leaders #### AI and Automation Developments Enterprise artificial intelligence adoption accelerated this week with several key developments reshaping how organizations approach automation and intelligent systems. The focus has shifted from experimental implementations to production-ready solutions that deliver measurable business value. **Enterprise AI Integration Maturity** Organizations are moving beyond pilot programs toward comprehensive AI strategies. Industry analysts report that companies are increasingly prioritizing [AI governance](https://clateway.com/glossary/ai-governance) frameworks and establishing centers of excellence to manage deployment at scale. The emphasis has shifted from "AI for AI's sake" to targeted applications that address specific operational challenges. **Automation in Financial Services** The financial sector continues leading AI adoption, particularly in fraud detection and regulatory compliance. This week saw announcements of automated compliance monitoring systems that can process regulatory changes in real-time, reducing manual oversight requirements by significant margins. These developments highlight the growing sophistication of AI applications in highly regulated industries. **Workforce Impact Considerations** Technology leaders are grappling with the human dimension of AI implementation. Recent surveys indicate that successful AI initiatives require substantial investment in employee training and change management. Organizations that prioritize workforce development alongside technology deployment report higher success rates in AI project outcomes. #### Cybersecurity Trends The cybersecurity landscape evolved rapidly this week with new threat vectors emerging alongside defensive innovations. Executive teams are reassessing their security postures in response to increasingly sophisticated attack methodologies. **Supply Chain Security Focus** [Third-party risk management](https://clateway.com/glossary/third-party-risk-management) has become a critical priority following recent incidents affecting multiple organizations through vendor compromises. Companies are implementing more rigorous vendor assessment protocols and requiring enhanced security attestations from technology partners. This trend reflects the interconnected nature of modern business operations and the cascading effects of security breaches. **Zero Trust Architecture Adoption** Zero trust security models gained further traction as organizations recognize the limitations of perimeter-based defenses. Implementation strategies are evolving to address practical challenges around user experience and legacy system integration. Technology leaders report that successful zero trust initiatives require comprehensive identity management strategies and cultural shifts in security thinking. **Regulatory Compliance Evolution** New cybersecurity regulations continue emerging across jurisdictions, requiring organizations to adapt their compliance strategies. The regulatory landscape is becoming more prescriptive about specific security controls and incident reporting requirements. Companies with global operations face the challenge of harmonizing compliance across multiple regulatory frameworks. #### Digital Transformation Updates Digital transformation initiatives are entering a new phase characterized by platform consolidation and operational optimization rather than technology proliferation. **Cloud Strategy Refinement** Organizations are shifting from "cloud-first" to "cloud-smart" approaches, focusing on workload optimization and cost management. Multi-cloud strategies are becoming more sophisticated, with companies developing specific criteria for workload placement based on performance, compliance, and economic factors. This evolution reflects growing maturity in cloud adoption and operational experience. **Data Strategy Centralization** Data governance and analytics platforms are consolidating as organizations seek to break down information silos. The trend toward unified data architectures is driven by the need for comprehensive business intelligence and AI readiness. Companies are investing in data quality initiatives and establishing data stewardship programs to support these consolidated approaches. **Customer Experience Platform Integration** Customer-facing digital platforms are becoming more integrated and personalized. Organizations are moving beyond channel-specific solutions toward omnichannel experiences that provide consistent interactions across touchpoints. This shift requires significant integration work and often involves modernizing legacy customer relationship systems. #### Technology Leadership Insights Technology executives are adapting their leadership approaches to address evolving organizational needs and market conditions. **Strategic Planning Horizons** Technology leaders are extending their planning horizons while maintaining flexibility for rapid adaptation. The traditional annual planning cycle is being supplemented with quarterly strategy reviews and continuous capability assessments. This approach balances long-term vision with the need to respond quickly to market changes and technological developments. **Talent Development Priorities** Skills development has become a critical leadership focus as technology roles evolve rapidly. Organizations are investing in internal training programs and establishing partnerships with educational institutions to build necessary capabilities. The emphasis is shifting from hiring for current skills to developing adaptive capacity and learning agility. **Vendor Relationship Management** Technology leaders are restructuring vendor relationships to emphasize strategic partnerships over transactional arrangements. This includes consolidating vendor portfolios, establishing governance frameworks for partner management, and aligning vendor roadmaps with organizational objectives. The goal is to create more predictable technology ecosystems that support long-term business strategies. #### Industry Analysis Cross-industry trends are revealing common patterns in technology adoption and organizational transformation. **Sustainability Technology Integration** Environmental, social, and governance (ESG) considerations are becoming integral to technology decision-making. Organizations are evaluating the carbon footprint of their technology infrastructure and seeking solutions that support sustainability objectives. This trend is influencing everything from data center selection to software development practices. **Regulatory Technology Convergence** Regulatory technology (RegTech) solutions are expanding beyond financial services into healthcare, manufacturing, and other heavily regulated industries. The convergence of compliance requirements across sectors is driving demand for flexible, configurable regulatory platforms that can adapt to different industry requirements. **Economic Uncertainty Impact** Current economic conditions are influencing technology investment priorities, with organizations focusing on solutions that provide clear return on investment and operational efficiency gains. Technology leaders are being asked to demonstrate more rigorous business cases for major initiatives while maintaining innovation momentum. **Disclaimer**: This analysis is based on publicly available information and industry observations. Technology leaders should validate specific recommendations with their internal teams and qualified advisors before making strategic decisions. Market conditions and regulatory requirements may vary by jurisdiction and industry sector. --- ## AI Agent Security: The New Identity Management Frontier Demanding C-Suite Attention URL: https://clateway.com/articles/ai-agent-security-the-new-identity-management-frontier-demanding-c-suite-attention Published: 2026-09-29 · Clateway Technology Council Key takeaways: As AI agents proliferate across enterprise systems with unprecedented autonomy and access privileges, organizations face a fundamental shift in identity and access management. The emergence of specialized security frameworks, governance controls, and venture-backed solutions signals that agent identity management is becoming a critical cybersecurity domain requiring dedicated executive oversight and strategic investment. ### Background: When Software Actors Become Security Actors The enterprise technology landscape is witnessing a paradigm shift as AI agents evolve from experimental tools to active participants in business operations. Unlike traditional software applications that respond to user commands, AI agents operate with increasing autonomy—browsing the web, executing code, accessing databases, and making decisions across enterprise systems. This fundamental change in how software interacts with corporate infrastructure has created an entirely new category of security risk that existing identity and access management frameworks were never designed to address. The challenge extends beyond simple access control. Traditional identity management focuses on authenticating users and granting permissions to passive resources. AI agents, however, represent what security professionals are beginning to recognize as "active identities"—software entities capable of independent action, cross-system navigation, and dynamic decision-making. As one industry analysis notes, "Companies now need to protect not only users, devices and applications, but software actors that can take actions on their behalf" [4]. ### Key Developments: Industry Mobilization Around Agent Governance #### Standards Bodies and Platform Initiatives The Cloud Security Alliance has positioned itself at the forefront of this emerging domain, actively building industry consensus around governance and security controls for autonomous AI systems. The organization's recent endorsement of specialized platforms demonstrates the urgency with which standards bodies are approaching agent security [1]. This standardization effort is crucial, as enterprises need consistent frameworks for evaluating and implementing agent security controls across diverse technology stacks. The development of dedicated safety platforms represents a significant evolution in enterprise AI infrastructure. These platforms are specifically engineered to "give agents the freedom to do useful work while maintaining control over their actions," addressing the fundamental tension between agent autonomy and organizational risk management [1]. #### Intelligence Integration and Real-Time Decision Making The launch of specialized intelligence layers for agentic security operations marks another critical development. Recorded Future's Model Control Protocol (MCP) exemplifies this trend, providing AI agents with direct access to threat intelligence data to enable "precise, trustworthy, and cost-effective decision-making at machine speed and scale" [2]. This integration of real-time intelligence into agent decision-making processes represents a sophisticated approach to autonomous security operations, but also introduces new dependencies and potential failure points that enterprises must carefully evaluate. #### Supply Chain Security Concerns The agent ecosystem's rapid expansion has exposed significant supply chain vulnerabilities that traditional security models inadequately address. A notable incident involving an MCP server distributed through npm demonstrated how quickly trust relationships can be compromised in the AI supply chain [3]. The affected package operated normally across 15 versions and achieved substantial adoption before introducing malicious functionality, highlighting the sophisticated nature of threats targeting AI infrastructure. This incident underscores a critical insight: "An enterprise can approve an AI model, authenticate its users, and restrict access to internal systems, yet still expose sensitive data through the components surrounding that model" [3]. The implication is that agent security requires a holistic approach that extends beyond the AI models themselves to encompass the entire ecosystem of supporting components, servers, and integration points. #### Investment and Market Formation Venture capital activity in this space signals strong market confidence in the commercial viability of agent security solutions. Baselayer's $35 million Series A funding round, specifically focused on extending identity verification technology to AI agents, demonstrates investor recognition of the market opportunity [5]. The company's expansion from traditional business identity verification into agent identity management reflects the natural evolution of existing security capabilities to address new threat vectors. ### Impact Analysis: Strategic Implications for Enterprise Leadership #### Operational Risk and Compliance The proliferation of AI agents introduces operational risks that extend far beyond traditional cybersecurity concerns. Agents with access to corporate systems can inadvertently expose sensitive data, execute unauthorized transactions, or make decisions that violate regulatory requirements. Unlike human users, whose actions can be traced through established audit trails and accountability mechanisms, agent actions may occur at machine speed across multiple systems simultaneously, making post-incident analysis significantly more complex. For organizations in regulated industries, agent governance becomes a compliance imperative. Financial services firms, healthcare organizations, and government contractors must demonstrate that AI agents operating within their environments maintain appropriate controls, audit trails, and approval workflows. The absence of established regulatory frameworks for agent governance means that organizations must proactively develop internal standards that anticipate future regulatory requirements. #### Identity Architecture Evolution Traditional identity and access management (IAM) architectures require fundamental reconsideration to accommodate agent identities. Unlike service accounts, which typically have static permissions and predictable access patterns, agents may require dynamic permissions that adapt to changing contexts and objectives. This evolution demands new approaches to privilege management, session monitoring, and access revocation. The challenge is compounded by the fact that agents may operate across organizational boundaries, accessing external APIs, cloud services, and partner systems. Establishing trust relationships and maintaining security controls across these distributed environments requires coordination between multiple stakeholders and potentially incompatible security frameworks. #### Skills and Organizational Readiness The emergence of agent security as a distinct discipline creates immediate skills gaps within enterprise security teams. Traditional cybersecurity professionals may lack the expertise needed to evaluate AI agent behaviors, configure appropriate monitoring systems, or respond to agent-related security incidents. Organizations must invest in training existing personnel while simultaneously recruiting specialists with experience in AI security, machine learning operations, and autonomous systems governance. ### What to Watch: Strategic Priorities for Technology Leaders #### Market Consolidation and Vendor Selection Industry analysis suggests that the agent security market will not develop as a single broad category but rather as a collection of specialized solutions addressing specific control points [4]. Organizations should expect to see continued market fragmentation, with different vendors focusing on agent identity management, data access controls, prompt security, and MCP server governance. This fragmentation creates both opportunities and challenges for enterprise buyers, who must carefully evaluate vendor capabilities and integration requirements. Technology leaders should monitor merger and acquisition activity in this space, as established cybersecurity vendors are likely to acquire specialized agent security capabilities rather than develop them internally. Early consolidation moves may signal which approaches are gaining market traction and which vendors are positioned for long-term success. #### Regulatory Development While current regulatory frameworks provide limited guidance on AI agent governance, this situation is likely to change rapidly as agents become more prevalent in enterprise environments. Technology leaders should actively participate in industry working groups and standards development processes to influence emerging regulations and ensure their organizations are prepared for compliance requirements. Particular attention should be paid to sector-specific regulations that may impose unique requirements on agent deployment and governance. Financial services, healthcare, and critical infrastructure organizations should expect more stringent oversight of AI agent operations in the near term. #### Integration and Interoperability Challenges As the agent security ecosystem matures, organizations will need to integrate multiple specialized solutions into coherent governance frameworks. Technology leaders should prioritize vendors and platforms that demonstrate strong API capabilities, standards compliance, and integration flexibility. The ability to correlate agent activities across multiple security tools and maintain unified audit trails will become increasingly important as agent deployments scale. #### Proof of Concept and Pilot Programs Given the nascent state of agent security technologies, organizations should approach vendor selection through carefully structured pilot programs that test specific use cases and integration requirements. These pilots should focus on measurable outcomes such as policy enforcement effectiveness, incident response capabilities, and administrative overhead. Technology leaders should also establish baseline metrics for agent behavior and security posture before implementing specialized security controls, enabling more accurate assessment of solution effectiveness and return on investment. Note: This analysis is based on publicly available information and industry reporting. Organizations should conduct thorough due diligence and consult with qualified security professionals when evaluating AI agent security solutions and developing governance frameworks. --- ## Enterprise AI Agents Enter Production: Advanced Models Drive Autonomous URL: https://clateway.com/articles/enterprise-ai-agents-enter-production-advanced-models-drive-autonomous-work Published: 2026-09-29 · Clateway Technology Council Key takeaways: Major cloud providers are launching production-ready AI agent platforms powered by sophisticated models like GPT-6 variants and Claude Opus 5.5, marking a fundamental shift from experimental AI to autonomous enterprise systems. This evolution enables AI agents to handle complex, long-running workflows in coding, knowledge work, and business operations with unprecedented reliability and scale. ### Background: From Experimental to Production-Grade The enterprise AI landscape is experiencing a further transformation as agentic AI systems transition from proof-of-concept demonstrations to production-ready platforms capable of autonomous decision-making and execution. Unlike traditional AI applications that respond to user inputs, these new agentic systems continuously reason through problems, break them into steps, execute solutions, and iterate based on results—all without human intervention in the loop [9]. This shift represents more than an incremental improvement in AI capabilities. As one industry analysis notes, "The work we used to capture as deterministic code, where every branch was defined in advance and every step was known before the first line ran, is now being rewritten as multi-agent applications that work out the steps at runtime" [9]. This fundamental change in how enterprise software operates puts new demands on underlying infrastructure and governance frameworks. ### Key Developments: Advanced Models and Platform Maturation #### Next-Generation Model Capabilities The availability of advanced models specifically designed for agentic workflows marks a critical milestone. Microsoft Foundry has launched GPT-6 Sol and GPT-6 Luna alongside GPT-6 Astra, with these models engineered to "produce less noise and are more capable at completing full tasks with agents" [10]. These systems bring advanced reasoning, software engineering, and computer interaction capabilities to demanding work requiring both judgment and autonomous action. Similarly, Claude Opus 5.5 has been optimized for "everyday complex work" that extends "far beyond a single prompt: building a feature across a codebase, investigating a complex issue, synthesizing hundreds of pages of information, or working through a multi-step business process" [12]. The model demonstrates improved focus during long-running tasks while providing better transparency into its decision-making process. #### Infrastructure Adaptations for Agent Workloads Cloud providers are fundamentally redesigning their platforms to support the unique demands of agentic systems. Google Cloud's AlloyDB now features an "agentic database architecture" that can provision sandboxed database instances in seconds, enabling full workload isolation for agent operations that can scale "from a few agents to millions of agents" [7]. This addresses a critical challenge where traditional database architectures become overwhelmed by the unpredictable query surges generated by agents executing dense reasoning loops. Microsoft Foundry has adopted a "model-agnostic foundation" approach, allowing organizations to "adopt better models as they emerge while preserving their investments in the enterprise systems, knowledge, tools, and controls that make agents useful to their business" [5]. This architectural decision reflects the recognition that model capabilities will continue evolving rapidly, requiring flexible platforms that can accommodate change without requiring complete rebuilds. #### Enterprise-Grade Voice and Multimodal Capabilities Google Cloud's launch of Gemini 3.8 Live with Live Avatar for general availability represents the maturation of enterprise voice AI beyond "basic speed and cost metrics" to focus on interaction quality [6]. These multimodal capabilities enable agents to engage in more natural, context-aware interactions across different communication channels, expanding their applicability to customer-facing and collaborative workflows. ### Impact Analysis: Transforming Enterprise Operations #### Autonomous Coding and Software Development The implications for software development are particularly profound. Google Cloud's "agent harness" concept demonstrates how agents can be grounded in rich context to achieve "high levels of agent autonomy" in coding tasks [4]. This shift from manual code editors to agent-driven development represents a fundamental change in how software is created, tested, and maintained. The concept of "shifting left" in agent interventions means that human oversight and control mechanisms are built into earlier stages of the development process, allowing agents greater autonomy in execution while maintaining appropriate governance and quality controls. #### Knowledge Work Automation Enterprise applications are expanding beyond traditional task automation to encompass complex knowledge work. Claude Opus 5.5's capabilities in "synthesizing hundreds of pages of information" and "working through multi-step business processes" [12] indicate that agents can now handle sophisticated analytical and research tasks that previously required significant human expertise and time investment. Real-world implementations are demonstrating tangible business value. In the hospitality sector, Dextr AI's deployment of agents for guest services, reservations, and staff coordination has shown measurable improvements in online reviews within 90-day periods [8], illustrating how agents can enhance both operational efficiency and customer experience. #### Security and Governance Considerations The production deployment of autonomous agents raises significant security and governance challenges. NVIDIA's Open Agent Safety Platform and the Cloud Security Alliance's focus on "governance and security controls for autonomous AI" [2] highlight industry recognition that agent autonomy must be balanced with appropriate safety mechanisms. The National Institute of Standards and Technology is actively addressing these concerns through initiatives exploring DevSecOps practices for agentic AI [1], recognizing that traditional security frameworks may need adaptation for systems that continuously act and make decisions without human oversight. #### Operational Intelligence and Decision-Making Platforms like Recorded Future's MCP (Intelligence Layer) are enabling agents to access real-time threat intelligence and make "precise, trustworthy, and cost-effective decision-making at machine speed and scale" [3]. This integration of external intelligence sources with agent decision-making capabilities represents a significant advancement in autonomous security operations and risk management. ### What to Watch: Strategic Considerations for Enterprise Leaders #### Platform Strategy and Vendor Lock-in Organizations should prioritize platforms that offer model flexibility and avoid architectural decisions that create dependencies on specific AI models. Microsoft Foundry's model-agnostic approach and emphasis on continuous optimization through "hill-climbing" methodologies [5] provide a template for sustainable agent platform strategies that can evolve with advancing capabilities. #### Governance Framework Development The shift to autonomous agents requires new governance frameworks that can provide oversight without inhibiting agent effectiveness. Organizations should develop policies for agent behavior, decision boundaries, escalation procedures, and audit trails that accommodate the dynamic nature of agentic systems while maintaining compliance and risk management standards. #### Workforce Transformation Planning The automation of complex knowledge work and coding tasks will require significant workforce planning and reskilling initiatives. Organizations should begin identifying roles that will be augmented versus replaced by agents, and develop training programs that help employees work effectively alongside autonomous systems. #### Infrastructure Readiness Assessment Current infrastructure may not be optimized for the continuous, unpredictable workloads generated by agent systems. Organizations should evaluate their database architectures, API management capabilities, and monitoring systems to ensure they can support agent-driven workflows at scale. #### Security Architecture Evolution Traditional security models based on human-initiated actions may need fundamental revision for environments where agents continuously interact with systems and data. Organizations should engage with emerging frameworks from standards bodies and industry consortiums to develop appropriate security architectures for agentic environments. Note: This analysis is based on publicly available information and industry developments as of late 2026. Organizations should validate specific capabilities and conduct thorough evaluations before implementing production agent systems. Given the rapidly evolving nature of AI technology, regular reassessment of platform choices and governance frameworks will be essential. --- ## Approach and architecture of GenAI and Enterprise data URL: https://clateway.com/articles/approach-and-architecture-of-genai-and-entterprise-data Published: 2026-09-28 · Clateway Technology Council Key takeaways: Save data in a enterprise data source, use AI providers stateless ### GenAI and Enterprise Data Architecture: A Stateless Approach The integration of Generative AI (GenAI) with enterprise data is a crucial strategy for organizations aiming to harness AI's potential without compromising on data security and compliance. This article outlines a recommended architecture that focuses on maintaining control over enterprise data while utilizing AI providers in a stateless manner. ### Recommended Architecture Components To ensure a secure and efficient integration of GenAI with enterprise data, the architecture consists of the following key components: - **Company Data Store** **Purpose**: Store enterprise data in a centralized data warehouse or database under your control. - **Implementation**: Utilize infrastructure from cloud providers such as AWS, Azure, or GCP to maintain direct oversight of your data. - **Middleware / API Gateway** **Functions**: **Anonymization**: Strip personal and sensitive identifiers from data. - **Encryption**: Secure data in transit to protect against interception. - **Access Control**: Manage who can interact with data, preventing unauthorized access. - **Prompt Caching**: Store frequently used instructions or queries to improve efficiency. - **Benefits**: Acts as a buffer between your data store and AI providers, ensuring data remains safeguarded. - **AI Model Provider** **Role**: Serve as a "stateless engine" that processes data, returns results, and forgets the data immediately. - **Integration**: Use APIs to send anonymized data for processing, ensuring no data persistence occurs on the AI provider's side. ### Core Architectural Benefits This architecture offers several advantages tailored to enterprise needs: - **No Vendor Lock-In**: By designing the system to interact with AI models via a single API endpoint, organizations can seamlessly switch between different AI providers, such as Claude or others, without extensive reconfiguration. - **Granular Access Control**: Utilizing existing security protocols ensures that internal policies govern who can read or write data, reducing the risk of AI models inadvertently exposing sensitive information. - **Compliance**: Keeping data storage in-house allows easy adherence to regional data residency laws such as [GDPR](https://clateway.com/glossary/gdpr) or HIPAA, as data never leaves your controlled environment. ### Implementation Considerations To tailor this architecture to your organization's specific needs, consider the following: - **Cloud Provider Choice**: Which cloud provider (AWS, Azure, GCP, etc.) does your company currently use or plan to use? This decision affects integration and data management strategies. - **Data Type**: Identify the types of data (e.g., text documents, SQL databases, customer tickets) you want the AI to analyze. This will influence data structuring and anonymization processes. - **Framework Needs**: Determine whether your organization requires an off-the-shelf framework, such as LangChain, for quicker deployment, or if a custom-built solution is more appropriate for your unique requirements. By adopting this architecture, enterprises can leverage the power of GenAI while maintaining control over their data, optimizing for both security and flexibility. Whether you are looking to implement this solution or explore further, understanding these components and their benefits is crucial in making informed decisions. --- ## NIS2 - Executive Implementation Brief URL: https://clateway.com/articles/nis2-executive-implementation-brief Published: 2026-04-29 · Clateway Technology Council Key takeaways: A board-level guide to scope, obligations, timelines, and the work programme required to comply with the EU's NIS2 Directive. **[NIS2](https://clateway.com/glossary/nis2)** **Executive Implementation Brief** What organisations actually need to do A board-level guide to scope, obligations, timelines, and the work programme required to comply with the EU's NIS2 Directive. **Clateway Insights** Executive Series The NIS2 Directive is now national law across most of the EU. Member States were required to apply national transposition measures from 18 October 2024. Supervision and enforcement are live. Administrative fines reach EUR 10 million or 2% of group worldwide turnover for essential entities, and personal accountability sits with the management body — including, as a last resort, temporary prohibition of senior individuals from managerial functions. For most organisations in scope, NIS2 is not primarily a technology project. It is a governance, risk and accountability programme that has technology consequences. The work concentrates in five areas: confirming whether and how the organisation is in scope; bringing the management body into formal accountability; closing the gap on the ten Article 21 risk-management domains; rebuilding the incident-reporting playbook around the 24 / 72 / 30-hour cadence; and extending cybersecurity due diligence into the supply chain. Each of these requires a defensible evidence trail, because supervisors will ask for one. This brief is written for boards, executive committees, and the CIO/CISO/CRO leadership preparing or refining their NIS2 programme. It is deliberately compact: the structure, the obligations, and the work to do — without legal restatement. A separate Clateway reference document covers the Directive article-by-article. **The single most important slide** NIS2 holds the management body — not the CISO, not the CIO, not IT — accountable for cybersecurity risk-management measures. Boards must approve the programme, oversee its implementation, undertake training, and can be held liable for the entity's infringements. This is the change that matters most. Everything else flows from it. ### 1. Confirm scope first Before any control work, the organisation must answer one question with a documented answer: are we in scope, and if so, as an essential entity or as an important entity? The answer determines the supervisory regime, the maximum fine, and the depth of evidence the organisation must maintain. ### The scoping test Walk the test in this order, document each step, and store the conclusion as the foundation of the compliance file: - Is the organisation in a sector listed in Annex I (sectors of high criticality) or Annex II (other critical sectors)? - Does it meet the size threshold — medium-sized enterprise or above (broadly: 50+ employees and EUR 10m+ turnover or balance-sheet total)? - If it does not meet the size threshold, does any 'regardless of size' trigger apply? These include trust services, TLD registries, DNS service providers, sole provider of an essential service in a Member State, central-government public administration, and entities critical at national or regional level. - Has the organisation been identified as a critical entity under the Critical Entities Resilience (CER) Directive? If so, it is automatically an essential entity under NIS2. - Does any Article 2 carve-out apply (national security, defence, law enforcement, exempt financial entities under [DORA](https://clateway.com/glossary/dora))? ### Essential vs important — what changes **Essential entity** **Important entity** Annex I sectors above the size threshold; certain entity types regardless of size; central-government public administration; CER critical entities All other in-scope entities in Annex I or II that do not qualify as essential Proactive (ex ante) supervision: regular and ad-hoc audits, on-site inspections, security scans, mandatory documentation Reactive (ex post) supervision: triggered by evidence, indication or information of non-compliance Last-resort enforcement available: temporary suspension of certifications and authorisations, temporary management ban for senior individuals Last-resort enforcement (Article 32(5)) does not apply Maximum administrative fine: at least EUR 10 million or 2% of total worldwide annual turnover of the undertaking, whichever is higher Maximum administrative fine: at least EUR 7 million or 1.4% of total worldwide annual turnover of the undertaking, whichever is higher If the organisation operates in multiple Member States, jurisdiction must also be settled. For most entities, jurisdiction is concurrent — each Member State where services are provided has authority. For digital infrastructure and digital providers (DNS, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplaces, search engines, social networking platforms), jurisdiction follows main establishment, similar to the [GDPR](https://clateway.com/glossary/gdpr) one-stop-shop. Document the location of cybersecurity decision-making — that is what determines main establishment, not where servers physically sit. ### 2. Bring the management body into accountability Article 20 is the structural change in cybersecurity governance. The management body must approve the cybersecurity risk-management measures, oversee their implementation, undertake training, and can be held personally liable for the entity's infringements. National transposition translates this into administrative, civil, or in some cases personal liability. Several Member States have introduced explicit director-liability provisions; others rely on existing corporate-governance frameworks. The board's exposure should be reviewed against the relevant national act, not against the Directive text alone. ### What the board needs to put in place - A formal, dated approval of the cybersecurity risk-management framework — the policies, the control set, the [risk appetite](https://clateway.com/glossary/risk-appetite), the supplier-cybersecurity expectations. - A standing reporting cadence (typically quarterly) covering the [risk register](https://clateway.com/glossary/risk-register), significant incidents, near misses, third-party assurance status, and remediation tracking against the framework. - Annual cybersecurity training for management body members, with content relevant to identifying risks and assessing risk-management practices, and with attendance recorded. - Clear delineation between management-body, executive, and operational responsibilities — typically expressed as a RACI or equivalent governance map. - Director-and-officer insurance and indemnity reviewed against the relevant national NIS2 transposition act, particularly where personal liability applies. - Documented evidence that significant cybersecurity decisions (control investments, supplier choices, risk acceptances) are taken with management-body awareness and approval where appropriate. **A practical heuristic** If a supervisor asked the chair of the board today to produce evidence — a single binder — that the management body has approved, oversees, and is being trained on the cybersecurity programme, could the organisation produce it within 48 hours? If not, that gap is the first one to close. ### 3. Close the gap on the ten risk-management domains Article 21 is the operational control set. Measures must be appropriate, proportionate, state-of-the-art, and follow an all-hazards approach — covering not only cyberattacks but theft, fire, flood, telecommunications and power failures, unauthorised physical access, human error, malicious acts, and natural phenomena. The Directive does not prescribe specific controls. It defines outcomes across ten domains, which the organisation must map to a recognised standard ([ISO/IEC 27001](https://clateway.com/glossary/iso-27001), IEC 62443, NIST CSF, sectoral standards) and demonstrate implementation against. ### The ten domains - Policies on risk analysis and information system security. - Incident handling. - Business continuity, including backup management, disaster recovery, and crisis management. - Supply-chain security, including direct supplier and service-provider relationships. - Security in network and information system acquisition, development, and maintenance — including vulnerability handling and disclosure. - Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. - Basic cyber hygiene practices and cybersecurity training. - Cryptography and, where appropriate, encryption. - Human-resources security, access-control policies, and asset management. - Multi-factor or continuous authentication; secured voice, video, and text communications; secured emergency communications — where appropriate. ### How to demonstrate implementation Supervisors expect evidence, not assurances. For each of the ten domains, the organisation should be able to produce: the policy or standard that governs the domain, the controls that operationalise it, the evidence that the controls run as designed, the metrics that track effectiveness, and the remediation log for known gaps. A useful test: can the organisation produce, for each domain, the most recent version of the policy, the latest assurance evidence, and the open-issue log within one working day? **For digital infrastructure and digital providers** Commission Implementing Regulation (EU) 2024/2690 sets concrete technical and methodological requirements for DNS service providers, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplaces, online search engines, social networking platforms, and trust service providers. Entities in those categories should treat that implementing act, not Article 21 alone, as the relevant control specification. ### 4. Rebuild the incident-reporting playbook Article 23 is the most operationally demanding provision in the Directive. The reporting cadence is fixed and short, the significance test must be applied early, and the organisation must be able to produce structured notifications under pressure — usually before the root cause is known. ### The 24 / 72 / 30 cadence - **Hour 0 — **the organisation becomes aware of a significant incident. Incident handling begins. The significance assessment must be running in parallel. - **Hour 24 — early warning **to the CSIRT or competent authority, indicating where applicable whether the incident is suspected to be unlawful or malicious and whether it could have cross-border impact. - **Hour 72 — incident notification **updating the early warning with an initial assessment of severity and impact, and indicators of compromise where available. - **On request — intermediate report **with relevant status updates if the CSIRT or competent authority asks for one. - **Day 30 from notification — final report **with a detailed description of the incident, the root cause, the mitigation measures applied and ongoing, and any cross-border impact. If the incident is still active, a progress report is submitted on day 30 and the final report follows within one month of closure. - **Trust service providers — derogation: **the incident notification is due within 24 hours of awareness, not 72. ### Significance — the threshold question An incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss to the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The triage must run early. For digital infrastructure and digital provider categories, Implementing Regulation (EU) 2024/2690 sets concrete numeric thresholds; for other sectors, national transposition typically supplies guidance. The playbook must reference both. ### What the playbook must contain - A clear definition of 'becoming aware', so the 24-hour clock starts at a defensible moment. - A significance-assessment checklist mapped to the relevant implementing act and national guidance. - Templates for the early warning, incident notification, intermediate report, final report, and progress report. - A named accountable role per stage — typically CISO for the technical content and General Counsel or DPO for legal and regulator coordination. - A coordination process with GDPR notification under Article 33, since many significant incidents will trigger both regimes simultaneously. - A communications protocol for service recipients potentially affected by the incident or by a significant cyber threat. - A rehearsal schedule — at least one tabletop per year that exercises the 24-hour clock end-to-end. ### 5. Extend cybersecurity into the supply chain Article 21(2)(d) and 21(3) make supply-chain cybersecurity a first-class obligation. The organisation must take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of products and cybersecurity practices of suppliers (including secure-development procedures), and the results of any Union-level coordinated risk assessment carried out under Article 22. This is the area where most NIS2 programmes underestimate the work. Procurement, vendor risk management, and contract templates typically need to be rebuilt — not lightly amended — because the obligation is ongoing and evidence-based, not a one-time questionnaire. ### What needs to be in place - A current inventory of direct suppliers and service providers, classified by criticality to the in-scope services. - A tiered due-diligence process that scales with criticality — light-touch questionnaires for low-risk suppliers, formal cybersecurity assessments for high-risk ones, on-site or independent-audit assurance for the most critical. - Standard contract clauses covering cybersecurity risk-management obligations, incident-notification timelines aligned to the entity's own 24 / 72 / 30 cadence, audit rights, sub-processor approval, and termination triggers on serious failures. - Ongoing monitoring of supplier cybersecurity posture, not just point-in-time onboarding checks. - A process for ingesting and acting on Article 22 coordinated supply-chain risk assessments published at Union level — these may impose mandatory mitigation measures on specific technologies. - Particular attention to managed service providers (MSPs) and managed security service providers (MSSPs), which are now formally defined and brought directly into scope, anchoring supply-chain accountability at the contractual perimeter. **MSP and MSSP risk** MSPs and MSSPs are explicitly named in Annex I and singled out in the recitals because of their privileged access to client environments. If the organisation outsources detection, response, identity, or core operations to an MSP or MSSP, the supplier's cybersecurity practices are effectively the organisation's. Increased diligence in selection — and in ongoing assurance — is now an explicit expectation. ### 6. The work programme — at a glance A typical NIS2 implementation programme runs across six workstreams. The shape and pace varies with starting maturity, but the structure does not. **Workstream** **What it covers** **Key deliverables** **Scoping & registration** Document scope conclusion, classification (essential/important), main establishment, and jurisdiction. Register with the relevant competent authority by the national deadline. Scoping memo, registration confirmation, jurisdiction analysis **Governance** Stand up management-body accountability, board approval of the framework, training programme, reporting cadence, and personal-liability review. Board-approved framework, training records, RACI, indemnity review **Risk management** Map the ten Article 21 domains to a recognised standard, run a gap assessment, prioritise remediation, build the evidence library. Gap assessment, remediation roadmap, control-evidence repository **Incident reporting** Rebuild the playbook around 24 / 72 / 30. Define significance triage, build templates, rehearse end-to-end. Playbook, templates, tabletop after-action reports **Supply chain** Rebuild vendor due diligence, contract templates, ongoing assurance, MSP/MSSP scrutiny. Vendor inventory, due-diligence framework, contract clauses **Multi-jurisdiction tracking** For multinationals, track each national transposition law, each competent authority, and each variation in scope or fines. Jurisdiction matrix, national law tracker, single-point-of-contact list ### Indicative timeline For an organisation starting from a typical mid-market baseline — broadly aligned with ISO/IEC 27001 but without formal NIS2 mapping — the first cycle of work usually runs six to nine months across these workstreams, with a steady-state operating model from month nine onward. Organisations starting from a lower baseline, or with significant scope across multiple Member States, should plan for twelve months. Organisations that are already mature on ISO 27001 and have structured third-party risk management can usually compress to four months. The single most useful early action is the scoping memo and the management-body approval of the programme charter. Both can be completed in four to six weeks and unlock everything else: budget authority, accountability, and a defensible position if a supervisor engages before remediation is complete. ### 7. What 'good' looks like A NIS2 programme is in good shape when, taken together, the following statements are all true and evidenced: - Scope is documented and signed off. The organisation knows whether it is in scope, as essential or important, and under whose jurisdiction in each Member State of operation. - The management body has formally approved the cybersecurity risk-management framework, receives regular structured reporting against it, and has been trained within the last twelve months. - Each of the ten Article 21 domains maps to a named policy, a control set, and current evidence of operation. Gaps are tracked in a single remediation log with owner and date. - The incident-reporting playbook has been rehearsed end-to-end in the last twelve months, with the 24 / 72 / 30 timeline tested under realistic conditions. - The supplier base is inventoried, classified by criticality, and subject to ongoing assurance proportionate to that classification — with MSP and MSSP relationships under particular scrutiny. - Registration with the relevant competent authority is current, contact details are accurate within the two-week change window, and SPOC relationships are established. - The programme is integrated with adjacent regimes (GDPR, DORA where relevant, CER, eIDAS, EECC, the Cyber Resilience Act, the AI Act) so that overlapping obligations are met once, not multiple times. **The board-level test** Could the organisation, on a Monday morning, produce a single one-page summary that tells a supervisor: this is our scope conclusion, this is our framework, this is our last board approval, this is our last training session, this is our last tabletop, this is our open-issue log, this is our register of suppliers? If yes, the programme is in good shape. If not, the priority is to make that page real, then back-fill the evidence behind it. ### How Clateway helps Clateway is a fractional executive practice for IT and cybersecurity leadership in mid-market organisations. We bring senior, multi-jurisdiction CTO and CIO experience into NIS2 programmes — at a fraction of the cost of full-time hires — and we apply a structured methodology, RCEC, that turns the NIS2 obligation into a defensible, board-grade work programme. ### RCEC — Research, Commit, Execute, Control RCEC is the methodology behind every Clateway engagement. It is designed for exactly the kind of programme NIS2 demands — one where the work is partly technical, mostly governance, and entirely accountability-driven. - **Research — **scope confirmation, gap assessment against the ten Article 21 domains, jurisdiction analysis, supplier-base review, and a clear baseline that the management body can act on. - **Commit — **a formal Board Commitment Ledger that captures what the management body has approved, what it has committed to fund, and what it has accepted as residual risk. This is the artefact that anchors personal accountability under Article 20. - **Execute — **delivery of the remediation roadmap, the incident-reporting playbook, the supplier-assurance rebuild, and the evidence library — with a fractional CTO or CIO embedded as a recognisable, accountable executive presence. - **Control — **steady-state oversight, board reporting cadence, training, tabletop rehearsals, and the ongoing assurance loop that keeps the programme defensible across regulatory cycles. ### What we typically deliver in an NIS2 engagement - A documented scope and classification memo, signed off by the management body. - A board-approved cybersecurity risk-management framework, with a quarterly reporting pack template the board actually uses. - A gap assessment against the ten Article 21 domains, mapped to ISO/IEC 27001 or the standard the organisation already operates. - A remediation roadmap with named owners, dates, and budget — sized against the organisation's actual capacity, not against an idealised maturity model. - A complete incident-reporting playbook aligned to 24 / 72 / 30, with templates, an exercised tabletop, and a coordination protocol with GDPR notification. - A rebuilt supplier-cybersecurity framework — inventory, classification, due-diligence process, contract clauses, ongoing assurance — with particular attention to MSP and MSSP relationships. - A multi-jurisdiction tracker for organisations operating across Member States, including SPOC contacts, national transposition variation, and registration status. - Management-body training, designed and delivered in plain language, with attendance recorded and content tailored to the organisation's actual risk profile. ### Why fractional executive leadership fits NIS2 NIS2 needs senior, accountable leadership — but most mid-market organisations cannot justify a full-time cybersecurity executive for a programme of this shape. The fractional model gives the board a recognisable executive presence, with the experience to run the programme and the standing to engage with regulators, without the cost or overhead of a permanent hire. The same person designs the framework, presents it to the board, leads the supplier negotiations, and is in the room when a supervisor calls. **Start the conversation** If your organisation is in scope of NIS2 — or unsure whether it is — Clateway can run a structured scoping and readiness review in four to six weeks, ending in a board-grade report that tells you exactly where you stand and what the work to closure looks like. **clateway.ai** Fractional - board - CTO and CIO leadership for the mid-market and small enterprise — RCEC methodology, multi-jurisdiction experience, board-grade delivery. — End of brief — --- ## THE NIS2 DIRECTIVE - A Complete Article-by-Article Reference and Explanation URL: https://clateway.com/articles/executive-summary Published: 2026-04-29 · Clateway Technology Council Key takeaways: A complete Articly by Article Reference and Explanation **THE [NIS2 DIRECTIVE](https://clateway.com/glossary/nis2)** Directive (EU) 2022/2555 A Complete Article-by-Article Reference and Explanation Measures for a high common level of cybersecurity across the Union Adopted 14 December 2022 · Entered into force 16 January 2023 · Transposition deadline 17 October 2024 **Clateway Insights** Regulatory Reference Series The NIS2 Directive (Directive (EU) 2022/2555) is the European Union's flagship cybersecurity law. It replaces the original NIS Directive of 2016 and substantially expands both the population of regulated entities and the depth of obligations placed upon them. NIS2 was adopted on 14 December 2022, entered into force on 16 January 2023, and Member States were required to transpose it into national law by 17 October 2024, with national measures applying from 18 October 2024. NIS2 pursues a single objective: to achieve a high common level of cybersecurity across the Union, thereby improving the functioning of the internal market. To do this, the Directive sets minimum rules covering national cybersecurity strategies, designation of competent authorities and CSIRTs, cooperation at Union level, cybersecurity risk-management and incident-reporting obligations for in-scope entities, supervision, and enforcement — including administrative fines that can reach EUR 10 million or 2% of worldwide annual turnover for essential entities. This document provides a structured, article-by-article walkthrough of the entire Directive. For each article, the reader will find both a description of what the article says and an explanation of what it means in practice — for Member States, for management bodies, and for the security, risk and compliance functions inside in-scope organisations. It is written to be used as an internal reference: a single, navigable source of truth that translates the Official Journal text into operational understanding. ### How to read this document The Directive is organised into nine chapters and 46 articles, plus three annexes. This document follows that structure exactly. Each article block contains a Description (a faithful summary of the legal text) and an Explanation (the practical meaning, intent, and impact). Defined terms — essential entity, important entity, significant incident, near miss, CSIRT — carry specific legal meaning under the Directive and are used consistently throughout. **Two-tier scope at a glance** NIS2 classifies in-scope organisations as either essential entities or important entities. Essential entities sit in sectors of high criticality (Annex I) and meet the size threshold, plus certain entities regardless of size (e.g. trust service providers, TLD registries, DNS service providers, qualified trust service providers, central-government public administration, identified critical entities). Important entities are the remainder of in-scope entities in Annex I and II. Essential entities face proactive (ex ante) supervision; important entities face reactive (ex post) supervision. ### Chapter I — General Provisions Chapter I sets the foundations: the subject matter and scope of the Directive, the relationship to sector-specific Union law, the principle of minimum harmonisation, and the definitions used throughout. These provisions determine who is in scope, who is out, and what key terms mean — questions every compliance project must answer before any control implementation begins. #### Article 1 — Subject matter **Description** Article 1 states that the Directive lays down measures to achieve a high common level of cybersecurity across the Union, with the aim of improving the functioning of the internal market. It does so by requiring Member States to adopt national cybersecurity strategies and designate competent authorities, cyber crisis management authorities, single points of contact, and CSIRTs; by imposing cybersecurity risk-management measures and reporting obligations on entities listed in Annexes I and II as well as critical entities under Directive (EU) 2022/2557; by laying down rules on cybersecurity information sharing; and by setting supervisory and enforcement obligations on Member States. **Explanation** Article 1 frames NIS2 as an internal-market measure: cybersecurity is treated as a precondition for the free movement of digital services across the EU, not as a national-security carve-out. The four pillars introduced here — national capability, entity-level obligations, information sharing, and supervision/enforcement — recur throughout the rest of the text and should be used as the top-level structure for any NIS2 readiness programme. #### Article 2 — Scope **Description** Article 2 defines who falls within the Directive. It applies to public or private entities of a type listed in Annex I or II that qualify as medium-sized enterprises under Recommendation 2003/361/EC, or that exceed those ceilings (the size-cap rule). Regardless of size, the Directive also applies to providers of public electronic communications networks or services, trust service providers, TLD name registries, DNS service providers, sole providers of an essential service in a Member State, entities whose disruption would significantly impact public safety/security/health or induce systemic risk, entities critical at national or regional level, central-government public administration entities, entities providing domain name registration services, and entities identified as critical under Directive (EU) 2022/2557. Member States may extend scope to local public administration and education institutions carrying out critical research. Article 2 also lists carve-outs: it does not apply to public administration entities operating in national security, public security, defence or law enforcement; Member States may exempt specific entities active in those areas from Articles 21 and 23; financial entities exempted from [Regulation (EU) 2022/2554](https://clateway.com/glossary/dora) (DORA) by Member States are out of scope. Information disclosure that would harm essential national-security interests is not required, and the Directive applies without prejudice to [GDPR](https://clateway.com/glossary/gdpr), the ePrivacy Directive, and other listed instruments. **Explanation** This is the most consequential single article for scoping. The size-cap rule means that any organisation in an Annex I or II sector with 50+ employees or more than EUR 10 million turnover and balance sheet total is in scope by default — a vast expansion compared with NIS1's identification-driven approach. The 'regardless of size' triggers (sole provider, systemic risk, critical at regional level, central government, DNS/TLD/trust services) catch small but strategically important organisations that the size cap would otherwise miss. Compliance projects should produce a formal scoping memo that walks each criterion in turn and that documents reasons for inclusion or exclusion, because supervisory authorities will expect this trail. **Practical scoping** Run the test in this order: (1) Is the entity in an Annex I or II sector? (2) Does it meet the size threshold? (3) If not, does any 'regardless of size' trigger apply? (4) Is it a critical entity under CER (2022/2557)? (5) Does Article 2(7)–(10) carve it out? Document the answer to each and store it as the foundation of the compliance file. #### Article 3 — Essential and important entities **Description** Article 3 establishes the two-tier classification. Essential entities include: Annex I entities exceeding the medium-sized enterprise ceilings; qualified trust service providers, TLD name registries and DNS service providers regardless of size; medium-sized providers of public electronic communications networks or services; central-government public administration entities; any entity identified by a Member State under Article 2(2)(b)–(e); entities identified as critical under CER; and, optionally, operators of essential services previously identified under NIS1. All other in-scope entities are important entities. By 17 April 2025, Member States must establish a list of essential and important entities (and entities providing domain name registration services), reviewed at least every two years, and entities must submit identifying information (name, address, contact details, sector, list of Member States served). Member States must notify aggregate numbers to the Commission and Cooperation Group. **Explanation** The essential/important distinction governs the supervisory regime (Articles 32 vs 33), the maximum administrative fine (EUR 10m / 2% vs EUR 7m / 1.4%), and the level of attention the entity should expect from regulators. Entities should determine their classification early because it changes the cost and shape of the compliance programme. Registration with the competent authority is itself an obligation — failure to register is itself a breach — and contact details must be kept current within two weeks of any change. #### Article 4 — Sector-specific Union legal acts **Description** Where a sector-specific Union legal act imposes cybersecurity risk-management or incident-reporting obligations that are at least equivalent in effect to those in NIS2, those sectoral provisions apply instead, including their supervision and enforcement framework. Equivalence requires that risk-management measures be at least equivalent to Article 21(1) and (2), and that reporting requirements be at least equivalent to Article 23(1)–(6) with immediate (and where appropriate automatic and direct) access to notifications by the NIS2 competent authority. The Commission was required to publish guidelines clarifying application by 17 July 2023. **Explanation** Article 4 is the lex specialis bridge. Its most prominent application is DORA (Regulation (EU) 2022/2554) for financial entities: NIS2 obligations on risk management, reporting, supervision and enforcement do not apply to DORA-covered financial entities; DORA's equivalents do. Aviation entities likewise interact with Regulations (EC) 300/2008 and (EU) 2018/1139. Mapping which legal regime applies to which entity inside a financial group is itself a non-trivial exercise and is best resolved before risk-management programmes are designed. #### Article 5 — Minimum harmonisation **Description** Member States may adopt or maintain provisions ensuring a higher level of cybersecurity than NIS2 prescribes, provided they are consistent with Union law. **Explanation** NIS2 sets a floor, not a ceiling. National transposition will diverge in detail — some Member States set lower fine thresholds, narrower or wider scope extensions to local public administration and education, additional reporting channels, or additional sector inclusions. Multinationals must build a comparison matrix of national transposition laws across the Member States in which they operate, rather than relying on the Directive text alone. #### Article 6 — Definitions **Description** Article 6 sets out 41 numbered definitions used throughout the Directive. Key terms include: network and information system; security of network and information systems; cybersecurity (cross-referencing the Cybersecurity Act); near miss (an event that could have compromised availability, authenticity, integrity or confidentiality but did not); incident (an event that did compromise these properties); large-scale cybersecurity incident (one that exceeds a Member State's response capacity or significantly impacts at least two Member States); incident handling; risk; cyber threat; significant cyber threat; ICT product, service and process; vulnerability; standard; technical specification; internet exchange point; DNS, DNS service provider, TLD name registry, entity providing domain name registration services; trust service and provider, qualified trust service and provider; online marketplace; online search engine; cloud computing service; data centre service; content delivery network; social networking services platform; representative; public administration entity; public electronic communications network; electronic communications service; entity; managed service provider; managed security service provider; research organisation. **Explanation** The definitions deserve close reading because they operationalise scope. The introduction of 'near miss' is particularly important: NIS2 expects entities to recognise events that could have caused harm even when they did not, which raises the bar on detection and root-cause analysis. The cloud computing service definition deliberately captures IaaS, PaaS, SaaS and NaaS across private, community, public and hybrid models, and the data centre service definition captures non-cloud colocation. Managed service provider and managed security service provider are formally defined and brought directly within scope, anchoring supply-chain accountability. Where a definition cross-references another instrument (e.g. trust service to eIDAS, or cybersecurity to the Cybersecurity Act), the cross-referenced text is binding. ### Chapter II — Coordinated Cybersecurity Frameworks Chapter II places obligations on Member States to build the institutional infrastructure that NIS2 depends on: a national strategy, competent authorities, a single point of contact, a cyber crisis management authority, CSIRTs, a coordinated vulnerability disclosure framework, and national-level cooperation between all of the above. #### Article 7 — National cybersecurity strategy **Description** Each Member State must adopt a national cybersecurity strategy setting out strategic objectives, resources required, and policy and regulatory measures. The strategy must address: objectives and priorities (covering the Annex I and II sectors), governance frameworks, asset identification and risk assessment mechanisms, preparedness/response/recovery measures, the list of authorities and stakeholders, coordination with the CER framework, and a plan to raise general cybersecurity awareness. It must include policies on supply-chain cybersecurity, public procurement cybersecurity requirements, vulnerability management and coordinated disclosure, sustaining the public core of the open internet (including undersea cables), advanced technologies, education and skills, support for academia and research, voluntary information sharing, support for SMEs excluded from NIS2 scope, and active cyber protection. National strategies must be notified to the Commission within three months of adoption and reassessed at least every five years. **Explanation** Article 7 elevates national cybersecurity from a policy aspiration to a structured deliverable. For multinationals it is a useful map: it tells you, per Member State, which authorities you will be dealing with, how supply-chain expectations are framed nationally, what active-cyber-protection services may be available for free, and what the SME baseline guidance looks like. National strategies are also where national choices on local public administration scope, education-sector inclusion, and undersea-cable mapping become explicit. #### Article 8 — Competent authorities and single points of contact **Description** Each Member State must designate or establish one or more competent authorities responsible for cybersecurity and the supervisory tasks under Chapter VII, and a single point of contact (SPOC) for cross-border cooperation. Where there is only one competent authority, it doubles as the SPOC. Member States must give competent authorities and SPOCs adequate resources, notify the Commission of their identities and tasks, make the competent authority public, and the Commission publishes the SPOC list. **Explanation** The SPOC is the entity's primary cross-border interface. For organisations operating in several Member States, knowing each SPOC and each competent authority is essential — particularly because Article 26 establishes that DNS providers, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplace, search engine, and social networking entities fall under a single jurisdiction (the main establishment), while most other entities are subject to concurrent jurisdiction in each Member State where they operate. #### Article 9 — National cyber crisis management frameworks **Description** Each Member State must designate one or more cyber crisis management authorities to handle large-scale cybersecurity incidents and crises, with a designated coordinator if there is more than one. Member States must identify deployable capabilities, assets and procedures, and adopt a national large-scale cybersecurity incident and crisis response plan setting out objectives, responsibilities, procedures (including integration with general national crisis management and information exchange channels), preparedness measures, stakeholders, and arrangements for participating in coordinated EU-level response. The Commission and EU-CyCLONe must be notified within three months. **Explanation** Article 9 connects national capability with EU-CyCLONe (Article 16). For entities, it matters because an incident that triggers national crisis-management procedures will sit alongside the entity's own incident response — entities should know in advance who their crisis-management counterpart is and how the national plan envisages industry cooperation. #### Article 10 — Computer Security Incident Response Teams (CSIRTs) **Description** Each Member State must designate or establish one or more CSIRTs covering at least the Annex I and II sectors. CSIRTs may sit within a competent authority. They must comply with the requirements in Article 11(1), be responsible for incident handling under a well-defined process, and have adequate resources and a secure, resilient communication infrastructure. CSIRTs cooperate with sectoral or cross-sectoral communities of essential and important entities, participate in peer reviews, cooperate effectively in the CSIRTs network, and may establish relationships with third-country teams (subject to GDPR for personal data). **Explanation** The CSIRT is the operational counterpart for entities during incidents — it receives notifications under Article 23, provides initial feedback within 24 hours, can offer technical assistance, and can perform proactive scans on request. Building a working relationship with the relevant national CSIRT before an incident is sound practice. #### Article 11 — Requirements, technical capabilities and tasks of CSIRTs **Description** CSIRTs must ensure high-availability communication channels, secure premises and supporting systems, request-management systems, confidential and trustworthy operations, adequate trained staff, redundancy and continuity. They must monitor and analyse threats, vulnerabilities and incidents at national level; provide early warnings, alerts and information dissemination; respond to incidents and assist entities; collect and analyse forensic data; perform proactive scanning at the entity's request; participate in the CSIRTs network; act as coordinator for coordinated vulnerability disclosure where applicable; and contribute to deploying secure information-sharing tools. They may carry out non-intrusive proactive scans of publicly accessible systems of essential and important entities, prioritising tasks via a risk-based approach. **Explanation** The proactive scanning provisions are a meaningful capability shift: CSIRTs can scan publicly accessible perimeter for misconfigurations and vulnerabilities and notify the entity. Entities should anticipate this by ensuring that their external attack-surface inventory is current and that intake processes for CSIRT findings are defined. #### Article 12 — Coordinated vulnerability disclosure and a European vulnerability database **Description** Each Member State designates one of its CSIRTs as coordinator for coordinated vulnerability disclosure (CVD). The coordinator acts as trusted intermediary between vulnerability reporters and the manufacturer/provider of the affected ICT product or service: identifying and contacting affected entities, assisting reporters, and negotiating disclosure timelines (including multi-party CVD across Member States via the CSIRTs network). Reporters may report anonymously. ENISA develops and maintains a European vulnerability database where entities and their suppliers can voluntarily register and disclose publicly known vulnerabilities, including a description, affected products/services and severity, and the availability of patches or mitigation guidance. **Explanation** Article 12 establishes a European backbone for CVD. For software vendors and component manufacturers it formalises a process that many already follow voluntarily under ISO/IEC 30111 and 29147, and creates a central EU-managed database alongside the established [CVE](https://clateway.com/glossary/cve) system. For entities, it creates a trusted route for receiving vulnerability reports from external researchers. #### Article 13 — Cooperation at national level **Description** Where they are separate, the competent authority, SPOC and CSIRT of the same Member State must cooperate. Member States must ensure that CSIRTs (or competent authorities) receive significant-incident notifications under Article 23 and voluntary notifications under Article 30, and inform the SPOC of these. Cooperation must also extend to law enforcement, data protection authorities, aviation authorities, eIDAS supervisory bodies, DORA competent authorities, EECC national regulatory authorities, CER competent authorities, and other sectoral authorities. CER and NIS2 competent authorities must regularly exchange information on critical-entity identification, risks, threats, incidents and response measures. Reporting must be simplified through technical means. **Explanation** Article 13 prevents the regulatory landscape from fragmenting at national level. For entities, it means that information given to one authority is likely to be shared with others where lawful, including data protection authorities when an incident has personal-data implications — which directly affects how the GDPR Article 33 and NIS2 Article 23 notifications are coordinated. ### Chapter III — Cooperation at Union and International Level Chapter III creates the EU-level cooperation architecture: the Cooperation Group (strategy), the CSIRTs network (operations), and EU-CyCLONe (crisis), as well as the framework for international cooperation, the biennial state-of-cybersecurity report, and peer reviews. #### Article 14 — Cooperation Group **Description** The Cooperation Group is established to support strategic cooperation, exchange of information, and trust-building among Member States. It is composed of representatives of Member States, the Commission and ENISA, with the EEAS as observer and the ESAs and DORA competent authorities able to participate. It works on biennial work programmes (first by 1 February 2024). Its tasks span guidance to competent authorities; sharing best practices; exchanging advice with the Commission on emerging policy and on draft delegated/implementing acts; coordinated security risk assessments of critical supply chains (Article 22); discussion of mutual-assistance cases; strategic guidance to the CSIRTs network and EU-CyCLONe; methodology for peer reviews and self-assessment; reporting for the periodic Commission review (Article 40); regular threat-landscape assessments such as ransomware. The Commission may adopt implementing acts on procedural arrangements. The Group meets at least annually with the Critical Entities Resilience Group under CER. **Explanation** The Cooperation Group is where the strategic shape of NIS2 implementation is set. Its work programmes, guidance and supply-chain risk assessments materially affect what 'state of the art' means under Article 21. Tracking its outputs — particularly NIS Cooperation Group publications such as the EU 5G toolbox and successor documents — is part of staying current. #### Article 15 — CSIRTs network **Description** The CSIRTs network connects national CSIRTs and CERT-EU, with ENISA providing the secretariat and the Commission as observer. Tasks include exchanging CSIRT capability information, sharing technology, tools, best practices and frameworks; exchanging information on incidents, near misses, threats, risks and vulnerabilities; supporting interoperability; discussing and implementing coordinated cross-border incident responses on member request; providing assistance with cross-border incidents; supporting CVD coordinator CSIRTs in multi-Member-State cases; cooperating with regional and Union-level Security Operations Centres; and providing biennial reports on operational cooperation progress for Article 40 reviews. **Explanation** The CSIRTs network is the operational engine. For entities, it is what makes cross-border incident handling work: when an incident in one Member State affects entities or infrastructure in another, the network is the channel through which information moves between national CSIRTs. #### Article 16 — European cyber crisis liaison organisation network (EU-CyCLONe) **Description** EU-CyCLONe is established to coordinate the management of large-scale cybersecurity incidents and crises at operational level. It is composed of Member States' cyber crisis management authorities, with the Commission as participant in cases with significant impact on services and activities in NIS2 scope and as observer otherwise. ENISA provides the secretariat. Tasks include preparedness, shared situational awareness, impact assessment and mitigation proposals, coordination of crisis management, and supporting political-level decision-making. EU-CyCLONe reports to the Cooperation Group and submits an assessment of its work to the European Parliament and Council every 18 months from 17 July 2024. **Explanation** EU-CyCLONe sits between the technical CSIRTs network and the political IPCR arrangements, providing the operational layer for crisis decision-making. Its existence is the EU's institutional answer to the lessons of major cross-border incidents (NotPetya, SolarWinds, Log4j) where coordination across Member States lagged the speed of the threat. #### Article 17 — International cooperation **Description** The Union may conclude international agreements with third countries or international organisations, in accordance with Article 218 TFEU, allowing them to participate in particular activities of the Cooperation Group, the CSIRTs network and EU-CyCLONe. Such agreements must comply with Union data protection law. **Explanation** Article 17 keeps the door open for structured cooperation with non-EU partners — relevant for EEA neighbours, NATO partners, and like-minded third countries — while subordinating any data exchange to GDPR/EUDPR transfer rules. #### Article 18 — Report on the state of cybersecurity in the Union **Description** ENISA, with the Commission and Cooperation Group, must adopt a biennial report on the state of cybersecurity in the Union and present it to the European Parliament. The report must include a Union-level cybersecurity risk assessment, an assessment of public and private cybersecurity capabilities, an assessment of cyber awareness and hygiene among citizens and entities (including SMEs), an aggregated assessment of peer-review outcomes, and an aggregated assessment of cybersecurity maturity at Union and sectoral level (including alignment of national strategies). It must contain policy recommendations and a summary of ENISA's EU Cybersecurity Technical Situation Reports. **Explanation** The biennial report is the most authoritative public picture of how NIS2 implementation is going across the Union. For boards, it is a useful external benchmark for internal cybersecurity maturity discussions. #### Article 19 — Peer reviews **Description** By 17 January 2025 the Cooperation Group had to establish a methodology and organisational arrangements for peer reviews. Participation is voluntary. Peer reviews are carried out by cybersecurity experts designated by at least two other Member States and may cover: implementation of risk-management measures and reporting obligations under Articles 21 and 23; the capabilities and effectiveness of competent authorities; CSIRT operational capabilities; mutual-assistance implementation; information-sharing arrangements implementation; or specific cross-border or cross-sector issues. The methodology covers expert designation criteria, self-assessment, on-site or virtual visits and off-site exchanges, conflict-of-interest management, codes of conduct, confidentiality, and reports with recommendations (which the reviewed Member State may publish in full or redacted form). **Explanation** Peer reviews introduce a soft accountability mechanism between Member States, building on the OECD-style approach of structured mutual evaluation. They are voluntary, but the resulting reports — when published — provide useful evidence of national maturity that entities can use in jurisdictional risk decisions. ### Chapter IV — Cybersecurity Risk-Management Measures and Reporting Obligations Chapter IV is the operational heart of the Directive for in-scope entities. It defines management-body accountability (Article 20), the catalogue of risk-management measures (Article 21), Union-level coordinated supply-chain risk assessments (Article 22), the multi-stage incident reporting regime (Article 23), the use of cybersecurity certification schemes (Article 24), and the role of standardisation (Article 25). #### Article 20 — Governance **Description** Member States must ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by the entity to comply with Article 21, oversee implementation, and can be held liable for infringements of Article 21 by the entity. Members of management bodies must follow training, and entities are encouraged to offer similar training to employees, sufficient to identify risks, assess risk-management practices, and understand their impact on services. **Explanation** Article 20 is a structural change in cybersecurity governance: it pushes accountability up to the board. The text refers to liability for infringements 'by the entity' of Article 21, which national transpositions translate into different forms of director liability — administrative, civil, or in some cases personal. Boards must approve the cybersecurity risk-management programme, oversee it (which means receiving meaningful reporting against it), and undergo training. In practice this means a documented governance structure: who approves the policies, how often, what the reporting cadence is, what training the board has had and when. This connects directly to RCEC's Commit and Control disciplines. **Board accountability checklist** (1) Documented board approval of the cybersecurity risk-management framework. (2) Regular board reporting (typically quarterly) covering risks, incidents, near misses, third-party assurance and remediation status. (3) Annual board cybersecurity training, with attendance recorded. (4) Clear delineation of management-body vs executive vs operational responsibilities. (5) Director-and-officer insurance and indemnity reviewed against national transposition. #### Article 21 — Cybersecurity risk-management measures **Description** Essential and important entities must take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to network and information systems used in their operations or service provision, and to prevent or minimise the impact of incidents on service recipients and other services. Measures must reflect the state of the art, relevant European and international standards, and the cost of implementation, with proportionality assessed against exposure to risk, entity size, and likelihood and severity of incidents. Measures must follow an all-hazards approach and include at minimum: (a) policies on risk analysis and information system security; (b) incident handling; (c) business continuity, including backup management, disaster recovery and crisis management; (d) supply-chain security, including direct supplier and service-provider relationships; (e) security in network and information system acquisition, development and maintenance, including vulnerability handling and disclosure; (f) policies and procedures to assess effectiveness; (g) basic cyber hygiene practices and cybersecurity training; (h) cryptography and, where appropriate, encryption; (i) human-resources security, access-control policies and asset management; (j) multi-factor or continuous authentication, secured voice/video/text and emergency communication, where appropriate. When considering supply-chain measures, entities must take into account vulnerabilities specific to each direct supplier and service provider, the overall quality of products and cybersecurity practices of suppliers (including secure-development procedures), and the results of any Article 22 coordinated security risk assessment. Where an entity finds non-compliance, it must take corrective measures without undue delay. By 17 October 2024 the Commission had to adopt implementing acts laying down technical and methodological requirements for DNS providers, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplaces, online search engines, social networking platforms, and trust service providers; further sectoral implementing acts may follow. **Explanation** Article 21 is the operative control set. The ten domains are deliberately framed in outcome terms rather than as a checklist of specific controls — entities are expected to map them to a recognised framework ([ISO/IEC 27001](https://clateway.com/glossary/iso-27001), IEC 62443, NIST CSF, sector standards) and demonstrate appropriate, proportionate and state-of-the-art implementation. The all-hazards framing is important: physical, environmental, human-error and natural-phenomena risks are inside scope alongside cyberattacks. Supply-chain security under (d) explicitly captures direct supplier and service-provider risk and connects to Article 22 coordinated assessments — meaning supplier-tier-1 cybersecurity due diligence and contracting are mandatory, not optional. The Commission's implementing act of October 2024 ((EU) 2024/2690) operationalises these requirements for the digital-infrastructure and digital-providers categories with substantially more concrete requirements. Entities in those categories should treat that implementing act, not Article 21 alone, as the relevant control specification. #### Article 22 — Union-level coordinated security risk assessments of critical supply chains **Description** The Cooperation Group, with the Commission and ENISA, may carry out coordinated security risk assessments of specific critical ICT services, ICT systems or ICT product supply chains, taking into account technical and where relevant non-technical risk factors. The Commission, after consulting the Cooperation Group, ENISA and stakeholders, identifies the specific items eligible for such assessment. **Explanation** Article 22 generalises the model used in the EU 5G coordinated risk assessment to other critical ICT supply chains. The output of any such assessment becomes a mandatory input for entity-level supply-chain risk decisions under Article 21(3). Procurement, [vendor risk management](https://clateway.com/glossary/third-party-risk-management) and architecture decisions should anticipate that designated technologies may carry mandatory mitigating measures (e.g. restrictions on use in sensitive functions) once the assessment process concludes. #### Article 23 — Reporting obligations **Description** Essential and important entities must notify their CSIRT (or competent authority) of any incident having a significant impact on the provision of their services — a 'significant incident'. An incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss to the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Where appropriate, entities must also notify recipients of services likely to be adversely affected, and where likely to materialise, must inform recipients of significant cyber threats and remedies. Reporting follows a multi-stage timeline: (a) early warning within 24 hours of becoming aware of the incident — indicating, where applicable, suspicion of unlawful or malicious cause and possible cross-border impact; (b) incident notification within 72 hours, updating the early warning and providing initial severity, impact and indicators of compromise; (c) intermediate report on relevant status updates upon CSIRT/competent-authority request; (d) final report no later than one month after the incident notification, including detailed description, type of threat or root cause, applied and ongoing mitigation measures, and any cross-border impact; (e) progress report instead of final report if the incident is ongoing at the one-month mark, with a final report one month after handling concludes. Trust service providers must, by derogation, notify within 24 hours. CSIRTs/competent authorities must respond — where possible within 24 hours of the early warning — with initial feedback and, on request, mitigation guidance and additional technical support; they must also signpost law-enforcement reporting where criminal nature is suspected. Cross-border incidents must be communicated to other affected Member States and ENISA. The CSIRT or competent authority may, after consulting the entity, inform the public when public awareness is needed. SPOCs submit quarterly anonymised aggregated summary reports to ENISA, which informs the Cooperation Group and CSIRTs network every six months. CSIRTs share information with CER competent authorities about critical entities. The Commission may adopt implementing acts further specifying the form and procedure of notifications, and by 17 October 2024 had to specify when an incident is significant for the digital-infrastructure and digital-providers categories. **Explanation** Article 23 is the most operationally demanding provision in the Directive. The 24/72-hour cadence requires a rehearsed, role-based incident-reporting playbook with templates for each stage, clarity about what counts as 'becoming aware', and a triage process for significance. Many entities will need to redesign their incident classification and SLA frameworks so that significance assessment can be reliably made early in an incident, often before root cause is known. The recipient-notification obligation is separate from GDPR Article 34 — the trigger is impact on the service, not breach of personal data, although they often coincide. Implementing Regulation (EU) 2024/2690 sets concrete significance thresholds for digital-infrastructure and digital-provider entities. For other sectors, national transposition typically supplies guidance. Build the playbook against both the Directive text and the relevant implementing acts. **The 24-72-30 cadence** Hour 0: incident handling begins. Hour 24: early warning to CSIRT (suspected unlawful/malicious? cross-border impact?). Hour 72: incident notification (severity, impact, IoCs). Day 30 from notification: final report (description, root cause, mitigation, cross-border impact) — or progress report + final on closure if still active. Trust service providers: incident notification at hour 24, not 72. #### Article 24 — Use of European cybersecurity certification schemes **Description** Member States may require essential and important entities to use particular ICT products, services and processes — developed in-house or procured — that are certified under European cybersecurity certification schemes adopted under the Cybersecurity Act (Regulation (EU) 2019/881). Member States must also encourage the use of qualified trust services. The Commission is empowered to adopt delegated acts (under Article 38) specifying which categories of essential and important entities must use such certified products, services or processes, where insufficient cybersecurity levels have been identified, including an implementation period; an impact assessment and consultations under the Cybersecurity Act are required first. Where no appropriate scheme exists, the Commission may request ENISA to prepare a candidate scheme. **Explanation** Article 24 ties NIS2 to the EU's growing certification ecosystem (EUCC for ICT products, EUCS for cloud, EU5G, etc.). For now, certification under these schemes is voluntary by default, but the delegated-act mechanism means specific entity categories may be required to use certified components in the future. Procurement strategies should anticipate that EU-certified options will progressively become the default, with cost and lead-time implications. #### Article 25 — Standardisation **Description** To promote convergent implementation of Article 21(1) and (2), Member States must encourage the use of European and international standards and technical specifications relevant to network and information system security, without imposing or discriminating in favour of any particular technology. ENISA, with Member States and stakeholders, draws up advice and guidelines on the technical areas and existing standards (including national ones). **Explanation** Article 25 enshrines technology neutrality while pulling implementations toward recognised standards — ISO/IEC 27001, ISO/IEC 27005, ISO/IEC 22301, IEC 62443, ETSI EN 303 645, and others. Choosing a recognised standard as the operating framework simplifies audit and supervisory dialogue. ### Chapter V — Jurisdiction and Registration Chapter V resolves the cross-border question — which Member State regulates which entity — and creates registration obligations, including the dedicated WHOIS-style domain-name registration data regime. #### Article 26 — Jurisdiction and territoriality **Description** Entities fall under the jurisdiction of the Member State in which they are established, except: (a) providers of public electronic communications networks or services fall under the jurisdiction of the Member State in which they provide their services; (b) DNS service providers, TLD name registries, entities providing domain name registration services, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms fall under the jurisdiction of the Member State of their main establishment in the Union; (c) public administration entities fall under the jurisdiction of the Member State that established them. Main establishment is determined by where decisions on cybersecurity risk-management measures are predominantly taken; failing that, where cybersecurity operations are carried out; failing that, where the entity has the highest number of employees in the Union. Entities under (b) not established in the Union but offering services in the Union must designate a representative in a Member State where services are offered. **Explanation** Article 26 introduces a single-jurisdiction model for the digital-infrastructure and digital-provider categories, mirroring the GDPR's one-stop-shop logic. For most other entities, jurisdiction is concurrent: an entity providing services across multiple Member States is subject to each of those Member States' competent authorities. The 'main establishment' analysis must be documented — particularly the location of decision-making on cybersecurity risk management — because it directly determines the competent authority and applicable national transposition law. For non-EU providers in category (b), designating a Union representative is mandatory and the representative's location determines jurisdiction. #### Article 27 — Registry of entities **Description** ENISA creates and maintains a registry of DNS service providers, TLD registries, entities providing domain name registration services, cloud, data centre, CDN, MSP, MSSP, online marketplace, online search engine and social networking services platform providers, based on information received from SPOCs. By 17 January 2025, Member States must require those entities to submit name; relevant sector, subsector and type of entity; address of main establishment and other Union legal establishments (or representative if not Union-established); contact details (email, phone) of entity and representative; Member States in which the entity provides services; and the entity's IP ranges. Changes must be notified within three months. SPOCs forward this information to ENISA except IP ranges. **Explanation** Article 27 creates a central registry that allows ENISA and competent authorities to track the digital-infrastructure population of NIS2. For entities in scope of Article 27, the obligation is administrative but non-trivial: it requires accurate inventories of legal entities, IP ranges, and Member-State coverage that some organisations do not currently maintain in a single place. #### Article 28 — Database of domain name registration data **Description** TLD name registries and entities providing domain name registration services must collect and maintain accurate and complete domain-name registration data in a dedicated database, with due diligence and in compliance with Union data protection law. The database must contain at minimum: domain name; registration date; registrant name, contact email and telephone; and contact email and telephone of the point of contact administering the domain (if different from the registrant). Registries and providers must have publicly available verification policies and procedures; must without undue delay publish non-personal registration data; must provide access to specific personal registration data to legitimate access seekers on lawful and substantiated requests within 72 hours; and must publish disclosure policies. Duplication of collection is not required; cooperation between registries and providers is mandatory. **Explanation** Article 28 is the EU's answer to the post-GDPR collapse of the public WHOIS. It rebalances DNS transparency against data protection by establishing a structured access regime: non-personal data are public, personal data are accessible to legitimate access seekers (law enforcement, CERT/CSIRTs, cybersecurity researchers in some interpretations) on substantiated request, with a 72-hour SLA. Implementation has been the subject of significant ICANN, registrar and registry attention and remains an evolving area of practice. ### Chapter VI — Information Sharing Chapter VI sets the rules for voluntary cybersecurity information sharing — both peer-to-peer between entities and from entities (and non-NIS2 organisations) to the authorities. #### Article 29 — Cybersecurity information-sharing arrangements **Description** Member States must ensure that NIS2 entities — and where relevant, non-NIS2 entities — can voluntarily exchange relevant cybersecurity information among themselves, including threat information, near misses, vulnerabilities, TTPs, IoCs, threat-actor information, alerts and tooling configuration recommendations. Such sharing must aim to prevent, detect, respond to or recover from incidents or mitigate their impact, or to enhance overall cybersecurity. Sharing must take place within communities of essential and important entities and where relevant their suppliers and service providers, through cybersecurity information-sharing arrangements that respect the sensitivity of shared information. Member States must facilitate the establishment of such arrangements (including through dedicated ICT platforms and automation tools), and may impose conditions on information made available by competent authorities or CSIRTs. Entities must notify competent authorities of their participation, and of any withdrawal. ENISA supports the establishment of such arrangements. **Explanation** Article 29 legitimises and structures private-sector ISAC-style cooperation. Many sectors (financial services, energy, automotive) already have mature ISACs; Article 29 brings them under a recognised legal umbrella, addresses competition-law and liability concerns that have historically inhibited sharing, and formalises the role of competent authorities and ENISA in facilitating it. Joining or forming a relevant ISAC or sectoral CTI community is a defensible and increasingly expected element of an Article 21 programme. #### Article 30 — Voluntary notification of relevant information **Description** In addition to mandatory notifications under Article 23, voluntary notifications may be submitted to CSIRTs (or competent authorities) by: (a) essential and important entities, regarding incidents, cyber threats and near misses; (b) other entities (whether or not in NIS2 scope), regarding significant incidents, cyber threats and near misses. Such notifications are processed under the Article 23 procedure and may be deprioritised relative to mandatory notifications. Voluntary reporting must not result in additional obligations the notifying entity would not otherwise have. **Explanation** Article 30 creates a safe harbour for voluntary disclosure that encourages early sharing of weak signals — near misses, threat observations, supply-chain compromises affecting non-NIS2 entities — without penalising the reporter. For mature security operations, building voluntary CSIRT engagement into the standard playbook (especially around near misses and threats observed but not yet materialised) increases the value of the relationship before a mandatory-reporting incident arrives. ### Chapter VII — Supervision and Enforcement Chapter VII defines the supervisory toolkit, the differentiated regimes for essential vs important entities, the enforcement powers of competent authorities, the framework for administrative fines, the relationship with GDPR enforcement, mutual assistance, and the cross-cutting principle that all measures must be effective, proportionate and dissuasive. #### Article 31 — General aspects concerning supervision and enforcement **Description** Member States must ensure that competent authorities effectively supervise and take measures necessary to ensure compliance. Authorities may prioritise supervisory tasks based on a risk-based approach, including establishing supervisory methodologies. Authorities must cooperate closely with GDPR supervisory authorities for incidents resulting in personal-data breaches. For public administration entities, supervisory powers must be exercised with operational independence, in line with national legislative and institutional frameworks; appropriate, proportionate and effective measures may be imposed. **Explanation** Article 31 sets the supervisory tone: risk-based, cooperative across regulators, and adapted to the public sector. The risk-based prioritisation language is significant — competent authorities are not expected to audit everyone every year, but to focus their resources on the highest-risk entities and questions. #### Article 32 — Supervisory and enforcement measures in relation to essential entities **Description** Supervisory measures applicable to essential entities include: on-site inspections and off-site supervision (including random checks); regular and targeted security audits by an independent body or competent authority; ad-hoc audits; security scans on objective non-discriminatory criteria; requests for information necessary to assess risk-management measures (including documented policies); requests for data, documents and information needed for supervision; requests for evidence of cybersecurity policy implementation (e.g. audit results). Costs of targeted independent audits are borne by the audited entity unless duly substantiated otherwise. Enforcement powers include: warnings; binding instructions or remediation orders, including time limits; cease-and-desist orders; orders to bring risk-management or reporting into compliance; orders to inform affected service recipients of significant cyber threats and remedies; orders to implement audit recommendations within a reasonable deadline; designation of a monitoring officer with defined tasks and duration; orders to publish aspects of infringements; and administrative fines under Article 34. Where measures (a)–(d) and (f) are ineffective, competent authorities may set a remediation deadline and, on failure, (i) suspend (or request the suspension of) certifications or authorisations covering part or all of the relevant services or activities; or (ii) request that bodies, courts or tribunals temporarily prohibit any natural person responsible at CEO or legal-representative level from exercising managerial functions in the entity. Suspensions and prohibitions apply only until remediation is complete, with appropriate procedural safeguards. These last-resort measures do not apply to public administration entities. Natural persons responsible for or representing an essential entity have the power and duty to ensure compliance and may be held liable for breach of those duties. Enforcement measures must be motivated and preceded by notification of preliminary findings, with reasonable time to submit observations. Authorities must inform CER competent authorities, and where DORA-relevant, the Oversight Forum, when exercising powers over critical entities or critical ICT third-party service providers. **Explanation** Article 32 is unusually muscular for a sectoral cybersecurity instrument. The combination of mandatory audits, binding instructions, monitoring-officer designation, public disclosure of infringements, suspension of authorisations, and temporary CEO/legal-representative prohibitions gives competent authorities the means to compel remediation in a way NIS1 lacked. The temporary management ban is particularly notable and is a meaningful personal-liability mechanism — it does not require criminal conviction, only administrative determination after due process and other measures having failed. #### Article 33 — Supervisory and enforcement measures in relation to important entities **Description** Important entities are subject to ex post supervision: when authorities receive evidence, indication or information that they may not be complying with the Directive, they must take action through ex post supervisory measures that are effective, proportionate and dissuasive. Supervisory powers include on-site inspections and ex post off-site supervision; targeted security audits by independent body or authority; security scans; requests for information to assess ex post risk-management compliance; requests for data, documents and information for supervision; requests for evidence of policy implementation. Enforcement powers parallel essential-entity measures (warnings, binding instructions, cease-and-desist, compliance orders, recipient-notification orders, audit-recommendation implementation orders, public-disclosure orders, administrative fines). The last-resort suspension and management-ban measures of Article 32(5) do not apply to important entities. **Explanation** The essential vs important distinction has direct supervisory consequences: important entities face a lighter, reactive regime. They are not required to systematically document compliance in advance. But they remain subject to the full Article 21 obligations and to administrative fines (capped lower at EUR 7m / 1.4%). The pragmatic implication: important entities still need a mature programme; they simply face less proactive examination of it unless something flags. #### Article 34 — General conditions for imposing administrative fines on essential and important entities **Description** Administrative fines must be effective, proportionate and dissuasive, taking the circumstances of each case into account. They are imposed in addition to other enforcement measures and decided based on the elements in Article 32(7) (gravity, duration, recidivism, damage, intent or negligence, mitigation, codes of conduct, cooperation). For essential entities, infringements of Article 21 or 23 attract fines of up to at least EUR 10 million or up to at least 2% of total worldwide annual turnover of the undertaking in the preceding financial year, whichever is higher. For important entities the cap is up to at least EUR 7 million or up to at least 1.4% of total worldwide annual turnover, whichever is higher. Periodic penalty payments may be provided for. Member States may decide whether and to what extent fines apply to public administration entities. Where a Member State's legal system does not provide for administrative fines, fines must be imposed by courts or tribunals on the competent authority's initiative, with effective, proportionate and dissuasive equivalent effect. **Explanation** Article 34 brings GDPR-scale fining to cybersecurity. The EUR 10m / 2% (essential) and EUR 7m / 1.4% (important) caps are minimum maximums — Member States may set higher caps. The 'undertaking' concept is the EU competition-law concept, meaning fines can be calculated against a parent group's worldwide turnover, not just the legal entity that breached. This is a meaningful change in financial risk and should drive boards to revisit cybersecurity in the same way GDPR did in 2018. #### Article 35 — Infringements entailing a personal data breach **Description** Where competent authorities become aware that a NIS2 infringement under Articles 21 or 23 may entail a notifiable personal-data breach under GDPR Article 33, they must inform the relevant GDPR supervisory authority without undue delay. If the GDPR authority imposes a fine under GDPR Article 58(2)(i), the NIS2 competent authority cannot impose an Article 34 fine for an infringement arising from the same conduct, but may impose other Article 32(4)/(5) or 33(4) enforcement measures. Cross-border GDPR cases require notification to the GDPR authority in the Member State concerned. **Explanation** Article 35 prevents double-fining for the same conduct under GDPR and NIS2. Practically, an entity facing a major incident with personal-data implications will deal with both authorities; coordination between them is presumed, but the entity should structure its notifications and remediation evidence to satisfy both regimes simultaneously. #### Article 36 — Penalties **Description** Member States must lay down rules on penalties applicable to infringements of national measures adopted under the Directive, ensuring they are effective, proportionate and dissuasive. Member States had to notify these rules to the Commission by 17 January 2025. **Explanation** Article 36 leaves Member States to fill in the framework with national criminal or administrative penalties beyond Article 34 fines. National variation should be expected and must be reviewed in each operating jurisdiction. #### Article 37 — Mutual assistance **Description** Where an entity provides services in more than one Member State, or where its network and information systems are located in another Member State, competent authorities must cooperate and assist each other. Cooperation must include informing other Member States via the SPOC of supervisory or enforcement measures taken; requesting other competent authorities to take such measures; and providing assistance proportionate to the receiving authority's resources on substantiated request, including information requests and supervisory measures (on-site inspections, off-site supervision, targeted security audits). Refusal is permitted only if the requested authority lacks competence, the assistance would be disproportionate, or the request concerns information whose disclosure would be contrary to essential national-security interests. Joint supervisory actions may be carried out by mutual agreement. **Explanation** Article 37 makes cross-border supervision workable. For multinational entities, a supervisory action initiated in one Member State can prompt coordinated action across the others where the entity operates. Centralised cybersecurity governance helps not just for compliance but for orderly response to multi-authority engagement. ### Chapter VIII — Delegated and Implementing Acts Chapter VIII sets the procedural rules under which the Commission may adopt the secondary legislation that fleshes out NIS2. #### Article 38 — Exercise of the delegation **Description** Delegated powers under Article 24(2) (mandatory certification) are conferred on the Commission for five years from 16 January 2023. The European Parliament or Council may revoke the delegation. Before adopting a delegated act the Commission consults experts designated by Member States. Delegated acts enter into force only if neither the Parliament nor the Council objects within two months (extendable by a further two months) of notification. **Explanation** Article 38 is standard EU lawmaking machinery. Its practical importance is in the consultative process: certification mandates will not be sprung on industry without an evidence-based impact assessment and stakeholder consultation, and entities have a structured opportunity to engage. #### Article 39 — Committee procedure **Description** The Commission is assisted by a committee within the meaning of Regulation (EU) No 182/2011, with the examination procedure applying. **Explanation** Article 39 governs the comitology for implementing acts (Articles 14, 21, 23). Implementing Regulation (EU) 2024/2690 was adopted under this procedure and is now binding for the digital-infrastructure and digital-providers categories. ### Chapter IX — Final Provisions #### Article 40 — Review **Description** By 17 October 2027, and every 36 months thereafter, the Commission must review the functioning of the Directive and report to the European Parliament and Council. The review must in particular assess the relevance of the size of entities concerned and the sectors, subsectors and types of entity in Annexes I and II for the functioning of the economy and society in relation to cybersecurity. Cooperation Group and CSIRTs network reports feed the review. A legislative proposal may accompany the report. **Explanation** The review clause anticipates that NIS2's scope will need adjustment as technology and threats evolve. Sectors not currently in Annex I or II — and in particular entities sometimes designated as Very Large Online Platforms under the DSA — are explicit candidates for future inclusion. Entities should treat their NIS2 scoping as a living conclusion rather than a one-time exercise. #### Article 41 — Transposition **Description** Member States had to adopt and publish the measures necessary to comply with the Directive by 17 October 2024 and apply them from 18 October 2024. National measures must reference the Directive at official publication. **Explanation** In practice, transposition has been uneven across Member States. As of the date of this document, several Member States have completed transposition; others have draft or partial transposition; the Commission has issued infringement letters to those significantly behind. Operating organisations should track each relevant national transposition timeline and not rely on the Directive text alone for operational planning. #### Article 42 — Amendment of Regulation (EU) No 910/2014 **Description** Article 19 of eIDAS is deleted with effect from 18 October 2024. **Explanation** eIDAS Article 19 contained the security and notification regime for trust service providers. NIS2 absorbs that regime so trust service providers fall under a single coherent cybersecurity framework rather than two parallel ones. #### Article 43 — Amendment of Directive (EU) 2018/1972 **Description** Articles 40 and 41 of the European Electronic Communications Code (EECC) are deleted with effect from 18 October 2024. **Explanation** The deleted EECC articles were the security and incident-notification provisions for electronic communications providers. Like eIDAS Article 19, they are replaced by NIS2 obligations, unifying the legal regime for telecoms cybersecurity. #### Article 44 — Repeal **Description** Directive (EU) 2016/1148 (NIS1) is repealed with effect from 18 October 2024. References to NIS1 are construed as references to NIS2 in accordance with the correlation table in Annex III. **Explanation** NIS2 fully replaces NIS1. National laws built on NIS1 had to be replaced or substantially rewritten. The correlation table in Annex III is the definitive cross-reference. #### Article 45 — Entry into force **Description** The Directive entered into force on the twentieth day following its publication in the Official Journal — i.e. 16 January 2023. **Explanation** Entry into force is the legal start of the transposition clock; application via national law began 18 October 2024. #### Article 46 — Addressees **Description** The Directive is addressed to the Member States. **Explanation** As a directive — not a regulation — NIS2 binds Member States as to the result to be achieved while leaving form and method to national law. Entities therefore comply with their relevant national transposition act, not directly with the Directive, although the Directive remains the interpretive baseline. ### Annexes ### Annex I — Sectors of high criticality Annex I lists the sectors and entity types whose entities are essential entities (when the size threshold is met or 'regardless of size' criteria apply). The Annex I sectors are: - Energy: electricity (undertakings, DSOs, TSOs, producers, NEMOs, energy storage market participants, recharging-point operators); district heating and cooling; oil (transmission pipelines, production/refining/treatment/storage facilities, central stockholding entities); gas (supply, DSO, TSO, storage, LNG, natural gas undertakings, refining/treatment); hydrogen (production, storage, transmission). - Transport: air (commercial air carriers, airport managing bodies of core network airports and entities operating ancillary installations, ATC operators); rail (infrastructure managers, railway undertakings including those operating service facilities); water (inland/sea/coastal passenger and freight transport companies, port managing bodies and port facilities, VTS operators); road (road authorities responsible for traffic-management control, ITS operators). - Banking: credit institutions. - Financial market infrastructures: trading-venue operators and central counterparties (CCPs). - Health: healthcare providers, EU reference laboratories, R&D entities for medicinal products, basic pharmaceutical and pharmaceutical-preparations manufacturers, manufacturers of medical devices on the public-health-emergency critical list. - Drinking water: suppliers and distributors (excluding non-essential distribution). - Waste water: undertakings collecting, disposing of or treating urban, domestic or industrial waste water (excluding non-essential cases). - Digital infrastructure: IXP providers; DNS service providers (excluding root name servers); TLD name registries; cloud computing service providers; data centre service providers; content delivery network providers; trust service providers; providers of public electronic communications networks; providers of publicly available electronic communications services. - ICT service management (B2B): managed service providers; managed security service providers. - Public administration: central-government public administration entities; regional-level public administration entities (where Member States so determine after risk assessment). - Space: operators of ground-based infrastructure for the provision of space-based services (excluding providers of public electronic communications networks). Explanation: Annex I covers the sectors whose disruption would have the deepest societal and economic impact, and the entities in those sectors that are most central to service continuity. The expanded scope compared with NIS1 is most visible here — district heating/cooling, hydrogen, waste water, space ground infrastructure, MSPs/MSSPs, and public administration are notable additions. ### Annex II — Other critical sectors Annex II lists sectors whose entities are important entities (when the size threshold is met). The Annex II sectors are: - Postal and courier services. - Waste management (where waste management is the principal economic activity). - Manufacture, production and distribution of chemicals (manufacture or distribution of substances or mixtures under the REACH framework). - Production, processing and distribution of food (food businesses engaged in wholesale distribution and industrial production and processing). - Manufacturing: medical devices and in vitro diagnostic medical devices; computer, electronic and optical products (NACE Rev. 2 division 26); electrical equipment (27); machinery and equipment n.e.c. (28); motor vehicles, trailers and semi-trailers (29); other transport equipment (30). - Digital providers: providers of online marketplaces, online search engines, social networking services platforms. - Research: research organisations. Explanation: Annex II captures sectors that are critical but where entities typically face less prescriptive ex ante supervision. It also brings discrete-manufacturing categories under cybersecurity oversight for the first time at EU level — a meaningful change for industrial CIOs who historically operated outside the cybersecurity-regulation perimeter. ### Annex III — Correlation table Annex III is a one-to-one correlation table mapping NIS1 articles to their NIS2 successors. It is intended to make legal continuity workable for legacy references and existing case law. It is not reproduced here in full because it is a structural cross-reference rather than substantive text; readers needing it should consult the Official Journal version. The high-level continuities are: NIS1 Articles 14 and 16 (security and incident-reporting obligations) become NIS2 Article 21 (risk management) and Article 23 (reporting); NIS1 Articles 7 and 8 (national strategy and competent authorities) become NIS2 Articles 7 and 8; NIS1 Article 9 (CSIRTs) becomes NIS2 Articles 10 and 11; NIS1 Article 18 (jurisdiction) becomes NIS2 Article 26; NIS1 Annex II (sectors) becomes NIS2 Annex I; NIS1 Annex III (digital service providers) is largely absorbed into NIS2 Annex II point 6 and Annex I point 8. ### Impact and Scope: A Practical Synthesis ### What changed compared with NIS1 - Scope is uniformly defined by a size-cap rule rather than national identification of operators of essential services — eliminating divergence and dramatically expanding the regulated population. - Sectors and entity types are broader: hydrogen, waste water, space ground infrastructure, MSP/MSSP, food, chemicals, manufacturing categories, postal, research, public administration, and others are now in scope. - Two-tier classification (essential vs important) replaces the operator/digital-service-provider distinction and drives differentiated supervisory regimes. - Risk-management measures are codified as a ten-domain catalogue with an explicit all-hazards approach and explicit supply-chain obligations. - Reporting follows a 24/72/30 cadence with mandatory early warning, notification, intermediate progress reporting, and final report — a step-change from NIS1's looser regime. - Management bodies must approve and oversee the cybersecurity programme and may be held personally liable for the entity's infringements; senior individuals can be temporarily prohibited from managerial functions in essential entities as a last resort. - Administrative fines reach EUR 10m or 2% (essential) and EUR 7m or 1.4% (important) of worldwide annual turnover of the undertaking, with GDPR-style scope and severity. - Cross-border enforcement is structured through SPOCs, the Cooperation Group, the CSIRTs network, EU-CyCLONe, and a clear jurisdictional regime. ### Where the work concentrates for in-scope organisations Across diverse sectors, programme effort tends to concentrate in five areas. First, governance: getting the management body informed, trained, engaged, and on the record approving the programme; rebuilding cybersecurity reporting to the board so that liability is exercised against meaningful information. Second, control programme: mapping the ten Article 21 domains to a recognised standard, running a gap assessment, prioritising remediation against state-of-the-art and proportionality criteria, and maintaining defensible evidence. Third, supply chain: building or reinforcing third-party cybersecurity due diligence, contract clauses, ongoing assurance, and monitoring against Article 22 coordinated assessments. Fourth, incident reporting: rebuilding the playbook around 24/72/30, including a robust significance-assessment process and templates for each notification stage. Fifth, registration and jurisdiction: documenting main establishment, registering with the relevant SPOC/competent authority, maintaining contact information, and tracking national transposition variation across operating jurisdictions. ### How the regulatory ecosystem fits together NIS2 does not stand alone. It is part of an EU regulatory stack that includes the GDPR (data protection), the eIDAS Regulation (trust services, with Article 19 absorbed into NIS2), the Cybersecurity Act (ENISA mandate and certification), DORA (financial sector), the CER Directive (physical resilience of critical entities), the EECC (electronic communications, with Articles 40 and 41 absorbed into NIS2), the Cyber Resilience Act (product cybersecurity), the Digital Services Act and Digital Markets Act, and the AI Act. Compliance programmes that treat NIS2 in isolation will repeatedly rediscover that the same control or process is required by another instrument; integrated programmes that treat the stack as one architecture are materially more efficient. ### How to use this document This reference is structured to be read end-to-end as an onboarding piece, or sampled article-by-article when a specific question arises. The Description sections are deliberately faithful to the legal text so that they can be quoted in internal documents; the Explanation sections are interpretive and should be read alongside, not in place of, the relevant national transposition law. For operational decisions — reporting thresholds, certification mandates, sectoral risk-management specifics — the relevant Commission implementing acts (notably (EU) 2024/2690 for digital infrastructure and digital providers) and national transposition acts must be consulted. — End of document — --- ## The Technology Leadership Platform: a working guide for digital leadership teams URL: https://clateway.com/articles/how-the-modules-fit-together Published: 2026-04-29 · Clateway Technology Council Key takeaways: How the platform's four core base modules — Baseline, Technology Management, Strategy Execution and GRC — fit together, and how a digital leadership team uses them in practice. **CLATEWAY INSIGHTS · MEMBER BRIEFING** **The Technology Leadership Platform: a working guide for digital leadership teams** How the platform's four core base modules — Baseline, Technology Management, Strategy Execution and [GRC](https://clateway.com/glossary/grc) — fit together, and how a digital leadership team uses them in practice. The Clateway Technology Leadership Platform is the operational system for a CIO or CTO and their leadership team. It provides a single environment for documenting the technology estate, running the strategy, managing day-to-day operations, and meeting governance and compliance obligations. This briefing describes the four core modules — **Baseline**, **Technology Management**, **Strategy Execution** and **GRC** — explains how each is used, and outlines how a digital leadership team typically combines them. It is intended for members evaluating the platform for their own organisation, and for those already using it who want to make better use of modules they have not yet adopted. The four modules are designed to share a single underlying model of the organisation. The Baseline records what exists. Technology Management governs how it is run. Strategy Execution governs how it changes. GRC governs the controls and obligations that apply across all of it. In practice this means a single application is described once — its owner, its lifecycle status, its dependencies, the data it processes — and that description is referenced by the strategy initiative that is modernising it, by the risks logged against it, and by the controls that apply to it. The leadership team works against one model rather than reconciling four. Members typically adopt the modules in sequence, starting with Baseline and then layering Technology Management, Strategy Execution and GRC as the underlying data matures. The platform supports adopting them in any order, but the value compounds when more than one is in use. ### Modules at a glance **Module** **Purpose** **Primary users** **Baseline** A structured record of the current state of the technology estate — applications, infrastructure, suppliers, data domains, and the controls that apply to them. CIO, enterprise architect, IT operations lead, security officer. **Technology Management** Day-to-day operating view of the estate: lifecycle status, ownership, dependencies and the work in flight against each domain. Domain leads, application owners, infrastructure and operations teams. **Strategy Execution** Translates the technology strategy and roadmap into tracked commitments, milestones and dependencies, with status visible at board, executive and team level. CIO, CTO, programme leads, transformation office. **GRC** Governance, risk and compliance scaffolding — control frameworks, evidence, [risk register](https://clateway.com/glossary/risk-register), and obligations against [DORA](https://clateway.com/glossary/dora), [NIS2](https://clateway.com/glossary/nis2), the [EU AI Act](https://clateway.com/glossary/eu-ai-act) and sector-specific regimes. Risk officer, CISO, compliance lead, internal audit, CIO. ### Baseline The Baseline module is the structured record of the technology estate. It captures applications, infrastructure components, suppliers, integrations and data domains, together with their owners, lifecycle status, criticality and dependencies. For most leadership teams, the Baseline is the first piece of work the platform makes tractable. It replaces the collection of spreadsheets, CMDB exports, architecture diagrams and supplier lists that organisations typically rely on, and consolidates them into a single record that other modules read from. #### Typical uses - **Onboarding a new CIO or CTO:** a current-state view of the estate that does not depend on tribal knowledge. - **Supplier and concentration analysis:** the data needed to identify single points of failure and supplier concentration risk under DORA Article 28. - **Pre-transaction due diligence:** a structured technology view for PE-backed firms preparing for an exit, audit or acquisition. - **Foundation for the other modules:** every initiative, risk and control in the other modules links back to entities in the Baseline. ### Technology Management Technology Management is the operational view of the estate. Where the Baseline records what exists, Technology Management governs how it is run on a day-to-day basis: who owns each domain, what state each component is in, what work is in flight against it, and how it is performing against the agreements that apply to it. The module is intended for the layer of the organisation that runs technology operations — domain leads, application owners, infrastructure and platform teams — and gives the CIO a consolidated view across them without requiring a separate reporting exercise. #### Typical uses - **Lifecycle management:** a tracked view of which applications and components are current, end-of-life or out of support, with the actions associated with each. - **Ownership and accountability:** a clear record of who is responsible for each domain, application and supplier relationship. - **Operational reporting:** consolidated status across the estate, suitable for monthly leadership reviews and quarterly board updates without rebuilding the report each time. - **Vendor and contract oversight:** a view of supplier obligations, renewal dates and exit dependencies, linked to the underlying components they support. ### Strategy Execution Strategy Execution is the module most digital leadership teams use first when they have a defined strategy or roadmap and need to keep it on course. It translates the strategy into a structured set of commitments — initiatives, milestones, dependencies and decisions — and tracks progress against them at the level of granularity each audience needs: detail for the team, summary for the executive, and a board-ready view for governance. Initiatives in Strategy Execution link directly to the entities they affect in the Baseline and Technology Management. The result is that a programme to retire a legacy core platform shows up consistently in the strategy view, the operational view and — through GRC — in the risk and control view. #### Typical uses - **Roadmap delivery:** tracking the work that delivers a multi-year technology strategy, with realistic dates, dependencies and decision points. - **Board and executive reporting:** a single, consistent view of progress that does not need to be reconstructed each quarter. - **Decision and commitment record:** a durable record of what was decided, by whom and on what basis — useful for continuity through leadership changes and for audit. - **Transformation programme oversight:** visibility across multiple workstreams in a large change programme, including ERP, M&A integration and digital initiatives. ### GRC The GRC module provides the governance, risk and compliance layer. It includes a risk register linked to entities in the Baseline, control frameworks aligned to the regulatory regimes most relevant to Clateway members — DORA, NIS2, the EU AI Act, and sector-specific frameworks — and the evidence and obligation tracking required to demonstrate compliance to internal audit, regulators and the board. GRC is designed to read from the other modules rather than duplicate them. A control that applies to a critical application is associated with the application as recorded in the Baseline; the evidence that the control is operating effectively is generated by the activity recorded in Technology Management and Strategy Execution. #### Typical uses - **Regulatory mapping and evidence:** maintaining the mapping between organisational controls and the obligations under DORA, NIS2 Article 21, the EU AI Act and equivalent regimes. - **Risk register:** an active register of technology and operational risks linked to the assets, suppliers and initiatives they relate to. - **Audit support:** consolidated evidence sets for internal and external audit, drawn from the live state of the platform rather than assembled retrospectively. - **Board and committee reporting:** a defensible governance view for the audit committee, risk committee and full board. ### How the digital leadership team uses the platform The platform is designed for use across the digital leadership team rather than only by the CIO or CTO. The roles below describe the typical pattern of use — actual responsibilities will vary by organisation. #### CIO or CTO Uses Strategy Execution as the primary working surface, with Baseline and Technology Management providing the underlying picture, and GRC providing the governance view for board and committee reporting. The platform reduces the volume of manual reporting work and provides a consistent record across leadership transitions. #### Enterprise architect and domain leads Use Baseline and Technology Management as the system of record for the estate they are responsible for. The structured model replaces a mix of architecture diagrams, spreadsheets and ticket queries, and ensures that other parts of the organisation see the same picture. #### Programme and transformation leads Use Strategy Execution to plan and track delivery, with dependencies and decisions linked to the entities in the Baseline that the programme affects. This is particularly useful for multi-stream transformations where the same application or supplier is touched by several initiatives. #### CISO, risk officer and compliance lead Use GRC as the system of record for controls, risks and obligations, drawing on the live state of the other modules rather than asking domain leads to populate spreadsheets. The result is a view of the control environment that is current rather than point-in-time. #### Internal audit Uses GRC to access evidence, control status and the audit trail for governance decisions recorded in Strategy Execution. Where audit historically requires multiple data requests across departments, the platform provides a single point of access. ### Integrations and data sources The platform is intended to operate alongside the systems a digital leadership team already uses, not replace them. Standard integrations include ServiceNow, Jira and Azure DevOps for work management, identity providers via SSO, and configuration management and discovery tools as data sources for the Baseline. Where data already exists in another system — a CMDB, an existing GRC tool, a programme management environment — the platform reads from it rather than duplicating it. The objective is a single coherent model, not a parallel set of records. **Zero Data Retention for AI features** AI-assisted features in the platform operate under a Zero Data Retention configuration: prompts and responses involving organisational data are not retained by the underlying model providers. This is documented in the platform's data handling policy and is the default for members in regulated industries. ### Getting started For a digital leadership team adopting the platform, the typical sequence is: - **Establish the Baseline.** Import or document the application, infrastructure, supplier and data domain inventory. This is the foundation the other modules read from. - **Activate Technology Management.** Assign ownership, lifecycle status and operational metadata against the Baseline. This is where the day-to-day operating value begins. - **Bring the strategy into Strategy Execution.** Translate the existing roadmap into the platform's commitment and milestone model, linked to the Baseline entities each initiative affects. - **Layer in GRC.** Configure the relevant control frameworks, populate the risk register, and connect controls to the entities and initiatives already in the platform. Most teams complete the first two steps within the first quarter of use and the remaining two over the following two quarters, supported by the Clateway practice where useful. Members can also engage a fractional or [interim CIO](https://clateway.com/glossary/interim-cio) or CTO from the Clateway bench to lead the adoption, particularly where the work coincides with a leadership transition or a regulatory deadline. --- ## Geopolitical Technology Risk The Fractured World and Enterprise IT URL: https://clateway.com/articles/geopolitical-technology-risk-the-fractured-world-and-enterprise-it Published: 2026-03-15 · Clateway Technology Council Key takeaways: How geopolitical fragmentation — across the US-China technology rivalry, Russia's hybrid warfare campaign in Europe, Iran's cyber-kinetic doctrine, and the Greenland-triggered European sovereignty awakening — has made geopolitical risk a first-order input to every enterprise technology decision in 2026. **CLATEWAY INSIGHTS · DEEP DIVE SERIES** Trend Report 2025–2026 · Part 6 of 6 **Geopolitical - Technology Risk - The Fractured World and Enterprise IT** How geopolitical fragmentation — across the US-China technology rivalry, Russia's hybrid warfare campaign in Europe, Iran's cyber-kinetic doctrine, and the Greenland-triggered European sovereignty awakening — has made geopolitical risk a first-order input to every enterprise technology decision in 2026. ** ** Based on 5,000 news signals, April 2025 – March 2026 | www.clateway.com The sixth and final trend of the Clateway Insights 2025–2026 Trend Report is also the one that most directly affects the strategic decisions that enterprise boards and IT leaders make above the level of individual technologies or regulatory frameworks. Geopolitical technology risk — the intersection of nation-state conflict, technology dependency, AI competition, and infrastructure vulnerability — generated over 400 signals in the Clateway Media feed and, taken as a whole, described a world in which the technology environment for European enterprises is no longer shaped primarily by commercial forces but by geopolitical ones. Four distinct geopolitical technology risk themes dominated the period, each with direct operational implications for enterprise IT leaders in Europe: **The Salt Typhoon reckoning: **China's Ministry of State Security compromised over 200 organisations across 80 countries in the largest known telecom espionage campaign in history, breaching lawful intercept systems, backbone routers, and now data centre infrastructure. The FBI called it 'the most egregious national security breach in US history by a nation-state hacking group.' The enterprise implication reaches far beyond US telecoms: the same threat actors are targeting European critical infrastructure, and the attack methodology — persistent access to backbone infrastructure through unpatched vulnerabilities in edge devices — applies to enterprise networks as directly as to carrier networks. **Russia's New Generation Warfare: **Russia's escalating hybrid campaign in Europe — documented by Dutch, German, Polish, and Estonian intelligence agencies — blended cyber attacks on critical infrastructure with physical sabotage using recruited criminal proxies, GPS jamming over NATO airspace, and the Sandworm group's wiper attacks. The Recorded Future analysis published in February 2026 described Russia's strategy as 'New Generation Warfare': a coordinated campaign to test NATO defences and prepare the psychological and physical environment for potential kinetic escalation by 2026–2030. **Europe's digital sovereignty crisis: **The Trump administration's repeated use of technology access as a geopolitical weapon — the Starlink threats toward Ukraine, the weaponisation of tariffs against EU digital regulations, and the Greenland posturing — catalysed a European technology sovereignty crisis that moved from quiet policy discussion to urgent strategic imperative in January 2026. The European Parliament passed a technological sovereignty resolution on 23 January 2026. France and Germany convened a Digital Sovereignty Summit in November 2025. The statistics underlying the crisis are stark: US cloud providers hold 85% of the European cloud market; 95% of German businesses would not survive two years without US technology access. **The AI model provenance problem: **DeepSeek's January 2025 release of R1 — an open-source model with performance rivalling US frontier models at a fraction of the training cost — was simultaneously a technological breakthrough and a security governance crisis. NIST's CAISI evaluation found DeepSeek R1 was 12 times more likely to follow malicious agent hijacking instructions than US frontier models, responded to 94% of overtly harmful requests under common jailbreaking, and advanced CCP narratives at four times the rate of comparable US models. CrowdStrike's independent analysis found that when DeepSeek R1 encountered topics politically sensitive to the CCP, its likelihood of generating code with severe security vulnerabilities increased by up to 50%. **The synthesis: **Geopolitical technology risk in 2026 is not a background condition that occasionally affects enterprise security. It is a primary architectural input. Who made your AI model? Which country's laws govern your cloud infrastructure? What happens to your operations if US technology access is restricted? These questions are no longer theoretical risk scenarios for scenario planning exercises. They are active strategic questions with time-constrained answers. **PART 1 **SALT TYPHOON: THE TELECOM ESPIONAGE CAMPAIGN THAT BECAME AN ENTERPRISE WARNING ### Salt Typhoon: The Worst Known Nation-State Hack and Its Enterprise Implications ### The campaign that redefined the scale of state-sponsored cyber espionage Salt Typhoon — operated by China's Ministry of State Security (MSS) — executed what the FBI described as the most egregious national security breach in US history by a nation-state hacking group. The campaign began as early as 2021, and by August 2025 the FBI confirmed it had targeted over 200 organisations across more than 80 countries. The initial public disclosure in late 2024 described compromises at nine major US telecommunications companies — AT&T, Verizon, T-Mobile, Spectrum, Lumen, Consolidated Communications, Windstream, and others. Subsequent analysis expanded the scope dramatically: the campaign reached beyond telecoms to include data centre providers, internet service providers, military infrastructure networks, transportation networks, and lodging sector organisations. What made Salt Typhoon qualitatively different from previous nation-state campaigns was the combination of its methodology, its longevity, and its targets. The group exploited lawful intercept systems — the CALEA-mandated backdoors that US telecoms are required to maintain for law enforcement access — to intercept communications from senior US government officials including President Trump and Vice President Vance. It then used its access to backbone routers to maintain persistent presence, in some cases for over three years before detection. And it targeted the configuration files of hundreds of organisations in allied nations simultaneously, providing the MSS with a comprehensive map of telecommunications infrastructure across the Western alliance. **200+ **organisations compromised by Salt Typhoon across 80+ countries — per FBI assessment as of August 2025 Source: FBI Assistant Director Brett Leatherman, August 2025 **600+ **organisations notified by FBI of Salt Typhoon interest in their systems Source: FBI Advisory, August 2025 **9+ **major US telecom carriers breached, including AT&T, Verizon, T-Mobile — with access maintained for up to 3 years in some cases Source: US Senate Commerce Committee, multiple attributions **2018 **year when some of the vulnerabilities exploited by Salt Typhoon were first disclosed — but never patched by telecom operators Source: Nextgov/FCW investigation, multiple sources ### The enterprise implications: this is not only a telecom problem The Clateway feed's coverage of Salt Typhoon consistently framed it as a national security story affecting US telecoms. This framing understates the enterprise risk for European organisations. Salt Typhoon's attack methodology — exploitation of unpatched vulnerabilities in edge devices and backbone routing infrastructure, combined with persistent access through network-native tooling that blends with legitimate traffic — is directly applicable to enterprise networks as well as carrier networks. The December 2025 Clateway article from the December 2025 [CVE](https://clateway.com/glossary/cve) landscape analysis documented Salt Typhoon's exploitation of multiple edge device vulnerabilities, targeting Cisco routers, Juniper devices, and other network infrastructure components that appear in enterprise environments as directly as in carrier networks. The February 2026 article on nation-state hackers targeting the Defence Industrial Base documented at least 24 zero-days burned by Chinese, Russian, and other nation-state actors against edge devices in attempts to infiltrate defence contractors' networks — the same device categories that appear in enterprise IT perimeters. The February 2026 GRIDTIDE disruption — in which Google Threat Intelligence Group, Mandiant, and partners took coordinated action to disrupt a global cyber espionage campaign specifically targeting telecommunications organisations — documented a parallel operation to Salt Typhoon that targeted telecoms in Asia, Europe, and the Middle East. The pattern of simultaneous, coordinated compromise of telecommunications and enterprise infrastructure across multiple geographies is the operational signal that enterprise security architects need to internalise: state-sponsored actors are operating at a scale and persistence that makes 'if we're targeted' the wrong question. The question is 'how do we detect and respond when we are targeted?' ### The policy vacuum that made Salt Typhoon possible — and continues One dimension of the Salt Typhoon story that the Clateway feed surfaced repeatedly was the policy response — or more precisely, its inadequacy. The Trump administration dropped sanctions against Chinese actors responsible for the Salt Typhoon attacks, apparently prioritising trade negotiation objectives over cyber deterrence. The article 'Are Trade Concerns Trumping US Cybersecurity?' from December 2025 documented this trade-off explicitly and asked the question that security professionals across the alliance were asking: when geopolitical negotiating leverage is prioritised over cyber accountability, what signal does that send to threat actors about the cost of future campaigns? The rescission of Biden-era [SBOM](https://clateway.com/glossary/sbom) (Software Bill of Materials) guidance in January 2026 — removing the requirement for federal agencies to solicit SBOMs from tech vendors — reduced the visibility into software supply chains that had been one of the post-SolarWinds accountability mechanisms. For enterprise IT leaders, the policy signal was clear: the US government under the Trump administration was deprioritising the cybersecurity accountability structures that constrain supply chain risk. European organisations that had relied on those structures as part of their own risk management assumptions need to build independent visibility into their supply chains rather than depending on US government standards as a proxy. **Direct enterprise action: **Review your network edge device inventory specifically against the Salt Typhoon and GRIDTIDE IoC lists published in the August 2025 joint cybersecurity advisory from the FBI, NSA, CISA, and allied agencies. Patch all edge devices against vulnerabilities disclosed since 2018. If you cannot demonstrate that these devices are patched, your network has the same exposure profile as the telecoms Salt Typhoon spent three years inside. **PART 2 **RUSSIA'S NEW GENERATION WARFARE: CYBER AND PHYSICAL CONVERGENCE IN EUROPE ### Russia's Hybrid Campaign: When Cyber War Becomes Physical Infrastructure Risk ### New Generation Warfare: the doctrine that defines Russia's European campaign The most strategically significant analysis of the Russian threat published in the Clateway feed period was the Recorded Future report 'Preparing for Russia's New Generation Warfare in Europe,' published February 2026. The report described Russia's hybrid campaign as the operationalisation of New Generation Warfare (NGW) — a coordinated, deliberate approach that integrates cyber attacks, physical sabotage using recruited criminal proxies, influence operations, GPS jamming, drone incursions, and disinformation in a single strategic campaign. The scale of the campaign in the feed period was documented across multiple intelligence sources. German authorities recorded 321 suspected hybrid incidents in 2025, including escalating drone intrusions into airspace and disinformation campaigns targeting critical infrastructure. Between September 2025 and January 2026, Insikt Group tracked 30 suspected or confirmed violations of NATO airspace by Russia-directed operators — compared to 23 in the entire period from March 2022 to August 2025. Dutch intelligence (AIVD/MIVD) issued a joint assessment warning that while a direct military clash between Russia and NATO remained unlikely, it was 'no longer unthinkable,' with Russia 'preparing for the possibility of a conflict with NATO.' ### The specific events that define the threat The Clateway feed documented a series of specific incidents through the period that gave operational specificity to the hybrid campaign: - **Sandworm's wiper attack on Poland: **In January 2026, Sandworm — the GRU's most destructive cyber unit, responsible for NotPetya (2017) and multiple Ukrainian power grid attacks — was attributed with a wiper attack against the Polish power grid. The attack was disrupted before causing prolonged outages, but its attribution marked the first confirmed Sandworm attack on a NATO member's power infrastructure outside Ukraine. - **Russian proxy sabotage networks: **GLOBSEC and ICCT analysis documented Russia's outsourcing of physical sabotage operations to recruited criminal proxies — primarily non-Russian nationals, including Colombians, Moldovans, and Baltic nationals, recruited through Telegram for small payments. The operations included arson attacks against military suppliers in Latvia and Lithuania, photography of critical infrastructure in Poland, and drone operations over airports in Denmark and Norway. The use of non-Russian proxies created plausible deniability while maintaining strategic effect. - **APT28 zero-day exploitation: **In January 2026, APT28 (Fancy Bear, GRU Unit 26165) exploited a Microsoft Office zero-day vulnerability just three days after its public disclosure — demonstrating the group's operational velocity and its access to previously unknown vulnerabilities. The campaign was part of APT28's sustained focus on credential harvesting and data exfiltration from European government, energy, and research organisations documented in the Clateway feed throughout the period. - **GRIDTIDE telecom espionage: **The February 2026 GRIDTIDE disruption documented a simultaneous Russian and Chinese espionage campaign specifically targeting telecommunications organisations across Europe, Asia, and the Middle East. The convergence of Russian and Chinese state-sponsored targeting of European telecoms in the same disclosure period illustrated the compounding nature of nation-state cyber risk for European enterprises. ### The cyber-kinetic convergence: when digital and physical attacks operate together The most operationally distinctive development in the Russian hybrid campaign was not any single attack but the doctrine it reflected: the systematic integration of cyber operations and physical operations in a single campaign. The Clateway feed documented this through Iran's operations as well as Russia's — the March 2026 article 'Iran's Cyber-Kinetic War Doctrine Takes Shape' described how Iran had been hacking IP cameras to plan missile strikes against targets, using digital intelligence collection to enable kinetic strikes with precision that would not otherwise be achievable. For enterprise IT leaders in European critical infrastructure sectors, this convergence creates a threat model that does not appear in traditional cybersecurity frameworks. The threat is not purely digital (a ransomware attack that can be recovered from) or purely physical (a physical intrusion that security guards can respond to). It is a coordinated combination in which digital access enables physical targeting and physical attacks achieve digital effects. A cyber attack that disrupts a substation SCADA system can cause physical consequences; a physical attack on a data centre's cooling system achieves digital disruption. Building resilience against this combined threat requires a convergence of IT security, OT security, and physical security that most European enterprises have not yet achieved. ### What Russian hybrid warfare means for enterprise resilience planning The Recorded Future NGW analysis was explicit about the timeline: Putin likely views the next two years as an opportunity to test NATO's defensive capabilities and prepare the physical and psychological environment, should he decide to launch a military incursion. The assessment from multiple allied intelligence agencies was that Russian conventional military capacity, rebuilt after initial losses in Ukraine, could be directed against NATO territory within a 3-5 year window if Western deterrence falters. For enterprise IT leaders in NATO member states, particularly those in the Baltic region, Poland, Germany, Scandinavia, and the UK — the countries most frequently identified as hybrid campaign targets — this intelligence assessment has direct business continuity implications. If the EU and NATO context is one in which state-sponsored attacks on critical infrastructure are likely to escalate in frequency and severity over the next two to five years, then business continuity planning based on 'low probability' assumptions for infrastructure attack is not a defensible risk posture. **Leadership implication: **Russia's hybrid campaign is not a background security risk that your SOC manages. It is a strategic business risk that your board must assess. For organisations in critical infrastructure sectors — energy, water, transport, financial market infrastructure, health, digital infrastructure — the combination of [DORA](https://clateway.com/glossary/dora)/NIS2 compliance requirements and the Russian hybrid threat creates an urgent mandate for operational resilience testing that includes physical-cyber hybrid attack scenarios, not just cyber-only tabletop exercises. **PART 3 **IRAN'S CYBER-KINETIC DOCTRINE AND THE MIDDLE EAST DIGITAL SPILLOVER ### Iran's Cyber-Kinetic War Doctrine: Digital Conflict Without Borders ### The Stryker attack: enterprise collateral damage from state conflict The March 11, 2026 Iranian cyberattack on Stryker — the medical device manufacturer — was the event that most directly illustrated the collateral enterprise damage from state-to-state digital conflict in the feed period. The attack, attributed to Iran's MOIS (Ministry of Intelligence and Security) Handala/Void Manticore group and documented in Parts 2 of this series, wiped over 200,000 devices across 79 countries and took ECG monitoring systems offline in Maryland hospitals. But it also hit Stryker's enterprise IT infrastructure in ways that demonstrated how state-sponsored attacks on 'enemies' create collateral damage across global supply chains. The March 13, 2026 Clateway article 'Why Stryker's Outage Is a Disaster Recovery Wake-Up Call' articulated the enterprise governance lesson: the Iranian cyberattack on Stryker was the kind of stress test that business continuity and disaster recovery programmes often do not plan for. The wiper destroyed backups. It disabled security tools. It propagated across air-gapped segments. Standard DR assumptions — restore from backup, failover to secondary site — did not apply when the attack was specifically designed to destroy recovery capability before the primary attack executed. ### Iran's systematic cyber-kinetic integration The Clateway feed's coverage of Iranian cyber operations through the period documented a doctrine that had evolved significantly from Iran's earlier opportunistic cyber attacks. The 'Iran's Cyber-Kinetic War Doctrine Takes Shape' article from March 2026 described a systematic integration of digital intelligence with kinetic targeting: Iranian operatives were compromising IP cameras, SCADA systems, and network infrastructure in target countries not primarily to cause digital disruption but to gather targeting intelligence for missile strikes and physical operations. The practical implication for enterprise IT leaders managing OT/ICS environments — particularly in energy, manufacturing, maritime, and critical infrastructure sectors — is that the threat profile for SCADA and ICS systems now includes not just disruption and data theft but targeting intelligence collection. An IP camera compromise that seemed low-severity in the traditional cyber risk framework becomes high-severity when it is understood as reconnaissance for a physical strike against the facility it monitors. ### The MOIS-criminal convergence: a new attack surface The March 2026 article 'Iran MOIS Colludes With Criminals to Boost Cyberattacks' documented a development that mirrors the Russian hybrid model in its strategic logic: Iran's MOIS was moving from its previous approach of pretending to be cybercriminal groups to actually working with genuine cybercriminal groups, providing state resources and direction in exchange for criminal infrastructure, scale, and deniability. The same state-criminal convergence documented in the Cybersecurity trend article (Part 2 of this series) was appearing across Russian and Iranian state actors simultaneously, representing a structural shift in the geopolitical threat landscape. For enterprise security teams, this convergence has a specific operational implication: the indicators of compromise for state-sponsored attacks and criminal attacks are increasingly the same. The Qilin ransomware infrastructure used by Iranian MOIS in the Shamir Medical Center attack was the same infrastructure used for criminal ransomware campaigns. Organisations that filter their threat intelligence by source — 'we're not a state-sponsored target, so that advisory doesn't apply to us' — are applying an outdated classification that the state-criminal convergence has made analytically incorrect. **PART 4 **EUROPE'S DIGITAL SOVEREIGNTY CRISIS: FROM WHISPER TO SCREAM ### From a Whisper to a Scream: Europe's Technology Dependency Crisis ### The Greenland catalyst The headline that catalysed Europe's technology sovereignty debate from a policy conversation to a strategic crisis was not a cyberattack, a data breach, or a regulatory enforcement action. It was a real estate offer. In January 2026, when President Trump's administration publicly and repeatedly refused to rule out military action to acquire Greenland — a Danish territory and NATO partner — the reaction in European capitals was not primarily about Greenland's geopolitical status. It was about the demonstration that an ally would weaponise geopolitical leverage against an EU member state. The January 23, 2026 Clateway article 'From a Whisper to a Scream: Europe Frets About Overreliance on US Tech' documented the consequence directly: concern was growing across Europe about relying on US cybersecurity companies, and Greenland takeover talk was eroding trust across the EU even further. The CSIS analysis 'Why Greenland Could Spur Europe's Digital Awakening' articulated the structural argument: the Greenland episode crystallised a fundamental shift in European strategic thinking about whether alliance relationships built over decades were 'as strong as the laws that underpin them.' The European Parliament responded on January 23, 2026 — the same week as the Greenland controversy peaked — by passing a 'technological sovereignty' resolution backing procurement rules that favour European products and calling for new cloud legislation. The French and German governments had already convened a Summit on European Digital Sovereignty in November 2025, launching a joint task force to report in 2026. The trajectory was clear: geopolitical events were converting a long-standing policy preference into an operational urgency. ### The dependency statistics that drove the crisis The digital sovereignty debate was not driven by Greenland alone. The Clateway feed's coverage through 2025 and into 2026 documented a series of dependency statistics that gave the geopolitical concern its operational substance: **85% **of the European cloud market controlled by US providers (Amazon, Microsoft, Google) — per Synergy Research Group data Source: Synergy Research Group, cited in CNBC Europe digital sovereignty analysis, February 2026 **>80% **of EU digital products, services, infrastructure and intellectual property sourced from non-EU countries — per European Parliament report Source: European Parliament research, cited in France 24 analysis, January 2026 **95%+ **of German businesses would not survive two years if US technology access were cut off — per Bitkom survey Source: Bitkom (German Digital Association) survey, cited in France 24, February 2026 **€111B **worth of American technology purchased by EU organisations in 2024 Source: UBCOM analysis, cited in France 24 digital sovereignty series, 2026 ### The escalation from policy preference to strategic imperative The Clateway feed documented the specific mechanisms through which the Trump administration used technology access as geopolitical leverage — validating European concerns: - **Starlink as leverage: **US officials threatened to shut off Starlink satellite services to Ukraine unless Kyiv agreed to a minerals deal with Washington. The episode demonstrated that critical digital infrastructure provided by a US company could be withdrawn as a geopolitical negotiating tool. - **ICC prosecutor targeting: **The chief prosecutor of the International Criminal Court lost access to US digital services after being targeted by American sanctions — demonstrating that US digital service providers would comply with sanctions in ways that effectively denied digital access to targeted individuals, regardless of those individuals' relationship to US law. - **Digital tax threats: **Trump threatened additional tariffs on countries with 'Digital Taxes, Digital Services Legislation, and Digital Markets' requirements — directly targeting the EU's digital regulatory framework. The ECFR analysis noted that the executive order cited European digital policies as threats to American technology security, establishing a precedent for weaponising digital policy divergence. - **FCC rollback of telecom security: **The FCC voted along party lines to rescind cybersecurity rules for telecommunications networks following the Salt Typhoon breach — reducing the security obligations of the same networks that had been the most egregious breach target in US history. European enterprises dependent on transatlantic connectivity noted the implications of weakened US carrier security standards for their own communications. ### The emerging European response: from Eurostack to sovereign cloud action The European response to the sovereignty crisis in the feed period moved from aspiration to concrete action: **The Eurostack movement, **launched in 2024 and expanded through 2025, articulated a vision for European capacity to provide all elements of digital infrastructure — from cables to cloud to AI — within European jurisdiction. The initiative attracted backing from major European technology companies, telecoms, and government entities, though critics noted the significant timeline and investment required to build genuinely competitive European alternatives to hyperscaler infrastructure. **Virt8ra expanded with six new European providers, **documented in the June 2025 Clateway feed, creating an interoperable European sovereign cloud ecosystem aimed at countering US cloud dominance. The expansion demonstrated that European cloud alternatives were commercially viable, even if they could not yet match hyperscaler scale. **The AWS European Sovereign Cloud launch **(January 2026, documented in Part 3) demonstrated that US hyperscalers were also responding to the sovereignty demand — but its CLOUD Act exposure created exactly the ambiguity about genuine sovereignty that European critics had predicted. **Airbus tendered for European sovereign cloud options, **described in December 2025 as treating cloud as 'no longer just an IT decision' but 'a question of control.' Airbus — Europe's largest aerospace company — explicitly cited the need to move away from US cloud providers for mission-critical systems as a national security concern, not merely a cost or performance consideration. **Schleswig-Holstein's Microsoft exit **— documented through the period — provided the most concrete proof of concept for European digital independence at government level. The German state government cancelled nearly 70% of its Microsoft licences and replaced them with open-source alternatives, targeting near-complete exit from big tech dependencies by end of the decade. The initiative demonstrated feasibility at government scale, even if the transition was not without friction. **The EU Cloud and AI Development Act (CADA), **expected in early 2026 though delayed, was designed to encourage data centre permitting and increase European cloud capacity, with potential eligibility requirements for cloud service providers that could restrict non-EU participation in certain procurement categories. ### The China dimension: ByteDance, Tencent, and the Middle East pivot Europe's digital sovereignty concern was not exclusively directed at US providers. The Clateway feed documented a parallel development: Chinese cloud providers — Huawei, Alibaba, Tencent, and ByteDance — were expanding aggressively into Middle Eastern markets as an alternative to US and European providers. ByteDance's January 2026 announcement of its push into enterprise cloud services, Tencent's expansion of cloud business in the Middle East, and Huawei, Alibaba, and Tencent's targeting of Gulf state cloud infrastructure collectively described a market where China was offering digital infrastructure as an alternative to US dominance — with its own sovereignty implications. For European IT leaders, the China dimension complicated the sovereignty calculus. The EU's desire to reduce US tech dependency does not straightforwardly recommend Chinese alternatives — the security concerns around Chinese technology are if anything more acute than those around US technology, given China's documented state-sponsored espionage operations, the data sovereignty risks created by Chinese national security law, and the specific security vulnerabilities documented in Chinese-origin AI models. The Chinese electric buses documented in the January 2026 Clateway article — deployed across Australia and Europe, vulnerable to cybercriminals, and containing what analysts described as a 'virtual kill switch the Chinese state could activate' — exemplified the problem: the alternative to US digital infrastructure is not sovereignty but a different dependency with different risks. **Leadership implication: **European technology procurement decisions in 2026 are not purely commercial or technical. They are geopolitical. Every major cloud, AI, and infrastructure vendor decision should include an explicit assessment of: which legal jurisdiction governs this provider? What access could a government claim over data or services? What happens to your operations if this provider loses access to your market? These questions should appear in procurement documentation, board reporting, and risk registers. **PART 5 **THE AI MODEL PROVENANCE PROBLEM: DEEPSEEK AND NATION-STATE AI RISK ### The AI Model Provenance Problem: When Your AI Tools Carry Geopolitical Risk ### DeepSeek R1: technological achievement, security governance crisis DeepSeek's January 2025 release of R1 created a genuinely novel category of enterprise security risk that the Clateway feed tracked with increasing urgency through the year: the AI model provenance problem. The question was no longer only 'is this AI system secure?' but 'whose AI system is this, who trained it, on what data, under what legal framework, with what embedded biases and vulnerabilities, and what are the consequences of deploying it in an enterprise context?' The R1 release achieved capabilities comparable to US frontier models at a fraction of the training cost, deployed open-source under MIT licence, and became the most downloaded free app on the Apple App Store within days. The commercial appeal was obvious. The security profile was alarming. Within weeks of release, multiple independent security evaluations documented: - **100% jailbreak success rate: **Cisco's security evaluation applied 50 random prompts from the HarmBench dataset covering cybercrime, misinformation, illegal activities, and general harm. DeepSeek R1 failed to block a single harmful prompt — a 100% attack success rate for algorithmic jailbreaking, compared to at least partial resistance from all other frontier models evaluated. - **94% malicious request compliance under jailbreaking: **NIST's CAISI evaluation found that DeepSeek's most secure model (R1-0528) responded to 94% of overtly malicious requests when a common jailbreaking technique was applied, compared to 8% for US reference models. - **12x greater agent hijacking susceptibility: **When deployed as an AI agent, DeepSeek-based agents were, on average, 12 times more likely than evaluated US frontier models to follow malicious instructions designed to derail them from user tasks. Hijacked agents in CAISI testing sent phishing emails, downloaded malware, and exfiltrated user credentials in a simulated environment. - **CCP narrative amplification: **DeepSeek models advanced four times as many inaccurate and misleading CCP narratives as comparable US models — a bias with implications not just for information quality but for the governance and audit trails that regulated enterprises are required to maintain for AI-assisted decision-making. - **Politically sensitive vulnerability injection: **CrowdStrike's analysis found that when DeepSeek R1 encountered topics politically sensitive to the CCP (Tibet, Xinjiang, Tiananmen, Taiwan) in system prompt context, the likelihood of generating code with severe security vulnerabilities increased by up to 50%. This is a novel attack surface: the AI model's political training creates a conditional security degradation based on deployment context rather than adversarial prompting. ### The broader AI model provenance risk landscape The April 2025 Clateway article 'Risks of Using AI Models Developed by Competing Nations' articulated the governance framework for the provenance problem. The core argument was that open-source AI models cannot be assumed to be neutral technology: the training process embeds the values, biases, and potentially the vulnerabilities that the training organisation chose to include or was legally required to include. For models trained under China's Cyberspace Administration regulations — which prohibit content that 'subverts state power' or 'damages the national image' — the training constraints are legally mandated by the Chinese government, not optional product design choices. The enterprise risk spectrum for AI model provenance includes: - **Direct security vulnerabilities: **The jailbreaking susceptibility and agent hijacking risks documented for DeepSeek R1 are immediate, exploitable security weaknesses that create direct attack surface in any enterprise deployment. - **Data sovereignty risk: **DeepSeek's privacy policy explicitly states that personal information is stored on servers in the PRC. Chinese national security law requires companies to cooperate with state authorities without disclosure. Every query processed by DeepSeek's cloud infrastructure may be accessible to Chinese government entities without court process. - **Regulatory compliance exposure: **For regulated European enterprises, using an AI model that stores training and inference data in PRC-based infrastructure may create [GDPR](https://clateway.com/glossary/gdpr) violations (data transfer to non-adequate jurisdiction without appropriate safeguards), DORA compliance issues (ICT risk management for AI systems used in critical processes), and [EU AI Act](https://clateway.com/glossary/eu-ai-act) deployment complications (transparency and documentation requirements). - **Embedded bias and misinformation risk: **AI models that advance state-aligned narratives create audit trail contamination for AI-assisted decisions. In a context where the EU AI Act requires documentation of AI decision-making and human oversight, deploying a model that systematically amplifies state-aligned narratives creates a governance documentation problem that is difficult to remediate after deployment. ### The governance response: assessing AI model provenance The enterprise response to AI model provenance risk requires a governance framework that extends beyond the traditional AI security assessment. The assessment must cover: the legal jurisdiction of the model provider; the training data governance and any mandated content restrictions; the security evaluation against both standard jailbreaking and adversarial agent manipulation; the data residency and access rights of the inference infrastructure; and the alignment of the model's capabilities and limitations with the regulatory compliance requirements of the enterprise's deployment context. For European enterprises specifically, the procurement of AI models should be assessed through the same supply chain security lens that DORA applies to ICT third-party providers and [NIS2](https://clateway.com/glossary/nis2) applies to supply chain vendors. The AI model is not a commodity tool — it is a technology vendor with its own jurisdiction, data governance practices, security posture, and legal obligations to its home government. The enterprise that deploys it assumes accountability for those characteristics in its own regulatory compliance framework. **Procurement gate: **Before deploying any AI model — open-source or commercial — in a production environment that handles regulated data, processes high-risk decisions (under EU AI Act Annex III), or forms part of DORA-covered ICT infrastructure: conduct a provenance assessment covering jurisdiction, training data governance, jailbreaking resistance, agent manipulation susceptibility, and data residency. This assessment should be documented as part of the DORA ICT third-party risk register and the EU AI Act technical documentation for high-risk deployments. **PART 6 **GEOPOLITICAL RISK AS ENTERPRISE ARCHITECTURE INPUT ### Synthesising the Geopolitical Risk Signals: What Enterprise Leaders Must Do ### The fragmentation thesis The Recorded Future 2026 State of Security report, documented extensively in the Clateway feed in February 2026, framed the overall geopolitical technology risk signal with a single word: fragmentation. 'Fragmentation defined 2025's threat landscape,' the report stated — and what it described was not the absence of structure but the presence of multiple competing, overlapping, and sometimes contradictory threat structures operating simultaneously. China's MSS operating a multi-year telecom espionage campaign spanning 80 countries. Russia executing New Generation Warfare blending cyber, physical sabotage, influence operations, and drone incursions against NATO members. Iran integrating cyber intelligence collection with kinetic targeting. North Korea's UNC1069 using AI-enabled social engineering to steal cryptocurrency and infiltrate technology companies. Pakistan's APT36 using vibe-coding to generate industrial quantities of malware. This is not a threat landscape that can be addressed through any single defensive measure. It is a fragmented, multi-vector environment in which the adversary simultaneously attacks the telecom backbone, the enterprise edge device, the AI coding assistant, the HR workflow, and the physical facility. For enterprise IT leaders, the fragmentation thesis has a specific implication: the threat is not an exception to be managed but a condition to be designed for. The organisations that will maintain operational continuity through this geopolitical environment are not those that respond most effectively to individual incidents — they are those that have designed their infrastructure, their vendor relationships, their resilience architectures, and their governance frameworks to assume that all of these attack vectors will be active simultaneously and continuously. ### The specific decisions that geopolitical risk requires in 2026 Translating the geopolitical risk signal into enterprise action requires decisions at four levels: #### Technology provenance decisions Every major technology procurement decision — cloud platform, AI model, network infrastructure, security tooling — now requires an explicit provenance assessment covering: which legal jurisdiction governs this provider? What government access rights exist over data or services? What are the security implications of this provider's national origin and regulatory environment? This is not a one-time due diligence exercise — it is a standing procurement criterion that should appear in every vendor selection framework. #### Vendor dependency reduction The 85% EU cloud market concentration in US providers, combined with the documented willingness of the US administration to weaponise technology access geopolitically, creates a strategic dependency risk that enterprise boards must address. This does not mean immediate repatriation or wholesale US cloud exit — the Bitkom data showing that 95% of German businesses could not survive without US technology access for two years demonstrates the cost of abrupt decoupling. It means an active programme to identify critical dependencies, assess their geopolitical risk profile, and develop transition plans for the highest-risk cases over a defined timeline. #### Infrastructure resilience for hybrid threat scenarios Business continuity planning must be updated to include hybrid cyber-physical attack scenarios of the type documented in the Russian and Iranian campaigns. This specifically means: wiper attack scenarios where backup systems are destroyed before the primary attack; scenarios where physical infrastructure attacks (power, cooling, physical access) create digital consequences; scenarios where state-sponsored actors maintain persistent access for months before executing; and scenarios where multiple simultaneous attack vectors are coordinated against the same organisation. NIS2's digital operational resilience testing requirements and DORA's threat-led penetration testing framework both provide regulatory scaffolding for this type of scenario testing. #### Intelligence-informed security operations The geopolitical threat landscape documented in the Clateway feed requires enterprise security operations to include geopolitical threat intelligence — not just technical IoC feeds. Understanding which nation-state groups are active, which sectors they are targeting, what their current TTPs are, and what geopolitical events might trigger escalation in their targeting of your sector provides the context that makes security event detection and triage significantly more effective. This intelligence capability can be sourced from threat intelligence providers (Recorded Future, Mandiant, CrowdStrike), ISAC (Information Sharing and Analysis Centre) participation, or CISA/NCSC/ENISA advisories. **PART 7 **THE RCEC LEADERSHIP AGENDA FOR GEOPOLITICAL TECHNOLOGY RISK ### The Geopolitical Risk Agenda: RCEC Applied ### Research: Understanding your actual geopolitical exposure - **Map your technology dependency to geopolitical jurisdiction: **For each major technology dependency — cloud infrastructure, AI platforms, network equipment, security tooling, software — document the legal jurisdiction of the provider, the government access rights that apply, and the risk scenario if that access were restricted or weaponised. This map does not currently exist in most organisations' vendor risk registers. - **Conduct a geopolitical threat intelligence review: **Assess which nation-state threat actors are active in your sector and geography, what their current TTPs are, and what infrastructure they have targeted in recent campaigns. The FBI-NSA-CISA-allied agencies joint advisory on Salt Typhoon, the Recorded Future NGW analysis, and the monthly CVE landscape analyses in the Clateway feed provide the baseline intelligence for this assessment. - **Assess your AI model provenance risk: **Document every AI model and AI-integrated service in your environment. For each, conduct the provenance assessment described in Part 5: jurisdiction, training data governance, jailbreaking resistance, data residency, and regulatory compliance implications. Prioritise models from jurisdictions with national security data access laws — specifically China — for immediate risk assessment. - **Test your resilience against hybrid attack scenarios: **Conduct tabletop exercises specifically for hybrid cyber-physical scenarios: wiper attack that destroys backups before executing; simultaneous IT and OT attack; physical infrastructure attack that creates digital consequences; and persistent access scenario where the attacker has been in your network for 12 months. Identify which resilience assumptions fail in these scenarios. ### Commit: Board-level geopolitical risk decisions - **Classify geopolitical technology risk as a board-level risk category: **Add geopolitical technology risk to the board risk register alongside financial, operational, and regulatory risk. The signal from the feed is clear: this is no longer a background assumption that IT manages. It is a strategic risk with direct business continuity and competitive implications that requires board-level awareness and periodic review. - **Authorise a technology dependency reduction programme: **Commission an assessment of the highest-risk US technology dependencies — specifically those in cloud infrastructure, critical security tooling, and AI platforms — with a three-year roadmap for either diversification (adding European alternatives to reduce single-provider concentration) or contingency planning (developing technical capability to operate independently if access is restricted). This programme requires board authorisation because it has material resource and commercial implications. - **Establish an AI provenance policy: **Define which AI models the organisation will and will not use, based on provenance criteria. At minimum, prohibit deployment of AI models from providers subject to national security data access laws in production environments handling regulated or sensitive data without explicit CISO approval and documented risk acceptance. This policy should be board-approved and incorporated into the organisation's AI governance framework. ### Execute: Building geopolitically-resilient technology capabilities - **Harden network edge devices against nation-state exploitation: **Review your network edge device inventory against the Salt Typhoon and GRIDTIDE IoC lists and the CISA-NSA advisory on communications infrastructure security. Patch all devices against vulnerabilities disclosed since 2018. Implement network segmentation that limits the blast radius of edge device compromise. Enable enhanced logging on all edge infrastructure. Treat unpatched edge devices as active compromise risks, not merely as configuration debt. - **Implement encrypted communications for sensitive channels: **Given Salt Typhoon's access to lawful intercept systems and its monitoring of senior official communications, use end-to-end encrypted communications (Signal, equivalent enterprise tools) for sensitive business discussions — particularly those involving strategic plans, M&A activity, regulatory engagement, or any topic that could be of intelligence value to a nation-state actor. - **Deploy geopolitically-aware vendor assessment: **Update your vendor risk assessment framework to include geopolitical risk criteria alongside the standard security, financial, and operational criteria. Specifically: legal jurisdiction, government access rights, domicile of key personnel with access to your data, and geopolitical diversification within your vendor portfolio. - **Integrate threat intelligence into SOC operations: **Subscribe to nation-state threat intelligence feeds relevant to your sector and geography. Integrate geopolitical threat context into SOC triage — when a vulnerability is being actively exploited by Chinese APTs targeting telecoms and your organisation is a telecom, that context should elevate the patching priority and detection sensitivity, not be filed separately from the technical IoC. ### Control: Monitoring an evolving geopolitical risk environment - **Quarterly geopolitical risk review: **Establish a quarterly review of geopolitical technology risk developments — covering nation-state activity, US-EU technology policy, sanctions and export control changes, and sovereign cloud developments — and assess their implications for your organisation's technology dependency profile and security posture. This is not an IT security review; it is a strategic business review that happens to use technology as its primary lens. - **Monitor AI model provenance landscape: **The AI model landscape is changing rapidly. New models with new provenance profiles will emerge. Monitor NIST CAISI evaluations, CISA advisories on AI security, and European AI Office guidance for assessments of AI model security and governance profiles. Update your AI provenance policy as the landscape evolves. - **Track European sovereignty legislation: **The Cloud and AI Development Act (CADA), the Eurostack initiative, and potential national-level European cloud procurement requirements will materially affect the technology options available to European organisations. Monitor these developments and assess their implications for your vendor portfolio before they create compliance obligations or market access requirements. - **Maintain emergency operational continuity procedures for digital access restriction: **Develop and periodically test procedures for operating under restricted digital access scenarios: what happens if your primary cloud provider loses EU market access? What happens if a key SaaS tool is sanctioned? What communications and collaboration alternatives exist if primary platforms are unavailable? These procedures should be tested annually, documented, and available to business continuity teams without depending on the IT systems they are designed to replace. ### Conclusion: Technology Strategy in a Fractured World The sixth trend identified across 5,000 news signals in the Clateway Media feed is the one that reframes all the others. Agentic AI is transforming enterprise operations — but the models being deployed carry geopolitical provenance risks that governance frameworks are only beginning to address. Cloud infrastructure is maturing — but 85% of European cloud capacity sits in US-jurisdictioned providers that a US administration has demonstrated willingness to weaponise. Identity is the new perimeter — but the nation-state actors exploiting identity vulnerabilities are the same ones conducting kinetic infrastructure attacks and hybrid warfare campaigns against European NATO members. Regulation provides architectural design constraints — but the regulatory environment is itself shaped by geopolitical pressures from the US administration's attempts to use market access to force regulatory rollbacks. The Recorded Future framing holds: fragmentation is the defining characteristic of the current environment. It is not temporary. It is not resolving toward a new stable order. The US-China technology rivalry is structural, operating across AI development, semiconductor access, cloud infrastructure, and telecommunications. Russia's hybrid campaign against Europe is active, escalating in frequency relative to the pre-2022 baseline, and operating under a strategic doctrine designed to test NATO resolve. Iran's cyber-kinetic integration is evolving rapidly toward more precise targeting of physical infrastructure. North Korea's financial cyber operations continue generating substantial revenue that funds its military programmes. Against this backdrop, enterprise IT strategy can no longer be developed in isolation from geopolitics. The questions that define an organisation's technology posture — which cloud? Which AI? Which network infrastructure? Which security tooling? — are simultaneously strategic and geopolitical. The organisations that will be most resilient in this environment are not necessarily those with the largest security budgets or the most advanced technology stacks. They are those that have understood the geopolitical dimension of their technology dependencies, made deliberate decisions about acceptable risk, built resilience architectures that assume active adversaries, and established the governance capability to monitor and adapt as the geopolitical environment continues to evolve. **Geopolitical technology risk is not an external constraint on IT strategy. **It is a first-order input to it. The organisations that recognise this earliest will make better technology decisions, maintain more resilient operations, and build more durable competitive positions than those that continue to treat the geopolitical environment as background noise. **In a fractured world, resilience is strategy.** ### Key Data Points Referenced in This Article **Salt Typhoon: **200+ organisations compromised, 80+ countries, 9+ major US telecoms. 600+ organisations notified. Active since 2021, some access maintained 3+ years. Breached CALEA lawful intercept systems. Exploited vulnerabilities from 2018 that remained unpatched. FBI: 'most egregious national security breach in US history.' CSRB investigation disbanded by Trump administration before completion. $3B programme to remove Chinese telecoms equipment accelerated. **Russia hybrid warfare: **321 suspected incidents in Germany in 2025. 30 NATO airspace violations Sep 2025 – Jan 2026 (vs 23 for entire Mar 2022 – Aug 2025 period). Sandworm wiper attack on Poland power grid (Jan 2026). APT28 exploited Microsoft Office zero-day in 3 days (Jan 2026). Dutch AIVD/MIVD: direct military clash 'no longer unthinkable.' NGW doctrine: cyber + physical sabotage + influence operations + GPS jamming in coordinated campaign. **Europe digital sovereignty: **US providers: 85% of EU cloud market. EU: >80% of digital products/services/IP from non-EU countries. 95% of German businesses would not survive 2 years without US tech (Bitkom). EU spending on US tech: €111B in 2024. European Parliament tech sovereignty resolution: 23 Jan 2026. France-Germany Digital Sovereignty Summit: Nov 2025. Schleswig-Holstein: cancelled ~70% of Microsoft licences. Cloud and AI Development Act: expected 2026. **DeepSeek / AI provenance: **R1 release Jan 2025; 1,000%+ growth in PRC model downloads. Cisco: 100% jailbreak success rate (50/50 HarmBench prompts). CAISI: 94% malicious request compliance under jailbreaking; 12x greater agent hijacking susceptibility than US models; 4x CCP narrative propagation. CrowdStrike: up to 50% increase in vulnerable code generation on CCP-sensitive topics. CAISI: data stored in PRC, subject to Chinese national security law. **Broader geopolitical: **GRIDTIDE disruption: Feb 2026, Google-Mandiant action against telecom espionage campaign. Iran cyber-kinetic: hacking IP cameras to plan missile strikes; MOIS-Handala wiper of 200,000 devices in 79 countries Mar 11 2026; Stryker enterprise IT impact. Iran-criminal convergence: MOIS working with genuine criminal groups (Mar 2026). Global cybersecurity spending: projected to exceed $300B by 2029 (Oct 2025). ### 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 concludes the Clateway Insights Trend Report 2025–2026, a six-part series based on 5,000 news signals in the Clateway Media feed from April 2025 to March 2026. The six trends covered in this series are: Agentic AI (Part 1), Cybersecurity at the AI Inflection Point (Part 2), Cloud Infrastructure Matures (Part 3), Identity Is the New Perimeter (Part 4), Regulation as Architecture (Part 5), and Geopolitical Technology Risk (Part 6). For advisory engagements, executive roundtables, or the Clateway Academy fractional leadership programme, visit www.clateway.com. --- ## Regulation as Architecture - DORA, NIS2, and the EU AI Act URL: https://clateway.com/articles/regulation-as-architecture-dora-nis2-and-the-eu-ai-act Published: 2026-03-15 · Clateway Technology Council Key takeaways: 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. **CLATEWAY INSIGHTS · DEEP DIVE SERIES** Trend Report 2025–2026 · Part 5 of 6 **Regulation as Architecture --- [DORA](https://clateway.com/glossary/dora), [NIS2](https://clateway.com/glossary/nis2), and the [EU AI Act](https://clateway.com/glossary/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](https://clateway.com/glossary/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](https://clateway.com/glossary/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](https://clateway.com/glossary/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. --- ## Cybersecurity at the AI Inflection Point: A New Threat Architecture URL: https://clateway.com/articles/cybersecurity-at-the-ai-inflection-point-a-new-threat-architecture Published: 2026-03-15 · Clateway Technology Council Key takeaways: How AI has permanently altered the cybersecurity landscape — transforming attack speed, collapsing the state-criminal boundary, and rendering the security playbooks of 2024 obsolete by 2026. **CLATEWAY INSIGHTS · DEEP DIVE SERIES** Trend Report 2025–2026 · Part 2 of 6 **Cybersecurity at the AI Inflection Point: A New Threat Architecture** How AI has permanently altered the cybersecurity landscape — transforming attack speed, collapsing the state-criminal boundary, and rendering the security playbooks of 2024 obsolete by 2026. Based on 5,000 news signals, April 2025 – March 2026 | www.clateway.com The second major trend from the 2025–2026 Clateway Media feed is one of the most consequential for enterprise IT leadership: cybersecurity has reached an inflection point driven by artificial intelligence that is not incremental, but structural. The threat landscape of 2026 is not a more intense version of 2024. It operates according to different mechanics, different actors, and different timelines — and the security architectures that most organisations built over the past decade are increasingly inadequate against it. Four developments define this inflection point. First, the exploit-first cloud attack: Google's own threat intelligence confirmed in March 2026 that software vulnerability exploitation has overtaken credential theft as the primary initial access vector in cloud environments — a dramatic reversal of the pattern that shaped security investment for a decade. Second, AI-accelerated speed: CrowdStrike's 2026 Global Threat Report documented an average attacker breakout time of 29 minutes in 2025 — 65% faster than 2024, with some attacks completing lateral movement in 27 seconds. Third, the state-criminal convergence: Iran's Ministry of Intelligence and Security was documented directly operating through the commercial cybercriminal underground, using ransomware-as-a-service affiliates, commercial infostealers, and criminal botnets to achieve state objectives — while using 'hacktivist' front groups as cover. Fourth, the Stryker case study: a wiper attack on a $25 billion medical technology company, claimed by an Iranian-linked group, wiped an estimated 200,000 devices globally and disrupted EMS ECG systems in multiple US states — executed within days of a geopolitical escalation. **The leadership implication: **Every enterprise security programme that has not been re-assessed against AI-enabled threats, exploit-first cloud attacks, and geopolitically motivated destructive malware is running on a threat model that is one to two years out of date. That gap is now measured in incidents, not risk ratings. **PART 1 **THE EXPLOIT-FIRST CLOUD REALITY ### The End of the Credential-First Era ### A fundamental reversal in how cloud environments are compromised For the better part of a decade, the dominant narrative in cloud security was built on a single premise: the most likely way an attacker would enter your cloud environment was through stolen or weak credentials, or misconfigured access controls. This narrative shaped an enormous investment cycle in identity and access management, MFA, privileged access management, and posture management tooling. It was largely accurate. It is no longer accurate. Google Cloud's H1 2026 Cloud Threat Horizons Report — published March 2026 and based on incident response and threat intelligence data from the second half of 2025 — documented a reversal that security leaders need to understand in precise terms: **software vulnerability exploitation has overtaken credential abuse as the primary initial access vector in cloud environments for the first time since Google began publishing this report in 2021.** **44.5% **of cloud intrusions started with third-party software vulnerability exploitation in H2 2025 Source: Google Cloud Threat Horizons Report H1 2026 **27% **of cloud intrusions used credential compromise as primary entry vector — down from majority Source: Google Cloud Threat Horizons Report H1 2026 **2.9% **was the share of exploit-first attacks in H1 2025 — by H2 2025 it had reached 44.5% Source: Google Cloud Threat Horizons Report H1 2026 The numbers document a shift that happened within a single six-month period. In the first half of 2025, exploit-based initial access accounted for less than 3% of observed incidents. By the second half of the same year, it accounted for nearly half. This is not a gradual trend — it is an accelerating pivot that caught many security teams in mid-investment cycle. ### Why the shift happened: AI-enabled exploitation The explanation lies in the interaction between two simultaneous developments: improved credential security posture among cloud users, and AI-enabled acceleration of vulnerability exploitation. Google's assessment is direct: the shift toward exploit-first attacks is likely partly a sign of defensive progress. Secure-by-default cloud configurations, improved credential hygiene, MFA enforcement, and identity monitoring have made credential-based initial access harder for attackers. Faced with better-defended credential surfaces, attackers shifted to the next available entry point: unpatched applications running on cloud infrastructure, particularly internet-facing services, virtual machines, and containers where the customer — not the hyperscaler — bears responsibility for patching. The enabling technology is AI. As Saumitra Das of Qualys explained in analysis carried by Dark Reading: exploitation has become easier because of AI-driven vulnerability analysis, penetration testing, and exploit development. LLMs allow less technically sophisticated attackers to build well-crafted reconnaissance and exploitation frameworks, expanding the pool of actors who can execute sophisticated attacks. Critically, the time from vulnerability disclosure to mass exploitation has now collapsed from weeks to days. ### The React2Shell case: 48 hours from disclosure to mass exploitation The most vivid illustration of this new timeline came with CVE-2025-55182, the critical remote code execution vulnerability in React Server Components dubbed React2Shell. When the vulnerability was publicly disclosed in December 2025, Google Cloud observed multiple threat actors exploiting it to deploy XMRig cryptocurrency mining malware within approximately 48 hours of public disclosure. By January 2026, China-linked and North Korean nation-state actors had incorporated it into their attack chains. The practical implication for IT leaders is stark. The era of the 30-day patching window, the 90-day patching window, or any patching window calibrated to historic exploitation timelines is over. In the AI-accelerated threat environment of 2026, the gap between vulnerability disclosure and active exploitation is measured in hours, not weeks. **Critical finding: **Your patching cycle is now a competitive security differentiator. Organisations that can patch critical cloud application vulnerabilities within 24 to 48 hours of disclosure operate in a fundamentally different risk environment than those on monthly or quarterly cycles. ### Identity still matters — but the model has changed It is important to note that the exploit-first finding does not mean identity is irrelevant. Google's own analysis found that identity compromise underpinned 83% of compromises involving major cloud and SaaS-hosted environments — even when the initial access vector was software exploitation. The pattern is typically: exploit the unpatched application to gain a foothold, then steal or abuse credentials to move laterally through identity infrastructure. Palo Alto Networks' Global Incident Response Report 2026 made a complementary finding: two-thirds of initial access was tied to identity in some way. The key change is that identity compromise now often follows software exploitation rather than leading it. The attack chain has changed even if the endpoint outcome has not. **Leadership implication: **Security investment programmes that are solely identity-focused are now addressing the second step of the attack chain, not the first. Cloud application patch management has become a frontline security control — not an IT operations convenience. **PART 2 **AI AS ATTACKER: SPEED, SCALE, AND THE ARMS RACE ### The AI Arms Race: 29 Minutes, 27 Seconds, and What It Means ### The CrowdStrike Global Threat Report: 2025 in numbers CrowdStrike's 2026 Global Threat Report — drawing on data from more than 280 named adversaries across 2025 — defined the year as 'the year of the evasive adversary'. The headline finding was one of the starkest metrics in recent cybersecurity history: **the average attacker breakout time — the period between initial access and lateral movement to other systems — fell to 29 minutes in 2025.** This represents a 65% acceleration from 48 minutes in 2024, and a dramatic compression from 98 minutes in 2021. The fastest observed breakout time on record: 27 seconds. In one documented intrusion, data exfiltration had begun four minutes after initial access. **29 min **average eCrime breakout time in 2025 — 65% faster than 2024 Source: CrowdStrike 2026 Global Threat Report **27 sec **fastest observed breakout time ever recorded Source: CrowdStrike 2026 Global Threat Report **89% **increase in attacks by AI-enabled adversaries in 2025 vs. 2024 Source: CrowdStrike 2026 Global Threat Report **82% **of threat detections in 2025 were malware-free — intrusions moved through trusted pathways Source: CrowdStrike 2026 Global Threat Report These numbers demand a specific leadership response, because they describe a threat environment that manual incident response processes cannot operate within. The classic security operation model — detect, investigate, escalate, respond — was designed for environments where attackers moved at human speed and needed days or weeks to complete an intrusion. An adversary who achieves lateral movement in 29 minutes on average, and in 27 seconds in the most capable cases, has already completed the intrusion before most security teams have acknowledged the first alert. ### How AI is being used by threat actors in 2025–2026 The CrowdStrike data documents five specific ways in which AI is being integrated into attacker operations, each with distinct implications for defenders: #### Reconnaissance acceleration AI-powered reconnaissance allows threat actors to map an organisation's attack surface, identify unpatched vulnerabilities, and profile employee targets faster and at greater scale than human-led research. In particular, the Clateway feed documented cases of attackers using LLMs to automate the identification of exposed cloud services, misconfigured APIs, and vulnerable application versions — compressing what previously required hours of manual research into minutes. #### AI-generated phishing and social engineering The most thoroughly documented AI application in attack operations is phishing content generation. Research cited in the Clateway feed documented LLM-generated spear phishing achieving a 54% click-through rate, compared to 12% for human-generated phishing — a 4.5-fold improvement in effectiveness. Separately, analysis cited in the feed found that agentic AI has improved spear phishing effectiveness by 55% since 2023. The Darcula phishing-as-a-service platform received an AI upgrade in 2025 that made sophisticated phishing attacks accessible to technically unsophisticated attackers. Voice phishing (vishing) — which saw a 442% increase between the first and second halves of 2024 — continued to grow through 2025, with AI-powered voice cloning enabling convincing impersonation of internal IT staff, executives, and support personnel. #### AI-generated malware VoidLink — documented in January 2026 as a modular Linux malware framework — was found to have been built almost entirely by AI agents, marking a significant milestone in autonomous malware development. AI-generated Linux miner 'Koske', documented in July 2025, was found to include features that met or exceeded what traditional human-developed malware could produce. Pakistan's APT36 threat group was documented using vibe-coding tools to generate malware at scale, even if individual samples were of lower quality — the scale advantage compensating for quality deficiencies. Russia's Fancy Bear (FANCY BEAR) deployed LLM-enabled malware named LAMEHUG, embedding prompt-based logic to automate reconnaissance and document collection. #### Defence evasion and forensic erasure AI is being used to make attacks harder to detect and investigate. Punk Spider (behind Akira ransomware) was documented using AI-generated scripts to accelerate credential dumping and systematically erase forensic evidence. Separately, 82% of CrowdStrike's detections in 2025 were malware-free — attackers moved through legitimate credentials, trusted identity flows, and approved SaaS integrations, deliberately avoiding the IOC footprints that traditional security tools detect. When attacks don't involve malware, legacy detection systems produce no signal. #### AI systems as attack targets A category of attack that was essentially non-existent in 2023 has become material by 2026: attacks that target AI systems themselves. CrowdStrike responded to incidents at more than 90 organisations where adversaries injected malicious prompts into legitimate generative AI tools deployed in enterprise operations. ClickFix attacks leveraged AI-generated content summaries to push malware. The 'ShadowLeak' attack exploited ChatGPT infrastructure to silently exfiltrate company data with no trace on enterprise systems. As AI tools become embedded in enterprise workflows, they become attack vectors as well as productivity platforms. **The defining metric: **If your mean time to detect is measured in hours and your mean time to respond is measured in days, you are operating in a threat environment where the average attacker has already achieved their objective and moved on before you have identified the incident. **Leadership implication: **Speed is now the primary competitive variable in cybersecurity. Organisations cannot out-skill adversaries who operate at machine speed — they must out-automate them. Detection, decision, and response must be automated to the greatest extent possible, with humans reserved for decisions that require judgment. **PART 3 **STATE-CRIMINAL CONVERGENCE ### The State-Criminal Convergence: Iran's MOIS and the Collapse of Attribution ### A new threat category that security operations teams are not equipped for One of the most strategically significant shifts documented in the Clateway feed from 2025 through March 2026 is the deepening integration between state intelligence services and the commercial cybercriminal underground. This is not new in concept — Russia has long employed civilian hackers and organised crime networks for state operations. What is new is the sophistication and operational depth of the integration, particularly for Iran. Check Point Research, publishing in March 2026, documented what they described as a fundamental shift in Iranian cyber operations: Iran's Ministry of Intelligence and Security (MOIS) has moved from merely impersonating cybercriminals to directly integrating criminal tools, infrastructure, and even affiliate relationships into state-directed operations. ### How MOIS has embedded in the cybercriminal ecosystem The Check Point analysis, corroborated by Palo Alto Networks Unit 42 and other sources in the Clateway feed, documented four specific mechanisms of state-criminal integration: #### Criminal malware in state operations Void Manticore — the MOIS-linked APT group that operates the 'Handala' hacktivist persona — was documented using the commercial infostealer Rhadamanthys as a core element of its attack chains. Rhadamanthys is sold on darknet forums and is used by both criminal actors and state-aligned groups. By adopting commercial criminal tools, MOIS operations become harder to attribute and attribute correctly — a SOC that sees Rhadamanthys activity may classify it as criminal rather than state-sponsored. #### RaaS affiliate participation The most striking example of state-criminal convergence in the feed period was the October 2025 attack on Israel's Shamir Medical Center. The attack was initially claimed by the Qilin ransomware group and attributed to Eastern European criminals. Three weeks later, Israel's National Cyber Directorate corrected the attribution, identifying Iranian state-affiliated operators as having acted as ransomware-as-a-service affiliates. The Iranian state was using criminal ransomware infrastructure to achieve strategic objectives while maintaining plausible deniability through the RaaS brand. As Sergey Shykevich of Check Point stated: 'there can be a case where a SOC or CISO will see something in their network that they associate with cybercrime activity and label it as low risk. And in reality, it will be an Iranian threat actor who will be able to execute destructive activities.' #### Shared criminal infrastructure MuddyWater — the MOIS-linked group responsible for widespread espionage operations across the Middle East, Africa, and Europe — was found to have infrastructure and code-signing certificate overlaps with the Tsundere/DinDoor botnet, a criminal botnet that uses Node.js and Deno-based execution methods. The botnet has been linked to MuddyWater through multiple independent sources. This represents not just tool sharing but operational infrastructure sharing — the state and criminal ecosystems are using the same command and control nodes. #### Coordinated multi-actor operations CSIS analysis of over 250,000 Telegram messages from more than 178 hacktivist and proxy groups revealed that during the June 2025 Israel-Iran military conflict, the timing, target selection, and exchange of vulnerabilities and attack scripts across ostensibly independent hacktivist groups showed patterns of orchestration rather than organic activity. The analysis concluded that these campaigns indicated institutional backing and coordination rather than spontaneous hacktivist mobilisation. Multiple 'independent' hacktivist groups were effectively extensions of state cyber operations. ### The Stryker incident: a case study in geopolitically motivated destructive attack On the morning of March 11, 2026 — two weeks after US-Israeli military operations known as 'Operation Epic Fury' began against Iran — Stryker Corporation, one of the world's largest medical technology companies with over $25 billion in annual revenue, suffered a coordinated wiper attack. By mid-morning, employees across 79 countries could not access their systems. Mobile devices had been wiped to factory settings. Login screens on some devices displayed the logo of 'Handala' — the ostensibly pro-Palestinian hacktivist group that is, in fact, **Void Manticore**, a MOIS-run APT. The scale of disruption was extraordinary by enterprise standards: - Stryker internally described the attack as a 'severe, global outage impacting all Stryker laptops and systems that connect to our network.' - Handala claimed 200,000 systems, servers, and mobile devices wiped; 50TB of data exfiltrated; operations disrupted in 79 countries. - Maryland's Institute for Emergency Medical Services notified hospitals statewide that Stryker's Lifenet ECG transmission system was 'non-functional in most parts of the state,' requiring EMS clinicians to use radio consultation rather than electronic transmission. - Ireland's National Cyber Security Centre launched an investigation. Microsoft engineers assisted with forensic analysis and recovery. - Stryker shares fell more than 3% following media reports of the breach. - The Stryker attack represented the first time Handala/Void Manticore had targeted a major US business — a significant escalation noted by Check Point Research. The attack was enabled by a technique that Iran has used before and that Tenable's analysis documented as increasingly prevalent: pre-positioning. Nation-state hackers often infiltrate an organisation months before any visible action. The Stryker attack likely involved access gained before February 28, 2026 — the attackers were in position and waiting for a geopolitical trigger. When US-Israeli strikes on Iran began, the command was executed. Iran concurrently announced new targeting priorities, specifically naming Amazon AWS, Google, Microsoft, Oracle, Palantir, and Nvidia as organisations that the IRGC had threatened to attack. Drone strikes had already disrupted AWS data centres in the UAE and Bahrain. The Stryker incident was not an isolated event — it was the first visible operation of a broader retaliatory campaign. **Board-level concern: **The Stryker incident demonstrates that enterprise IT infrastructure is now a legitimate target in geopolitical conflicts, even for organisations with no direct government or defence connections. The trigger for a destructive attack can be a missile strike in a country your company has no operations in. **Leadership implication: **The state-criminal convergence means your SOC's attribution logic is now a security control. An incident classified as 'low-risk criminal activity' may be a MOIS or FSB operation. Update your threat classification model to treat unattributed ransomware and infostealer activity at critical targets as potentially state-sponsored until demonstrated otherwise. **PART 4 **THE AI-POWERED PHISHING EPIDEMIC ### Phishing Reinvented: When AI Breaks the Human Firewall ### The effectiveness gap that training cannot close For years, the standard enterprise response to phishing was a combination of email gateway filtering and employee awareness training. Both were imperfect, but together they created sufficient friction to limit the volume of successful attacks. The AI-powered evolution of phishing in 2025–2026 has fundamentally altered that equation — and the alteration is not marginal. The data points are consistent across multiple sources in the Clateway feed. LLM-generated spear phishing achieves a 54% click-through rate versus 12% for human-generated attempts. AI-assisted spear phishing is 55% more effective than previous techniques. AI-generated phishing content personalised to individual targets is now being produced at scale — the Darcula PhaaS platform's AI upgrade in 2025 made it accessible to non-technical actors. Traditional awareness training was designed to help employees recognise generic phishing lures. It was not designed for, and cannot reliably defend against, personalised, contextually accurate, grammatically flawless attacks generated by LLMs with access to LinkedIn, public company information, and email address formats. ### The evolution of attack vectors: phishing is going mobile The Clateway feed documented a consistent theme across 2025–2026: phishing is migrating away from email — where defences have improved — toward channels where enterprise defences are structurally weaker. The most significant developments: #### Telephone-oriented attack delivery (TOAD) TOAD attacks — where the only payload in a phishing email is a phone number — are bypassing email gateways entirely, because there is nothing malicious in the message for content filters to detect. Victims call a number and are socially engineered by a human operator or, increasingly, an AI voice agent impersonating IT support or a vendor. The callback rate for TOAD campaigns is significantly higher than for link-based phishing, partly because the phone call triggers social compliance norms that email does not. #### AI voice cloning and vishing Voice phishing (vishing) increased by 442% between the first and second halves of 2024, continuing its growth through 2025. AI-powered voice cloning has eliminated one of the traditional tells of vishing attacks — an unfamiliar accent or unnatural speech pattern. A researcher-developed framework documented in September 2025 demonstrated real-time voice cloning that could impersonate specific individuals during live phone calls, with sufficient fidelity to compromise help desk workflows that rely on voice authentication. ShinyHunters' expansion into vishing for SaaS data theft — documented in January 2026 — showed this technique being operationalised at scale by financially motivated criminal groups. #### QR code phishing (quishing) QR codes have become a common phishing vector because they bypass email link filtering — email security tools cannot easily assess where a QR code leads. The Anti-Phishing Working Group documented a significant increase in QR-code-based phishing campaigns through 2025. North Korean Kimsuky group was specifically cited by the FBI for quishing attacks against US and foreign government agencies. #### SMS and mobile-first attacks Chinese 'Smishing Triad' groups — which became notorious through fake toll and package tracking texts — were documented shifting toward lower-frequency, higher-impact government impersonation attacks. 'Lighthouse', a phishing-as-a-service operation Google worked to disrupt in November 2025, had powered massive volumes of mobile phishing campaigns across the US. The shift is structural: mobile devices have weaker phishing defences, users have higher trust in SMS communications, and enterprise mobile security controls are less mature than email security. ### When phishing breaks the AI itself A final category documented extensively in the Clateway feed is the use of phishing-style techniques to compromise AI systems deployed in enterprise operations. The 'ShadowLeak' attack in September 2025 exploited ChatGPT infrastructure to exfiltrate company data without leaving traces on enterprise systems. EchoLeak — a zero-click Microsoft Copilot vulnerability disclosed in June 2025 — could have enabled data exfiltration via AI-generated summaries triggered by malicious content in emails or documents. ClickFix attacks evolved to include AI-generated content summaries that pushed malware installation — victims were more likely to follow instructions that appeared to come from an AI tool they trusted. The pattern is consistent: as AI tools become integrated into enterprise workflows, the attack surface for social engineering expands. Attackers are now crafting content not to deceive humans, but to deceive or exploit the AI systems that humans have delegated decisions to. **Leadership implication: **Employee phishing awareness training has not lost its value, but it has lost its sufficiency. Technical controls — identity verification for help desk calls, hardware MFA resistant to real-time phishing, AI-aware email and mobile security, and explicit policies about what actions AI assistants are authorised to take — must carry the weight that human judgment alone cannot bear. **PART 5 **THE DISASTER RECOVERY REALITY ### Disaster Recovery in the Age of Wiper Attacks ### Why the Stryker incident is a stress test most organisations will fail The Stryker attack illuminated a gap in enterprise business continuity and disaster recovery planning that Dark Reading's post-incident analysis identified directly: most DR plans are designed for infrastructure failures, not adversarial destruction. They test against scenarios where systems go offline due to hardware failure, software bugs, or ransomware encryption. They rarely test against scenarios where an adversary with Active Directory access wipes all endpoints simultaneously, in 79 countries, within minutes. In Stryker's case, security experts assessed that the attackers gained access to Stryker's Active Directory services and used Microsoft Intune — the legitimate enterprise endpoint management platform — to issue a device wipe command at scale. The attack did not require the deployment of custom malware to each endpoint. It leveraged the organisation's own management infrastructure against itself. This is a qualitatively different kind of attack than the ransomware scenarios that most DR tabletops simulate. ### The three DR gaps the Stryker incident exposed #### Gap 1: Active Directory and identity infrastructure as a single point of failure If an attacker gains control of Active Directory, they have effective control of every endpoint, server, and service connected to it. Most enterprise DR plans do not include a scenario where Active Directory itself is compromised. The recovery from AD compromise — rebuilding directory services, re-issuing credentials, re-enrolling devices — can take weeks, not hours, and requires a level of preparation that most organisations have not made. #### Gap 2: Endpoint management platforms as attack amplifiers Microsoft Intune, Jamf, and equivalent endpoint management platforms are powerful administrative tools. They are also powerful attack amplifiers if an attacker gains sufficient privileges. An attacker who can issue commands through Intune can wipe every managed device in the organisation simultaneously. Most DR plans treat endpoint management tools as part of the recovery toolkit. They should also be treated as a risk that requires protective controls — including multi-person authorisation for mass device operations, network segmentation of management infrastructure, and out-of-band verification for destructive commands. #### Gap 3: Operational continuity without IT For a medical technology company like Stryker, the DR failure was not abstract. Maryland hospitals lost access to ECG transmission systems that paramedics relied upon for real-time cardiac monitoring during transport. The medical impact was limited in this case, but the scenario — enterprise IT failure cascading into critical operational system failure — is one that every organisation in healthcare, manufacturing, financial services, and critical infrastructure needs to have tested. ### What a resilience programme must include in 2026 The Clateway feed's security signals from 2025–2026 point to five requirements for a DR programme that is fit for the current threat environment: - Adversarial DR testing: Run tabletop exercises against a sophisticated adversary who has gained Active Directory access — not a ransomware scenario alone. Measure recovery time from AD compromise, not just from data encryption. - Out-of-band management: Ensure that critical infrastructure can be managed and communicated about through channels that are not dependent on the corporate Microsoft environment. This includes emergency communication plans that do not rely on corporate email, Slack, or Teams. - Endpoint backup and re-provisioning: Maintain clean device images, secure out-of-band backup systems, and tested processes for emergency re-provisioning of endpoints. The ability to rebuild a device estate at speed is now a DR capability requirement. - Privileged action controls: Implement multi-person authorisation for any mass device management operations, configuration changes to identity systems, and mass account modifications. - Cascade impact mapping: For each critical IT system, map the operational systems that depend on it. Know in advance what happens when Intune goes dark, when AD is compromised, when your SaaS CRM is inaccessible. Have manual fallback procedures documented and tested. **The CrowdStrike benchmark: **One year after the July 2024 CrowdStrike outage — which affected 8.5 million Windows endpoints — the post-incident review found that organisations had not learned the lesson about technology concentration risk. The Stryker wiper attack is the adversarial version of that event. The lesson is the same: concentration of critical operational functions in a single IT dependency is an existential risk. **PART 6 **THE LEADERSHIP AGENDA ### The RCEC Response: Security in the AI-Inflection Era The four developments documented in this article — exploit-first cloud attacks, AI-accelerated attacker speed, state-criminal convergence, and AI-powered phishing — are not independent trends. They are mutually reinforcing dimensions of a single structural shift: cybersecurity has entered an era in which the primary variable is not the sophistication of any individual attack, but the fundamental speed advantage that AI-enabled adversaries hold over manually-operated defences. Responding to this shift requires decisions at every level of the RCEC framework: ### Research: Intelligence for a new threat model - **Rebuild your threat model: **Explicitly include AI-enabled attack vectors, exploit-first cloud intrusion patterns, state-criminal actor scenarios, and destructive wiper attacks. A threat model that was built in 2023 or 2024 is operating on assumptions that no longer hold. - **Instrument for exploit detection: **If your primary detection logic is built around malware signatures and known-bad indicators, you are detecting 18% of modern intrusions. Behaviour-based detection, anomaly detection in identity flows, and application-layer monitoring for exploitation patterns are now baseline requirements. - **Subscribe to operational threat intelligence: **The geopolitical context of your threat environment now matters. The Stryker attack was preceded by weeks of public warnings about Iranian cyber retaliation. Organisations that were monitoring CISA advisories and commercial threat intelligence had warning. Many were not watching. ### Commit: Board-level security decisions - **Authorise automated response: **The 29-minute average breakout time makes manual incident response inadequate as a primary defence. Authorise security operations to implement automated detection and containment capabilities — including automated network isolation, automated credential revocation, and automated alert escalation — without requiring manual approval for each action. - **Reframe patching as a security control: **The collapse of the vulnerability-to-exploitation window makes patching velocity a board-level metric. Set a target for critical vulnerability patching within 48 hours of public disclosure for internet-facing cloud applications. Report this metric to the board alongside other security KPIs. - **Commission an AD resilience review: **Assess your organisation's ability to detect, contain, and recover from an Active Directory compromise. If you cannot answer the question 'how long would it take to rebuild our AD from scratch?' with confidence, you have a material DR gap. ### Execute: The operational capabilities - **Deploy AI-powered defence: **Adversaries are using AI to operate at machine speed. Defenders must do the same. AI-powered security operations platforms — including SIEM with AI-driven detection, automated threat hunting, and AI-assisted incident response — are now operational necessities, not advanced capabilities. - **Harden phishing-resistant MFA: **FIDO2 hardware keys or passkeys eliminate the real-time phishing vulnerability of TOTP-based MFA. Given the documented effectiveness of AI-powered phishing and vishing, organisations in high-risk sectors should be prioritising phishing-resistant MFA for all privileged accounts as a matter of urgency. - **Establish out-of-band communication: **Define and test an emergency communication process that is completely independent of your corporate Microsoft environment. This includes a secondary channel for IT staff coordination, a mechanism for customer and partner notification, and a documented decision authority structure that does not require access to corporate systems. ### Control: Monitoring for the AI-era threat - **Measure MTTD and MTTR against the 29-minute standard: **If your mean time to detect exceeds 29 minutes for a cloud intrusion, the average attacker has already achieved lateral movement before detection. Benchmark your current MTTD and MTTR, identify the gap, and build a roadmap to close it. - **Monitor endpoint management platforms: **Intune, Jamf, and equivalent platforms should be instrumented with anomaly detection for high-impact operations — particularly mass device commands, policy changes, and bulk account modifications. Alert on any operation that affects more than a defined threshold of endpoints in a single action. - **Include geopolitical triggers in your threat monitoring: **Subscribe to threat intelligence that covers geopolitical context. When nation-state cyber escalation is publicly anticipated — as it was before the Stryker attack — elevate your alert posture, review exposure of critical systems, and activate pre-positioned response capabilities. ### Conclusion: Security Has Crossed a Threshold The cybersecurity signals in the Clateway Media feed from April 2025 to March 2026 do not describe an incremental worsening of a familiar threat landscape. They describe a threshold crossing. The combination of AI-accelerated attack speed, the exploit-first reversal in cloud intrusions, the operational integration of state and criminal actors, and the demonstrated effectiveness of AI-powered phishing against the human firewall represents a qualitative change in the nature of the threat. The organisations that will navigate this environment effectively are not necessarily those with the largest security budgets or the most sophisticated tools. They are the organisations that have made the governance decisions — about automation authority, patching velocity, DR investment, and threat intelligence consumption — that allow them to operate at a speed appropriate to the threat. Speed, not complexity, is the defining variable. For Clateway clients and the IT leaders who read Clateway Insights, the message is direct: the security architecture you built for a 2023 threat environment is operating at a structural disadvantage in 2026. The gap is not insurmountable, but it requires deliberate action — and the window for deliberate, unhurried remediation is shorter than it was twelve months ago. **The adversary is operating at machine speed. Your defence must too.** ### Key Statistics Referenced in This Article **Cloud attacks: **Software exploitation overtook credentials as primary cloud initial access vector in H2 2025. Third-party software entry: 44.5% of incidents (from 2.9% in H1 2025). Credential abuse: 27%. Window from vulnerability disclosure to mass exploitation: now days, not weeks (Google Cloud Threat Horizons H1 2026). **Attack speed: **Average eCrime breakout time: 29 minutes in 2025 (down from 48 in 2024, 98 in 2021). Fastest observed: 27 seconds. 82% of detections malware-free. 89% increase in AI-enabled attacker operations. 37% increase in cloud-conscious intrusions (CrowdStrike 2026 Global Threat Report). **Phishing effectiveness: **LLM-generated spear phishing click-through rate: 54% vs 12% for human-crafted. AI-assisted spear phishing 55% more effective since 2023. Vishing increased 442% in H2 2024 vs H1 2024. **Stryker/Iran: **200,000 systems claimed wiped. 50TB data exfiltrated claimed. Operations disrupted in 79 countries. ECG systems non-functional in most of Maryland (March 11, 2026). Handala = Void Manticore = MOIS APT (Check Point, Palo Alto Networks Unit 42, CrowdStrike). **State-criminal convergence: **Iran MOIS using commercial infostealers, RaaS affiliates, criminal botnets in state operations. Shamir Medical Center attack initially attributed to Qilin/Eastern European crime — corrected to Iranian state operators. North Korea FAMOUS CHOLLIMA's PRESSURE CHOLLIMA stole $1.46B in crypto — largest single financial theft ever reported. ### 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 2 of the Clateway Insights Trend Report 2025–2026, covering the six dominant trends identified from 5,000 news signals in the Clateway Media feed. For advisory engagements, executive roundtables, or the Clateway Academy fractional leadership programme, visit www.clateway.com. --- ## Six Trends Every IT Leader Must Act on Now URL: https://clateway.com/articles/six-trends-every-it-leader-must-act-on-now Published: 2026-03-15 · Clateway Technology Council Key takeaways: A synthesis of 5,000 technology news signals — distilled into the six forces reshaping enterprise IT leadership in 2025–2026. **TECHNOLOGY TREND REPORT** March 2025 – March 2026 **Six Trends Every IT Leader Must Act on Now** A synthesis of 5,000 technology news signals — distilled into the six forces reshaping enterprise IT leadership in 2025–2026. Over the twelve months from April 2025 to March 2026, Clateway Media tracked more than 5,000 technology news signals across AI, cybersecurity, cloud infrastructure, regulatory compliance, identity management, and geopolitics. The patterns that emerge are not incremental updates — they represent a structural inflection point in how IT organisations operate, defend themselves, and create value. This report synthesises those signals into six dominant trends. For each, we identify the signal strength from the news feed, translate it into what it means for the IT leadership agenda, and frame it through the lens of the RCEC methodology — Research, Commit, Execute, Control — that anchors the Clateway practice. **The central message: **AI has moved from a technology experiment to a structural operating assumption. Security has moved from a cost centre to an existential board concern. And the window for leaders who are still 'evaluating' is closing rapidly. **TREND 01** ### The Agentic AI Shift: From Copilot to Autonomous Worker The most significant structural shift in the feed is the transition from AI-as-assistant to AI-as-autonomous-agent. Where 2023–2024 was dominated by chat interfaces and generative tools, 2025–2026 is defined by agents that plan, execute, and iterate without human handholding. AWS's launch of managed AI agent deployment on Lightsail, the rapid growth of multi-agent orchestration frameworks, and the emergence of agentic development patterns — popularised through 'vibe coding' experiments — collectively signal that the architecture of digital work is being redesigned. The implications for IT leaders are profound. Agentic systems are not plugins — they require governance structures, access control policies, audit trails, and failure recovery protocols. The Clateway news feed surfaced the security exposure directly: a 250,000-star AI agent framework was found to carry a critical remote code execution vulnerability with over 17,500 vulnerable instances exposed publicly, while 20% of third-party agent skill packages were identified as malicious. **Leadership implication: **Every IT leader needs an AI agent governance policy before they need an AI agent deployment. The question is not whether autonomous agents will enter your environment — they already are, through shadow IT and vendor platforms. The question is whether you govern them or they govern you. ### What to do now - Establish an AI agent inventory: map every agentic capability already active across SaaS vendors, developer toolchains, and IT operations platforms. - Define a minimum security baseline for agent deployment: identity, scope limits, logging, and kill-switch protocols. - Position AI agent governance as a board-level risk item, not an IT architecture decision. **TREND 02** ### Cybersecurity at the AI Inflection Point Cybersecurity was the single highest-volume topic in the Clateway feed, accounting for over 1,400 signals across the year. But the nature of the threat landscape shifted materially. The defining change: AI has equalised attacker and defender capabilities in ways that favour well-resourced, fast-moving actors — which means nation-states and organised crime, not underfunded IT teams. Three patterns dominate. First, exploit-first attacks: Google Cloud threat intelligence found that the majority of cloud environment compromises now begin with vulnerability exploitation rather than credential theft — upending years of security investment focused on identity. Second, state-sponsored collusion: Iran's MOIS was documented actively collaborating with cybercriminal groups, blurring the line between geopolitical espionage and commercial ransomware. Third, AI-accelerated social engineering: phishing attacks now use personalised AI-generated content that bypasses on-device detection with troubling frequency, while fake proof-of-concept exploits for high-profile vulnerabilities are being weaponised to create chaos in patch management processes. The Stryker cyberattack — attributed to Iranian threat actors — provided the year's most important case study. It exposed how unprepared most business continuity and disaster recovery programmes are for the speed and coordination of modern attacks. **Leadership implication: **Security posture can no longer be assessed against last year's threat model. The combination of AI-powered attacks, state-criminal collusion, and exploit-first entry vectors demands a fundamental reassessment of detection, response, and recovery architecture. ### What to do now - Rerun your DR and incident response playbooks against an AI-augmented adversarial scenario — not a compliance checklist. - Shift investment from identity-only security towards vulnerability management velocity: your patch cycle is now a competitive security advantage. - Brief your board on the state-criminal convergence risk — this is no longer a theoretical CISO concern. **TREND 03** ### Cloud Infrastructure Matures — And Gets Complicated Cloud infrastructure dominated the feed in volume — over 1,400 signals — but the story is no longer about migration. The 2025–2026 theme is operational maturity, power constraints, and the Kubernetes consolidation. AWS marked 20 years of S3, introducing S3 Vectors and S3 Tables as signals of where cloud-native data architecture is heading. KubeCon EU 2026 confirmed Kubernetes as the dominant abstraction layer for enterprise workloads. And the EU's landmark investment of €1.3 billion in cloud, AI, and cybersecurity infrastructure signalled that public sector cloud is entering its second act. The most underreported cloud story of the year, however, is power. The Clateway feed surfaced a growing number of signals around data centre power constraints in the United States and Europe — where hyperscaler construction programmes are outpacing grid capacity. For enterprise IT leaders, this creates a new dimension of cloud vendor risk: availability SLAs may be limited not by software or network failures, but by energy infrastructure. **Leadership implication: **Cloud strategy in 2026 must account for power supply chain risk, not just vendor lock-in or cost. Multi-cloud architecture decisions should now include energy resilience as a selection criterion for critical workloads. ### What to do now - Add energy availability and grid resilience to your cloud vendor assessment criteria for Tier 1 workloads. - Review your cloud security model against an exploit-first threat scenario — not just access control and misconfiguration. - Map your Kubernetes estate: most organisations now have more clusters than they can account for. **TREND 04** ### Identity Is the New Perimeter — And It Is Under Siege Identity and access management generated close to 250 signals in the feed — a number that understates its importance, since identity underpins nearly every other trend. The defining development: privileged access management (PAM) is being redefined by the emergence of machine identities. Delinea's acquisition of StrongDM — which specialises in ephemeral, real-time credential injection into developer workflows — signals the direction of the market: PAM is no longer primarily about human privileged users. It is about the proliferation of service accounts, API keys, CI/CD pipeline credentials, and AI agent identities that now outnumber human identities in most enterprise environments. The parallel development is the IAM challenge posed by multi-agent AI architectures. The Clateway feed surfaced analysis showing that a single IAM system cannot effectively govern the dynamic, context-switching identity requirements of autonomous agent networks. This is a structural gap in most enterprise identity architectures — one that vendors are racing to address, but which creates meaningful risk in the interim. **Leadership implication: **Your IAM programme almost certainly does not account for machine identity at scale. Before deploying the next AI system or cloud-native service, audit your non-human identity estate. The attack surface you don't know about is the one that will be exploited. ### What to do now - Commission a non-human identity audit: service accounts, API keys, pipeline credentials, and AI agent identities across your estate. - Evaluate whether your PAM solution is architected for ephemeral, just-in-time access — or designed for a world of standing privileges. - Integrate Zero Trust progress into your [DORA](https://clateway.com/glossary/dora) and [NIS2](https://clateway.com/glossary/nis2) compliance reporting. **TREND 05** ### Regulation as Architecture: DORA, NIS2, and AI Governance Regulatory signals in the feed clustered around three vectors: EU digital operational resilience (DORA going live), network and information security expansion (NIS2), and the emerging global [AI governance](https://clateway.com/glossary/ai-governance) frameworks. Taken together, they represent a structural shift in the relationship between technology leadership and legal obligation. Compliance is no longer a back-office function — it is an architectural constraint that must be embedded into system design, vendor selection, and operational processes from the outset. DORA is the most consequential near-term obligation for financial services IT leaders in the EU. The feed surfaced consistent signals of organisations underestimating the operational burden of DORA's ICT [third-party risk management](https://clateway.com/glossary/third-party-risk-management) requirements — particularly the obligation to perform comprehensive risk assessments of all ICT suppliers, including cloud providers and SaaS vendors. The EU's Cloud CISO Perspectives series emphasised digital sovereignty as the integrating concept: the ability of organisations to maintain meaningful control over their data, infrastructure, and AI systems. **Leadership implication: **Regulation is now a design input, not a post-deployment audit. IT leaders who treat DORA, NIS2, and AI governance as compliance exercises will build architectures that need to be rebuilt. Those who treat them as design constraints will build durable systems. ### What to do now - Map your DORA ICT third-party risk inventory now — the assessment obligations are more extensive than most organisations have budgeted for. - Build digital sovereignty requirements into your cloud and SaaS procurement process as a standing selection criterion. - Develop a cross-framework compliance view (DORA + NIS2 + [AI Act](https://clateway.com/glossary/eu-ai-act)) to identify shared control requirements and avoid redundant effort. **TREND 06** ### Geopolitical Technology Risk Becomes an IT Leadership Issue Nearly 400 signals in the feed touched the intersection of geopolitics and technology — a category that would have been considered peripheral to IT leadership five years ago. In 2025–2026, it is central. The TikTok divestiture saga, with a $10 billion fee to the Trump administration, exemplified the new reality: technology platforms are geopolitical assets, and governments are willing to intervene directly in corporate technology decisions. For IT leaders at multinationals, this creates a new category of technology risk that sits above the traditional security and compliance stack. The Iranian cyberattack on Stryker, the documented collusion between the Iranian MOIS and cybercriminal networks, the Chinese APT shift to new target geographies, and the US policy confusion around commercial spyware collectively illustrate a threat environment where IT infrastructure is a theatre of geopolitical competition. For European IT leaders specifically, the US policy environment introduced new unpredictability into transatlantic technology relationships — from tariffs on technology components to shifting stances on international cyber cooperation. **Leadership implication: **Geopolitical technology risk belongs on the enterprise [risk register](https://clateway.com/glossary/risk-register) alongside operational and financial risk. IT leaders who are not proactively briefing their boards on technology sovereignty, supply chain exposure, and nation-state threat actors are leaving a material gap in enterprise risk governance. ### What to do now - Add geopolitical technology risk as a standing agenda item in your risk committee reporting. - Review your critical technology supply chain for components or vendors with high exposure to US-China or US-EU regulatory tension. - Develop a technology sovereignty position — including data residency, vendor nationality, and jurisdictional access policies — as part of your IT strategy. ### The Integrated Leadership Agenda What makes 2025–2026 distinctive is not that any one of these trends is new — it is that all six are accelerating simultaneously, and they are deeply interconnected. Agentic AI creates new identity risks. Cloud maturity creates new power and sovereignty dependencies. Regulatory frameworks are being written in real time as the technology they govern is already being deployed. And geopolitical volatility makes every architectural decision a political one. For IT leaders operating through the Clateway RCEC framework, this means: - Research: the intelligence function must now track geopolitical and regulatory signals with the same rigour as technology signals. - Commit: governance decisions — on AI agents, identity architecture, cloud sovereignty, and regulatory alignment — need to be made at board level, not delegated to operations. - Execute: delivery programmes must be designed with regulatory and security constraints as first-class requirements, not late-stage additions. - Control: monitoring and reporting must surface AI, security, identity, and compliance risks in a single integrated view — not as separate domain silos. The organisations that will lead through this period are not those with the most sophisticated technology. They are those with the clearest governance structures, the most disciplined decision frameworks, and the leaders who can translate technical complexity into strategic clarity. **That is the Clateway proposition. And the market has never needed it more.** ### 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. Clateway Insights publishes regular analysis of technology trends for IT leadership audiences. For advisory engagements, executive roundtables, or the Clateway Academy fractional leadership programme, visit www.clateway.com. --- ## Strategic Analysis: Impact Of Ai On Management Consulting Effectivenes URL: https://clateway.com/articles/strategic-analysis-impact-of-ai-on-management-consulting-effectivenes Published: 2026-03-11 · Clateway Technology Council Key takeaways: Strategic Analysis: Impact Of Ai On Management Consulting Effectivenes Executive Summary The integration of AI into management consulting is reshaping the industry in profound ways, challenging... ### Executive Summary The integration of AI into management consulting is reshaping the industry in new ways, challenging traditional business models and enhancing efficiency. AI's capabilities in data analysis and insight generation are augmenting human consultants rather than replacing them, allowing for a focus on more strategic and creative tasks [1, 6, 7]. The consulting landscape is experiencing a shift from purely analytical roles to ones that emphasize human judgment and strategic insight, as AI tools automate routine tasks and enhance decision-making [3, 11]. A significant trend is the transformation of consulting firm structures and recruitment practices, with AI enabling leaner operations and altering talent strategies [2, 15]. Despite fears of obsolescence, the human element remains crucial, as AI serves as a complementary tool that enhances the value consultants provide [9, 12]. However, ethical considerations and the need for AI literacy are emerging as critical challenges for both consultants and clients [10, 5]. ### Key Insights - AI tools are enhancing efficiency by automating data analysis and routine tasks, allowing consultants to focus on high-value activities [1, 6]. - The demand for AI literacy among consultants is increasing, necessitating new skill sets to navigate AI-driven consulting environments [10]. - AI is reshaping recruitment strategies in consulting firms, emphasizing the need for skills beyond traditional analytical capabilities [2]. - The consulting industry is not becoming obsolete; instead, it is evolving with AI redefining the role and value of human consultants [7]. - AI-driven consulting services are projected to grow significantly, with major firms like BCG and EY seeing substantial revenue increases from AI initiatives [11]. - Ethical considerations around AI use in consulting are becoming more prominent, highlighting the need for responsible AI deployment [5, 10]. - The traditional consulting pyramid model is becoming more profitable as AI reduces operational costs and enhances service delivery [12]. - AI is facilitating a dual mandate for consultants, who are now expected to drive both growth and efficiency simultaneously [4]. - AI's impact is prompting strategic shifts in consulting firm structures, with new roles and business models emerging [15]. - Mid-size consulting firms face unique challenges and opportunities in leveraging AI to compete with larger and smaller firms [8]. ### Business Impact The integration of AI into management consulting is transforming business operations by enabling consultants to deliver faster, more accurate insights and strategies. This transformation is leading to reduced operational costs and improved service delivery, as AI handles tasks that were traditionally time-consuming [12]. For firms, this means a shift in their strategic priorities, focusing more on leveraging AI for competitive advantage and client value creation [13]. In the short term, firms need to invest in AI literacy and ethical AI practices to ensure sustainable growth and client trust [10]. In the long term, AI's role in consulting will likely expand, necessitating continuous adaptation of business models and strategies to remain competitive in an AI-driven landscape [15]. ### Recommendations - Invest in AI literacy programs for consultants to ensure they can effectively leverage AI tools in their work [10]. - Revise recruitment strategies to prioritize candidates with skills in AI and data analytics, alongside traditional consulting skills [2]. - Develop ethical guidelines and frameworks for AI deployment in consulting to address client concerns and ensure responsible use [5]. - Explore new business models that integrate AI capabilities to enhance service offerings and client engagement [15]. - Focus on building complementary AI-human workflows to maximize the strategic value offered to clients [7]. - Form partnerships with AI technology providers to access cutting-edge tools and stay ahead of industry trends [13]. - Encourage cross-functional teams that combine AI experts with traditional consultants to innovate and solve complex client challenges [6]. --- ## AI leapfrogging increases company valuation URL: https://clateway.com/articles/ai-leapfrogging-generates-company-value Published: 2026-03-11 · Clateway Technology Council Key takeaways: Ai and digital transformation as company value creator ### AI Leapfrogging: Generating Company Value Through Digital Transformation Artificial intelligence (AI) has fundamentally reshaped the business landscape, providing companies with new opportunities to fundamentally redesign their company and their value propositions. By integrating AI into their operations, organizations can not only streamline processes but also create a more agile and responsive business model. This article explores how AI leapfrogging generates company value, particularly by reducing manpower needs, lowering costs, and necessitating a comprehensive digital transformation. ### AI and Workforce Efficiency #### Reduced Manpower Needs One of the most significant advantages of AI is its ability to automate repetitive tasks that traditionally require human intervention. By implementing AI-driven solutions, companies can: - **Minimize Human Error**: AI systems can execute tasks with a high degree of accuracy, reducing the risks associated with human mistakes. - **Focus on Strategic Roles**: With AI handling mundane tasks, employees can concentrate on high-value activities that require critical thinking and creativity. This shift not only improves efficiency but also allows organizations to operate with leaner teams, ultimately reducing the overall workforce required for specific operations. ### Cost Reductions Across Business Functions #### Development Costs AI technologies can significantly lower development costs by: - **Accelerating Product Development**: Machine learning algorithms can analyze vast amounts of data, providing insights quicker than traditional research methods. - **Streamlining Testing Processes**: AI can predict potential flaws in products and suggest improvements, reducing time and resources spent on testing. #### Marketing Expenses AI's role in marketing is transformative, enabling companies to: - **Target Audiences More Accurately**: AI algorithms analyze consumer behavior and preferences, allowing for highly personalized marketing campaigns. - **Optimize Campaign Performance**: Automated analytics can assess campaign effectiveness in real-time, facilitating quick adjustments and resource allocation. #### Sales Cost Efficiency In sales, AI can enhance efficiency by: - **Improving Lead Scoring**: AI systems can evaluate potential leads based on historical data, helping sales teams prioritize their efforts. - **Automating Follow-Ups**: Chatbots and virtual assistants can handle initial contact and follow-up communications, freeing sales personnel for more complex interactions. ### The Interplay Between AI and Digital Transformation #### A Necessity for Digital Processes and Data To fully leverage AI's capabilities, organizations must undergo digital transformation. This involves: - **Digitizing Processes**: Traditional business processes must be re-engineered to incorporate digital workflows that AI can optimize. - **Utilizing Digital Data**: Access to high-quality, real-time data is crucial for AI algorithms to function effectively. Companies that embrace digital transformation alongside AI find that they can not only enhance operational efficiency but also drive innovation and customer engagement. ### A Fundamental Redesign of Thinking and Processes #### Rethinking Business Models The integration of AI necessitates a complete re-evaluation of existing business models. Organizations must adopt a mindset that emphasizes: - **Agility**: Companies need to be adaptable to rapid changes brought by AI technologies. - **Collaboration**: Cross-functional teams should work together to identify opportunities for AI implementation and optimization. This fundamental redesign of thinking and processes is essential for fully capitalizing on the benefits of AI. ### The CTO: The New Superhero of the Digital Era #### Expanding Competence and Skills In this new landscape, Chief Technology Officers (CTOs) are gaining "superpowers" due to the breadth of skills and competencies required to harness AI effectively. Their roles now involve: - **Strategic Vision**: CTOs must envision how AI can be integrated across various departments. - **Technical Expertise**: Understanding the complexities of AI technologies enables CTOs to make informed decisions on implementation and scaling. - **Change Management**: Leading organizational change is critical as teams adapt to new workflows and technologies. ### Enhancing Company Value in the Market #### Market Valuation Through Redesign A complete redesign of business processes through AI and digital transformation can significantly enhance a company's market value. This improvement can be attributed to: - **Increased Efficiency**: Streamlined operations lead to lower operational costs and higher profit margins. - **Enhanced Customer Experience**: Personalized services and faster response times can improve customer satisfaction and loyalty. - **Innovative Offerings**: AI-driven insights can lead to the development of new products or services that meet emerging market needs. ### Conclusion AI leapfrogging represents a pivotal opportunity for companies to create substantial value through digital transformation. By reducing manpower needs, cutting costs across multiple business functions, and necessitating a fundamental redesign of processes and thinking, organizations can enhance their market position. With CTOs at the helm, navigating the complexities of AI integration, companies are equipped to thrive in an increasingly competitive landscape. Embracing this transformation is not just an option; it is essential for sustainable growth and market leadership.