“Your company is using AI. Who is personally responsible if something goes wrong with it?”

The room usually goes quiet.

Not because people don’t care. But because the honest answer, in most organizations, is: nobody, really. The developers built it. The vendor manages it. The CISO “oversees it” in the broadest possible sense. And somewhere in that triangle of vague accountability, real risk is accumulating — quietly, every day.

This is the AI governance gap. And in 2025, it’s no longer theoretical.

AI Is Already Inside Your Enterprise. Is It Secure?

Think about where AI systems are actually operating right now in the average mid-to-large organization:

• Customer service chatbots handling sensitive queries

• Fraud detection models making real-time financial decisions

• HR tools screening candidates and summarizing performance reviews

• GenAI assistants with access to internal documents and email

Each of these systems has an attack surface. Each can be manipulated, poisoned, abused, or made to leak data — through techniques most security teams have never trained for.

Prompt injection. Model inversion. Data poisoning. Adversarial inputs. Deepfake-enabled social engineering.

These aren’t science fiction. They’re in the MITRE ATLAS framework. They’re in the OWASP LLM Top 10. They’re already being exploited in the wild.

And yet, most organizations approach AI security the same way they approached cloud security in 2012: as an afterthought.

The Regulation Is Coming. Ready or Not.

The EU AI Act is now in force. NIST has published its AI Risk Management Framework. ISO/IEC 42001 defines requirements for AI management systems. Boards are asking questions. Regulators are drafting guidance.

The compliance window is closing — and organizations that haven’t built internal AI governance capacity are going to feel it.

Here’s the uncomfortable truth: you cannot comply with AI regulation using traditional cybersecurity skills alone. AI risk requires a different vocabulary, a different threat model, and a different kind of leadership.

Enter the C)AICSO™

The Certified AI Cybersecurity Officer (C)AICSO™) by Mile2 is the first professional certification designed specifically for this role.

It’s not a developer course. It doesn’t require you to write a single line of code.

It’s a 20-module strategic leadership program for the professionals who need to govern, defend, and audit AI systems at an organizational level — CISOs, Risk Managers, Auditors, Security Architects, and the growing wave of AI Governance Officers being appointed across industries.

Here’s what makes it different from every other AI security course out there:

It treats GenAI as a potential insider threat vector. Most courses talk about AI as a tool to defend against external attackers. C)AICSO flips the frame: the AI system itself — its inputs, outputs, integrations, and supply chain — is part of your attack surface.

It uses Mile2’s Progressive AI Risk Management Framework. This isn’t a static checklist. It’s a living methodology for identifying, evaluating, and mitigating AI risks as the technology evolves — which it does, fast.

It maps directly to the frameworks regulators care about. NIST AI RMF. ISO/IEC 42001. EU AI Act. OWASP LLM Top 10. MITRE ATLAS. The course connects theory to the compliance landscape you’ll actually be navigating.

It includes Red Teaming exercises designed for managers. Simulation labs, attack scenarios, and governance playbooks — all structured for strategic decision-makers, not penetration testers.

What You’ll Be Able to Do

By the end of the program, certified professionals will be equipped to:

• Build a comprehensive framework for assessing and mitigating AI security risks

• Red team and develop incident response plans for LLM and GenAI systems

• Apply NIST and ISO frameworks to real AI workflows in the enterprise

• Securely integrate GenAI tools without creating shadow AI exposure

• Design governance blueprints for multi-stakeholder coordination and board-level oversight

That last one matters more than people realize. The question of who owns AI risk — the CISO, the CIO, the CTO, a new Chief AI Officer — is one of the defining organizational design questions of the next five years. The C)AICSO prepares you to be the person who answers it.

The Bottom Line

AI is not a future problem. It’s a present one.

The organizations that will navigate this transition well are not the ones with the most advanced AI — they’re the ones with the clearest ownership, the strongest governance, and professionals who understand the full threat landscape.

The C)AICSO™ is how you build that capacity. Not just for yourself, but for your entire security program.

The C)AICSO™ Ultimate Combo — including course access, exam voucher, and one free retake — is available at academy.avsecadvisory.eu.

There’s a conversation I keep having with CISOs and IT leaders across Southern Europe. It goes something like this:

“We know NIS2 is coming. We know we need to upskill our teams. But where do we even start?”

The honest answer, until recently, was: fly to London, Amsterdam, or Washington D.C. Pay thousands. Hope the training sticks.

That never sat right with me.

The certification landscape is broken — especially for mid-career professionals

Let’s be direct. The cybersecurity certification market has a structural problem. It’s dominated by two or three household names that have become gatekeepers rather than enablers. Multi-thousand-euro exam fees. Rigid experience requirements that punish career changers. Renewal cycles designed to extract revenue, not validate competence.

Meanwhile, the actual threat landscape doesn’t care about your acronyms. Ransomware groups aren’t checking whether your SOC analyst holds a particular certificate before they hit your infrastructure.

What matters is whether your people genuinely understand information security management, risk assessment, governance frameworks, and incident response — and whether they can prove it through a credible, internationally accredited credential.

Why I partnered with Mile2

When I evaluated training providers for AVSecAdvisory, I had three non-negotiable criteria:

Accreditation that holds up to scrutiny. Mile2 certifications are accredited under ISO/IEC 17024 through ANAB. That’s the same accreditation standard the big players use. When a regulator, auditor, or client asks “is this certification legitimate?”, the answer is unambiguous.

Breadth across the security domain. Not just penetration testing. Not just governance. Mile2 covers the full spectrum — from hands-on security operations to ISMS auditing, from AI security governance to strategic CISO-level leadership. That matters because real security teams need diverse skills, not a monoculture of one certification track.

Accessibility. This is the one that sealed it. Mile2’s model makes professional cybersecurity certification achievable without remortgaging your house. The price point, the flexible delivery, the lack of artificial barriers to entry — it opens doors that the traditional providers keep firmly shut.

What this means in practice

Through AVSecAdvisory Academy, professionals across Greece and Europe now have access to the full Mile2 certification portfolio. That includes credentials in:

∙ Information Security Management Systems — for those implementing or auditing ISO 27001

∙ Cybersecurity Strategy and Management — for security leaders who need to communicate risk to boards

∙ AI Security Governance — increasingly critical as organizations adopt AI under frameworks like ISO 42001

∙ Security Operations and Architecture — for the practitioners defending infrastructure every day

Every certification maps to real-world frameworks: ISO 27001, NIS2, NIST, GDPR. These aren’t theoretical exercises. They’re designed to make professionals more effective at their actual jobs.

The timing isn’t coincidental

Europe is in the middle of the most significant cybersecurity regulatory shift in a decade. NIS2 is transforming how organizations across 18 sectors approach security governance. DORA is reshaping financial services. The AI Act is creating entirely new compliance requirements.

All of these frameworks demand one thing in common: competent people. Not just tools. Not just policies on paper. Trained, certified professionals who can implement, manage, and audit security programs.

The organizations that invest in their people now will be the ones that navigate this transition successfully. The ones that don’t will learn the hard way that compliance isn’t something you can buy off the shelf.

A personal note

I hold five Mile2 certifications myself — C)CSSM, C)ISMS-LA/LI, C)AICSO, C)CSSA, and C)ISSO-A. I didn’t pursue them for the letters after my name. I pursued them because the curriculum genuinely made me better at my work as a CISO and as a consultant advising organizations on security governance.

That’s the standard I want to bring to every professional who trains through AVSecAdvisory Academy. Not certification for certification’s sake, but structured learning that translates into measurable capability.

If you’re a security professional looking to level up, or an organization trying to build a credible security function in the NIS2 and AI era, this is worth exploring.

AVSecAdvisory Academy: academy.avsecadvisory.eu

#Cybersecurity #NIS2 #Certifications #InfoSec #Europe #Mile2 #CISO #CyberTraining #ISO27001 #GRC​​​​​​​​​​​​​​​​

There is a quiet governance crisis unfolding in enterprise environments, and most boards have not been briefed on it. It does not involve a new threat actor or a zero-day exploit. It involves a category of identity that your organisation is almost certainly creating faster than it can govern — and which your existing Identity and Access Management programme was never designed to handle.

That category is Non-Human Identities. API keys, service accounts, OAuth tokens, certificates, and — increasingly — the credentials used by AI agents operating autonomously across your infrastructure. They do not log in from recognisable locations. They do not follow normal working hours. They do not respond to behavioural anomaly detection tuned for human patterns. And they outnumber your human users by ratios that, until recently, would have seemed implausible.

As of 2025, NHIs outnumber human identities in enterprise environments at a ratio of 144 to 1 — a 44% increase from the year prior.^[1] That ratio is accelerating as organisations deploy AI agents at scale. The governance infrastructure being applied to manage them has not kept pace. The result is a structural exposure that sits squarely within the scope of NIS2 Article 21 and, for many organisations, the EU AI Act — but which most compliance programmes have not yet addressed.

This is the new Shadow AI problem. Only this time, it is not employees quietly using unapproved tools. It is the tools themselves acquiring identities, permissions, and access — at machine speed, outside the visibility of your IAM programme.

The Scale of the Problem

Understanding why NHIs represent a governance failure requires appreciating their operational characteristics. Unlike human identities, NHIs bypass multi-factor authentication by design. They operate continuously — including at 3am, from multiple locations simultaneously, authenticating thousands of times per minute. They persist indefinitely without lifecycle management unless someone explicitly deprovisions them. And they are often granted standing privileges far beyond what any specific task requires.

The data on governance maturity is stark. According to CSA research, fewer than one in four organisations has documented and formally adopted policies for creating or removing AI identities.^[2] Only 12% report high confidence in their ability to prevent attacks via NHIs.^[3] A separate study found that 68% of IT security incidents now involve machine identities, and half of enterprises surveyed have experienced a breach attributable to unmanaged NHIs.^[4]

The attack surface extends beyond the agents themselves. Research by Entro Labs found that nearly half of all exposed secrets — the credentials NHIs use to authenticate — were discovered outside code repositories entirely: in CI/CD workflows, collaboration platforms, and, notably, SharePoint, which alone accounted for almost one in five credential exposures.^[5] The implication is that the credential sprawl problem is not contained within your development environment. It is distributed across the same productivity tools your organisation runs on.

Within this population, the privilege concentration is particularly concerning. One in twenty AWS machine identities carries full administrator-level permissions.^[6] These are not edge cases. They are the architecture of the average enterprise cloud environment, accumulated through years of permissive provisioning and insufficient lifecycle governance.

Why Existing IAM Programmes Fail Here

The core problem is architectural. Traditional IAM was designed around a set of assumptions that NHIs violate systematically.

Human IAM assumes predictable behaviour: employees work defined hours, access systems from consistent locations, and interact with technology in recognisable patterns. Anomaly detection, behavioural baselines, and privileged access review cycles are all calibrated to these patterns. NHIs break every one of them — legitimately. A service account that authenticates thousands of times per minute from multiple IP ranges is not compromised; that is its normal operational profile.

Human IAM assumes a defined lifecycle: onboarding creates the identity, role changes update permissions, offboarding removes access. NHIs are provisioned dynamically, often by developers building pipelines or deploying agents, without equivalent offboarding discipline. The result is credential sprawl: active credentials attached to decommissioned services, orphaned API keys retaining production access, and service accounts whose owners have long since left the organisation.

Human IAM assumes visibility: your HR system feeds your identity provider, which feeds your access management tooling. NHIs proliferate across cloud environments, SaaS platforms, and CI/CD pipelines in ways that no single system of record captures. As the Cloud Security Alliance notes, the challenge is not merely governance — it is that most organisations do not have a complete inventory of what NHIs exist in their environment, let alone what they are permitted to do.^[7]

The KuppingerCole Leadership Compass on Non-Human Identity Management puts it plainly: traditional IAM and PAM systems were not designed to handle the dynamic and large-scale nature of these entities. They do not adequately address the security complexities of device and system accounts, and this gap in governance not only poses significant security risks but also hampers operational agility.^[8]

The arrival of agentic AI compounds this in a specific and important way. AI agents are not static service accounts. They are autonomous systems that can spawn sub-agents, mint new credentials, and acquire permissions dynamically as they execute multi-step tasks. They operate at machine speed across APIs, databases, and SaaS integrations — often without a human in the loop. The blast radius of a compromised agent credential is not the agent itself; it is every system the agent has permission to touch, and every downstream agent it can reach.

The Regulatory Exposure

For NIS2-covered entities, NHI governance is not a future compliance consideration. It is a current one.

Article 21(2)(i) of the NIS2 Directive explicitly requires the use of multi-factor authentication or continuous authentication solutions, and policies and procedures regarding cryptography and encryption.^[9] By design, NHIs cannot satisfy MFA requirements — they are non-human, and authentication mechanisms for machine identities operate differently. The compliance question is whether your organisation has equivalent controls in place for NHIs: short-lived credentials, certificate-based authentication, zero standing privilege architectures, and automated rotation policies. Most organisations do not.

Article 21(2)(d) requires access control and asset management. Applied to NHIs, this means maintaining an inventory of machine identities, assigning accountable human owners to each credential, and enforcing least-privilege access. The 78% of organisations that lack formal NHI provisioning and deprovisioning policies are, in operational terms, running an access control gap of significant regulatory consequence.^[10]

The AI Act introduces a parallel and reinforcing obligation. From 2 August 2026, full compliance requirements apply to Annex III high-risk AI systems — which include AI used in critical infrastructure, essential services, and employment decisions.^[11] Article 9 of the AI Act mandates a continuous, documented risk management process throughout the AI system lifecycle. For organisations deploying agentic AI in NIS2-covered sectors, the intersection of these two frameworks creates a dual governance obligation: NIS2 governs the security of the network and information systems the agents operate across; the AI Act governs the agents themselves. Neither framework currently exempts the other’s obligations.

The governance gap is therefore not merely a security programme problem. It is a compliance programme problem with two distinct regulatory clocks running simultaneously.

What Boards Are Not Being Told

The board-level conversation about AI has, for most organisations, focused on productivity, risk appetite, and governance frameworks for AI adoption. It has not yet adequately addressed the identity implications of the AI systems already deployed.

Boards understand — at least in principle — that employees using unauthorised AI tools creates Shadow AI risk. What they are rarely told is that the AI tools they have authorised are generating their own credentials, acquiring their own permissions, and operating in ways that existing security controls cannot see or constrain.

The IANS Research report on identity security heading into 2026 ranked ‘Identity Assurance for an AI World’ as the second-highest CISO priority, scoring 4.46 out of 5.^[12] Yet the same research found a significant gap between recognition of the problem and organisational capacity to address it — with IAM investment as a proportion of security budget varying from 6% at smaller organisations to 12% at large enterprises, and manual processes still dominant across the market.

The strategic board argument is this: the organisation is creating a new class of digital actor — AI agents — that inherits enterprise access, operates at machine speed, and sits outside the governance model that applies to human access. Each agent represents a credential that, if compromised, provides an attacker with persistent access equivalent to the agent’s permissions, without triggering human-centric security controls. The attack is not sophisticated. The access it provides is.

As BeyondTrust’s analysis frames it, the mandate for the security function is to shift the question from ‘Who has access?’ to ‘What has access to what?’^[13] Boards should be asking the same question.

What CISOs Should Do Now

The NHI governance problem does not require a new technology investment as the first step. It requires a governance posture shift, followed by targeted tooling to operationalise it.

• Inventory before you govern. You cannot apply policy to identities you cannot see. The starting point is a comprehensive discovery exercise across cloud environments, SaaS platforms, CI/CD pipelines, and collaboration tools. This is not a one-time exercise — NHI creation is continuous, and discovery must be too.

• Assign human ownership to every NHI. Every machine credential should have a named human accountable for its existence, its permissions, and its deprovisioning. Orphaned credentials — those whose owners have left or whose originating service has been decommissioned — are the most common source of standing privilege that attackers exploit.

• Apply least privilege architecture to machine identities. The one-in-twenty AWS machine identities carrying full administrator access is not an outlier — it is the result of permissive defaults and insufficient review cycles. NHI privilege should be scoped to specific tasks, time-limited where possible, and reviewed on the same cadence as privileged human access.

• Design for zero standing privilege for AI agents. AI agents should receive elevated permissions only for the duration of the specific task that requires them, with automatic revocation on completion. This is not a theoretical architecture — it is the practical application of least privilege to autonomous systems operating at machine speed.

• Brief the board on the regulatory intersection. NIS2 Article 21 access control obligations and the AI Act’s Article 9 risk management requirements together create a documented governance obligation for NHI security. The board should understand that the AI it has authorised sits within a regulatory perimeter that includes identity governance — and that the compliance gap, if not addressed, carries both supervisory and personal liability risk under NIS2 Article 20.

• Treat NHI governance as the next phase of your Shadow AI programme. Shadow AI was about employees creating ungoverned AI usage. NHI proliferation is about authorised AI systems creating ungoverned identity sprawl. The governance logic is the same; the technical response needs to evolve to match.

The Governance Moment

Every major shift in enterprise IT architecture has eventually created an identity crisis — not in the existential sense, but in the governance sense. Cloud migration multiplied machine identities beyond what on-premise IAM could track. SaaS adoption distributed credentials across platforms that no single identity provider controlled. Each time, the security function ran behind the architecture, governing the previous model while the new one accumulated ungoverned exposure.

Agentic AI is the next instance of this pattern. The difference is that AI agents do not merely hold credentials passively — they use them autonomously, at speed, across systems, making decisions with real operational and regulatory consequences. The blast radius of a governance failure is no longer measured in data records exposed; it is measured in automated actions taken.

The organisations that will navigate this well are not those with the most sophisticated AI adoption. They are those that treated identity governance as a foundational control rather than a supporting function — and that extended that governance to non-human actors before the incidents made the case for them.

Your IAM programme was built for humans. The question is whether you will extend it to agents before an attacker does it for you.

References

[1] Entro Labs — NHI & Secrets Risk Report H1 2025

[2] CSA — State of Non-Human Identity and AI Security Survey Report

[3] CSA — State of Non-Human Identity and AI Security Survey Report

[4] Obsidian Security — What Are Non-Human Identities: NHI Security Guide

[5] Entro Labs — NHI & Secrets Risk Report H1 2025

[6] Entro Labs — NHI & Secrets Risk Report H1 2025

[7] CSA — Securing the Agentic Control Plane, March 2026

[8] KuppingerCole — Leadership Compass: Non-Human Identity Management

[9] Directive (EU) 2022/2555 — NIS2 Directive, Article 21(2)(i)

[10] MSSP Alert — Security Teams Will Wrestle with Agentic AI, Non-Human Identities in 2026

[11] EU AI Act — Regulation (EU) 2024/1689, Article 9 and Annex III

[12] IANS Research — AI Agents Are Creating an Identity Security Crisis in 2026

[13] BeyondTrust — Agentic AI Security: Securing Shadow AI & Non-Human Identities

Every enterprise wants to say it governs AI responsibly. Most of them are performing the appearance of governance while structurally excluding the one function equipped to operationalise it.

Across industries, organisations are standing up AI governance committees, drafting usage policies, and appointing oversight leads. The energy is real. The problem is who’s at the table — and who isn’t. In too many cases, AI governance is being led by Chief Data Officers, Chief Technology Officers, or innovation teams. Security leadership, when included at all, is added as an afterthought: a reviewer, not an architect.

The result is governance frameworks that look compelling on slides but have no operational teeth. They address ethics, bias, and transparency — all important — but skip the controls that determine whether an AI system is actually safe to run in production: identity management, data classification, access governance, incident response, and regulatory exposure mapping. These are not theoretical concerns. They are the CISO’s daily operating reality.

This matters now more than ever. The EU AI Act’s high-risk obligations become enforceable in August 2026, requiring risk management systems, technical documentation, human oversight, and cybersecurity controls for AI systems operating in sensitive domains.^[1]

NIS2’s management accountability provisions are already active across transposed jurisdictions. And the threat landscape is moving faster than any governance committee’s quarterly meeting cadence.

The Structural Exclusion Problem

Half of organisations have now established dedicated AI governance committees.^[2]

That sounds like progress — until you examine who sits on them. The typical composition includes legal, compliance, data, engineering, and business leadership. Security is frequently listed as a “stakeholder” rather than a co-owner. This mirrors a pattern familiar from cloud adoption a decade ago: business units moved to the cloud, IT enabled it, and security was invited to review the architecture after procurement was complete.

The consequences were predictable then, and they are predictable now. When AI governance is structured without security co-ownership, you get usage policies without enforcement mechanisms, data processing agreements without classification controls, risk assessments that consider reputational and ethical risk but not operational or cyber risk, and vendor evaluations that assess capability but not the security posture of the AI supply chain.

The governance ownership question remains unresolved for many organisations. As one analysis put it, accountability is fragmented across the CTO, CDO, CRO, and CISO — and when everyone assumes someone else is responsible, no one actually governs.^[3]

Shadow AI: The Governance Gap Made Visible

If there is a single metric that exposes the gap between governance theatre and operational governance, it is the scale of Shadow AI.

Ninety-eight percent of organisations report employees using unsanctioned AI applications.^[4]

Three out of four CISOs have discovered unapproved GenAI tools already running in their environments, often with embedded credentials, API integrations, or OAuth tokens that connect directly into enterprise systems.^[5]

Nearly half of employees admit to adopting AI tools without employer approval, with a significant proportion sharing sensitive enterprise data including research datasets, employee records, and financial information with consumer-grade tools.^[6]

This is not an awareness problem. It is a structural one. Employees use unsanctioned AI tools because the organisation has not provided governed alternatives fast enough. When approved tools are made available with appropriate guardrails, unauthorised usage drops dramatically — one healthcare system reported an 89% reduction after deploying sanctioned alternatives.^[7]

Shadow AI is not evidence of rogue employees. It is evidence of a governance model that excluded the function responsible for managing exactly this kind of risk: the CISO.

The AI Identity Crisis Security Leaders Are Already Managing

Beyond Shadow AI, there is a deeper operational challenge that AI governance committees without security representation are not equipped to address: AI systems now function as identities within enterprise environments.

Seventy-one percent of organisations report that AI tools have access to core business systems such as CRM platforms and ERP systems. But only 16% say that access is governed effectively.^[8]

Nearly half of security leaders have already observed AI agents exhibiting unintended or unauthorised behaviour, and a third have dealt with an actual security incident or near-miss in the past year tied to AI systems.^[9]

These AI identities operate at machine speed, with privilege levels that in many cases no one explicitly granted. They don’t follow human access patterns. They don’t leave conventional audit trails. And they create a class of insider risk that traditional governance frameworks were never designed to handle.

This is the CISO’s domain. Identity governance, privilege management, access control, and insider threat detection are core security competencies. An AI governance committee that does not include the CISO is, by definition, ungoverned on the dimension that determines whether AI systems are operationally safe.

The Regulatory Convergence the C-Suite Hasn’t Mapped

The EU AI Act, NIS2, and GDPR are converging on a single operational reality: organisations deploying AI systems in Europe face overlapping governance obligations that no single function can manage alone.

The EU AI Act’s high-risk obligations, enforceable from August 2026, require risk management systems, data governance, technical documentation, human oversight, and — critically — cybersecurity and robustness requirements for AI systems operating in sensitive domains.^[10]

NIS2 already requires management bodies to approve and oversee cybersecurity risk management measures, with provisions for personal liability in cases of serious negligence. When the AI systems an organisation deploys become vectors for cyber risk — through data exposure, privilege escalation, or supply chain compromise — the question of who approved and oversaw their deployment becomes a board-level liability question.

GDPR’s requirements around automated decision-making, data protection impact assessments, and lawful basis for processing all intersect with AI deployment. The CISO is typically the function that operationalises data protection controls and coordinates with the DPO.

No CDO or CTO, however capable, can single-handedly navigate this convergence. It requires the security leader who understands how controls are implemented, how incidents are detected and reported, and how regulatory exposure translates into operational risk.

What Governance Without the CISO Actually Looks Like

The pattern is consistent. Organisations that exclude the CISO from AI governance produce frameworks that are structurally incomplete:

They draft AI usage policies that define acceptable use but lack monitoring or enforcement capabilities. They conduct vendor risk assessments for AI tools that evaluate functionality and data processing agreements but not the security architecture of the model’s supply chain. They build AI risk registers that capture ethical and reputational risk but not cyber risk scenarios: prompt injection, data poisoning, model exfiltration, or credential compromise via AI integrations. They approve AI deployments without identity governance, access controls, or incident response playbooks specific to AI-related incidents.

The board receives a governance dashboard that shows committee activity, policy coverage, and adoption metrics. What it does not show is whether the AI systems running in the enterprise are secure, whether their access is governed, or whether the organisation could detect and respond to an AI-related breach within its regulatory reporting timelines.

That gap is not a CISO problem. It is a board-level risk that the CISO has been structurally prevented from addressing.

The Boardroom Alignment Problem

There is a growing disconnection between how boards perceive AI governance maturity and the reality on the ground.

A survey of Fortune 500 executives found that 70% of organisations now have AI risk committees and 41% have dedicated AI governance teams — yet only 14% report being fully ready for AI deployment.^[11]

Proofpoint’s 2025 Voice of the CISO report showed that boardroom alignment with CISOs declined from 84% in 2024 to 64%, even as boards elevated business valuation as their top concern following a cyberattack.^[12]

The WEF Global Cybersecurity Outlook 2026 identified a telling perception gap: CEOs now rank AI vulnerabilities as their second-highest cyber risk, while CISOs do not even list it in their top three.^[13]

This is not a contradiction. It reflects the fact that CISOs are managing AI risk operationally — through identity controls, access governance, and incident response — while boards are experiencing it as a strategic abstraction. When CISOs are excluded from the governance structure that frames AI risk for the board, both sides lose: the board gets an incomplete picture, and the CISO loses the mandate to act.

What Operational AI Governance Actually Requires

Effective AI governance is not a committee. It is an operational capability that must be embedded across the enterprise. And it requires the CISO as a co-architect, not a reviewer.

AI identity governance should treat AI agents, copilots, and automated systems as non-human identities subject to the same lifecycle controls as human users: provisioning, least-privilege enforcement, access certification, and deprovisioning. This is identity and access management. It belongs to the CISO.

AI-specific incident response requires playbooks that address prompt injection, data exfiltration via AI tools, model manipulation, and the disclosure obligations that arise when AI systems process personal data or operate in NIS2-regulated environments. This is incident response. It belongs to the CISO.

AI supply chain security means evaluating not just the vendor’s data processing agreements but their model provenance, training data practices, API security, and the third-party components embedded in their AI stack. This is supply chain risk management. It belongs to the CISO.

AI risk quantification requires translating AI-specific threats into the same risk language the board uses for every other enterprise risk: financial exposure, regulatory penalty, operational disruption, and reputational impact. This is cyber risk communication. It belongs to the CISO.

None of this can happen from outside the governance structure.

What CISOs Should Do Now

The challenge for CISOs is not to wait for an invitation. It is to demonstrate that AI governance without security co-ownership is incomplete by design — and to present the board with a clear, risk-based argument for inclusion.

Claim the AI identity governance mandate. If AI systems are accessing enterprise data and business-critical applications, they fall within the CISO’s existing scope. Document the AI identities operating in your environment, their access levels, and the gaps in their governance. Present this to the board as an operational risk, not a technology update.

Map the regulatory convergence. Show the board where the EU AI Act, NIS2, and GDPR obligations overlap on AI governance and where the current governance structure has no owner for those intersections. Make the accountability gap visible.

Build AI-specific incident response capability now. Do not wait for a governance committee to authorise it. Develop playbooks for AI-related incidents, run tabletop exercises, and ensure your team can detect and respond to AI-specific threats within your existing regulatory reporting timelines.

Reframe the conversation. The CISO’s role in AI governance is not to slow down innovation. It is to ensure that AI deployments are operationally safe, legally defensible, and resilient. The argument is not “you need security approval” — it is “you need someone who can tell the board whether these systems are actually governed.”

The Real Test

The organisations that will navigate the AI governance challenge successfully are not those with the most impressive committee structures or the most comprehensive policy documents. They are the ones that have embedded security leadership into AI governance from the beginning — not as a checkbox, but as an operational co-owner.

AI governance without the CISO is not governance. It is innovation theatre: a performance of oversight that leaves the organisation structurally exposed to the risks that governance was supposed to manage.

The stage is set. The question is whether CISOs will be in the room where the decisions are made — or left to manage the consequences of decisions made without them.

References

[1] European Commission — AI Act Implementation Timeline

[2] IANS Research — The CISO’s Expanding AI Mandate: Leading Governance in 2026

[3] Santanu Sengupta — AI Governance in 2026: Why Structure Doesn’t Equal Capability (Medium, January 2026)

[4] Vectra AI — Shadow AI: Risks, Costs, and Enterprise Governance (2026)

[5] Saviynt / Cybersecurity Insiders — 2026 CISO AI Risk Report

[6] CIO.com — Roughly Half of Employees Are Using Unsanctioned AI Tools (BlackFog Survey, January 2026)

[7] Vectra AI — Shadow AI: Risks, Costs, and Enterprise Governance (Healthcare Brew / 2026 data)

[8] Saviynt / Cybersecurity Insiders — 2026 CISO AI Risk Report

[9] Saviynt / Cybersecurity Insiders — 2026 CISO AI Risk Report

[10] Securiti — EU AI Act: What Changes Now vs What Starts in 2026

[11] Sedgwick 2026 Forecasting Report, cited in Sengupta, AI Governance in 2026 (Medium, January 2026)

[12] Proofpoint — 2025 Voice of the CISO Report

[13] World Economic Forum — Global Cybersecurity Outlook 2026 (via Fortinet CISO Collective)

March 2026 has been a busy month in European cybersecurity. A medical technology giant was hit by a wiper attack that wiped tens of thousands of devices. The EU proposed amendments that could ease the NIS2 compliance burden for small businesses. Germany’s registration deadline is weeks away. And a string of data breaches — including one at the European Commission itself — reminded us that no organisation is immune.

Here is what happened, why it matters, and what you should be doing about it.

1. Stryker: The Attack That Proves Wiper Malware Is Now a Business Risk

On 11 March 2026, Stryker — one of the world’s largest medical technology companies — suffered a devastating cyberattack. Iranian-linked hackers using the group name Handala deployed wiper malware across the company’s global network, permanently erasing data from tens of thousands of devices.

This was not ransomware. The attackers did not want money. They wanted destruction.

The impact at Stryker’s Cork, Ireland headquarters alone was severe: over 5,500 employees were unable to work, with engineering, product design, and manufacturing operations brought to a standstill. Corporate laptops, mobile phones enrolled in Microsoft Intune, and servers running proprietary applications were wiped or rendered inoperable. Login screens were defaced. Remote device management systems were turned against the company they were meant to protect.

For supply chain professionals and risk managers, the Stryker attack carries a critical lesson: the impact of a cyberattack on a large enterprise cascades immediately to its SME suppliers and partners. Companies relying on Stryker for components, instruments, or services faced disruption with no warning and no control.

NIS2 explicitly requires organisations to assess and manage cybersecurity risk across their supply chains. The Stryker incident is a textbook example of why that obligation exists — and what happens when it is not taken seriously across the ecosystem.

→ CyberSecurityNews – Stryker Cyber Attack: Iran-Linked Hackers, Wiper Malware, Cork HQ Impact

→ Data Breaches Digest – Week 11, 2026: Full Incident Roundup

2. The EU Proposes NIS2 Simplification — Including a New SME Category

On 20 January 2026, as part of a broader cybersecurity legislative package, the European Commission proposed targeted amendments to the NIS2 Directive. The goal: reduce compliance complexity, increase legal clarity, and — notably — ease the burden on smaller businesses.

The headline change for SMEs is the proposed introduction of a new ‘small mid-cap’ enterprise category. This would create a more proportionate compliance pathway for companies that currently fall under NIS2 scope but lack the resources of large enterprises. The Commission estimates that the amendments will ease compliance for approximately 28,700 companies, including 6,200 micro and small-sized enterprises.

Other proposed amendments include:

• Streamlined jurisdictional rules for cross-border entities

• Simplified ransomware data collection requirements

• A strengthened coordinating role for ENISA

• Integration with the Digital Omnibus ‘single-entry-point’ for incident reporting

Once adopted, Member States will have one year to transpose the amended provisions. The proposal is now under negotiation, and political agreement is expected later in 2026.

For SMEs already struggling with the complexity of NIS2, these amendments are a signal that the Commission has heard the feedback — even if relief is still months away.

Importantly, the proposed amendments do not pause existing obligations. If your country has already transposed NIS2, the current rules apply now. The simplification measures, when they arrive, will refine — not replace — what is already on the books.

→ European Commission – Proposal for Targeted Amendments to the NIS2 Directive (January 2026)

→ Inside Privacy – What to Watch in 2026: Key EU Privacy & Cybersecurity Developments

3. NIS2 Transposition: Germany’s April Deadline Is Now Weeks Away

Germany completed its NIS2 implementation on 6 December 2025, when the revised BSI Act entered into force — well over a year after the EU’s October 2024 deadline. That delay is now behind us. What matters now is the compliance clock that started ticking the moment the law took effect.

German-registered entities that fall within NIS2 scope must register with the Federal Office for Information Security (BSI) within three months of the Act’s entry into force. That deadline is April 2026 — weeks away. Beyond registration, the revised BSI Act introduces:

• Personal liability for management: Under Section 38 of the BSI Act, members of management bodies are personally accountable for approving and overseeing cybersecurity risk management measures.

• Significant fines: Particularly important entities face fines up to €10 million or 2% of global annual turnover. Important entities face up to €7 million or 1.4% of global turnover.

• Expanded BSI enforcement powers: Including broad inspection rights, binding orders, and detailed documentation requirements.

Germany’s approach is stricter than the baseline NIS2 Directive in several ways — most notably in how it layers new NIS2 obligations on top of the existing KRITIS framework, creating a more granular and demanding scoping model.

Across the EU more broadly, transposition is accelerating. Germany, Portugal, and Austria have all recently adopted national implementing legislation, while Spain, France, and Poland are nearing completion. As of early 2026, the majority of Member States have transposed NIS2 — meaning enforcement activity will follow.

→ Morrison Foerster – Flipping the NIS2 Switch: What Germany’s Implementation Means for 2026 Compliance

→ Bird & Bird – European Cybersecurity Regulatory Update: NIS2 and Beyond

4. Cyber Resilience Act: Six Months to the First Hard Deadline

The Cyber Resilience Act (CRA) entered into force in December 2024, and for most organisations it has felt abstract — something to think about later. That window is closing.

From 11 September 2026, manufacturers of products with digital elements must comply with the CRA’s vulnerability reporting requirements. This is the first hard, enforceable obligation under the Act. It requires manufacturers to actively report exploited vulnerabilities and serious cybersecurity incidents to ENISA and to the relevant national authority — within tight timelines.

The broader compliance picture looks like this:

• 11 September 2026: Vulnerability and incident reporting obligations begin

• 11 December 2027: Full CRA compliance required — security-by-design, conformity assessments, CE marking, and technical documentation

For SMEs that develop or sell software, hardware, or connected products in the EU market, the CRA is not optional. It applies regardless of whether the manufacturer is based inside or outside the EU — what matters is whether the product is placed on the EU market.

Six months is not long when you factor in supply chain audits, secure development process reviews, and the documentation trail regulators will expect to see.

The 10th Cybersecurity Standardization Conference, held in Brussels on 12 March 2026 and co-hosted by CEN, CENELEC, ETSI, and ENISA, dedicated significant discussion to the timeline of CRA standards and how they interact with NIS2, DORA, and eIDAS. The message from regulators and industry was consistent: begin preparing now, because the December 2027 deadline requires foundational work that cannot be done in the final months.

→ CEN-CENELEC – Highlights from the 10th Cybersecurity Standardization Conference, March 2026

→ Open Regulatory Compliance Working Group – The EU Cyber Resilience Act: Deadlines and Requirements

5. When the EU Commission Gets Breached: A Reminder That No One Is Immune

On 6 February 2026, the European Commission disclosed a data breach affecting staff. The incident was detected on 30 January, when its mobile device management infrastructure identified traces of unauthorised access — later linked to active exploitation of a vulnerability in Ivanti Endpoint Manager Mobile.

The same week, rail pass provider Eurail confirmed that customer data — including names, contact details, travel companion information, and passport numbers — had been stolen and offered for sale. Criminals claimed to have taken 1.3 terabytes from cloud storage and support systems, and threatened wider release if no buyer emerged.

Neither the Commission nor Eurail fits the profile of a poorly resourced organisation caught napping. Both have dedicated security functions, established processes, and regulatory obligations. Both were breached anyway.

If the European Commission cannot fully prevent a breach, your business certainly cannot. The goal is resilience, detection, and response — not the illusion of impermeability.

This is the core argument behind NIS2’s incident reporting requirements. The Directive does not assume organisations will never be breached. It assumes they will — and it requires them to have the governance structures, detection capabilities, and reporting processes in place to manage the aftermath effectively.

For SMEs, the lesson is practical: having an incident response plan is not a luxury. It is a baseline obligation under NIS2 for in-scope entities, and a basic act of business survival for everyone else.

→ Bright Defense – List of Recent Data Breaches in 2026 (Eurail, EU Commission, and more)

What Should You Do With All of This?

The five stories above are not isolated incidents. They form a pattern: the threat landscape is intensifying (Stryker, EU Commission, Eurail), regulatory enforcement is materialising (Germany’s April deadline, NIS2 transposition wave), and the legislative framework is evolving to address SME realities (NIS2 amendments, CRA implementation support).

If you run or advise a business in scope of NIS2 — or if you sell products with digital elements in the EU — here is where to focus your attention:

• Check your NIS2 status. With over 20 Member States now having transposed NIS2, the odds are that the rules apply in your country. If you are not sure whether your organisation is in scope, that question needs answering now.

• Register if you are in Germany. The April 2026 BSI registration deadline is imminent. Do not miss it.

• Map your supply chain. The Stryker attack is a case study in how cyber incidents spread through supplier ecosystems. NIS2 requires you to assess third-party risk. Start with your most critical vendors.

• Plan for CRA. If your business develops or sells products with digital elements, the September 2026 vulnerability reporting deadline is your first hard CRA obligation. Begin building your process now.

• Review your incident response plan. The EU Commission got breached via a known vulnerability type. Do you have a documented plan for detecting, containing, and reporting a significant incident?

──

If you want a practical, jargon-free guide to working through all of this — scoping, governance, risk management, supply chain, incident response, and documentation — I wrote NIS2 Practical Compliance for SMEs exactly for this situation: business owners and directors who need to get compliant without a large security team and without a large budget.

📖 Available on Amazon → amazon.com/dp/B0GRQVQG8C

Angelos Varthalitis is a CISO with over 20 years of cybersecurity experience. He runs avsecadvisory and writes at varthalitis.eu. Views are his own.

This article covers five developments that, taken together, tell a coherent story: Europe is raising the bar again, the talent to meet that bar is scarce, and the window for ‘wait and see’ is closing.

1. The EU’s New Cybersecurity Package: A Regulatory Upgrade Nobody Saw Coming

On 20 January 2026, the European Commission proposed a comprehensive new cybersecurity package — a revision of the 2019 Cybersecurity Act, paired with targeted amendments to NIS2 itself. This is not a minor update.

The proposal introduces a horizontal framework for trusted ICT supply chain security — the first of its kind in EU law. It would allow the Commission and Member States to act jointly against ‘non-technical risks’ in ICT supply chains: in plain terms, the ability to restrict suppliers from third countries that pose a strategic cybersecurity threat.

For the first time, the EU is treating supply chain security not just as a technical problem — but as a geopolitical one.

Beyond supply chain, the package significantly expands and simplifies the European Cybersecurity Certification Framework (ECCF). Organisations would be able to use certification to demonstrate compliance and obtain a presumption of conformity with NIS2 — a major simplification for entities already overwhelmed by audit requirements.

ENISA gets a budget increase of more than 75% and takes on new operational roles: managing EU-wide vulnerability databases, issuing early warnings, coordinating cybersecurity exercises, and operating a unified incident notification platform.

The package is now under negotiation, with political agreement expected later in 2026. Any adopted measures would be phased in over several years. But the direction is clear: the EU is building a more centralised, more aggressive cybersecurity architecture.

Source: European Commission – New measures to strengthen cybersecurity resilience and capabilities (January 2026)

Source: Mayer Brown – European Commission Proposes Major Cybersecurity Package (February 2026)

2. ENISA’s NIS Investments 2025: The Talent Crisis Is Now Structural

ENISA’s 6th annual NIS Investments report, published in December 2025, contains data that every CISO, policymaker, and business owner should read carefully. It surveyed 1,080 security professionals across all 27 Member States, and the picture it draws is one of a sector under serious strain.

The headline finding is a pivot from people to technology. Overall cybersecurity budgets have stabilised at around 9% of IT spending — roughly €1.5 million median across surveyed entities. But within those flat budgets, organisations are moving resources away from hiring and towards technology platforms and managed services. The reason is not strategic preference — it is necessity.

The talent gap has become a structural problem. 76% of organisations reported difficulty attracting cybersecurity professionals, and 71% struggle to retain them. Across the EU, the shortage is estimated at nearly 300,000 professionals. For SMEs, the numbers are starker: 59% struggle to fill cybersecurity roles.

The talent shortage is not a pipeline problem anymore. It is a structural constraint that is reshaping how organisations defend themselves — and not always for the better.

Regulatory compliance — primarily NIS2, DORA, and the CRA — is the main investment driver for 70% of organisations. This is generating real operational value: 41% credit compliance-driven investments with improving risk management, 35% with faster incident detection. Policy is working. But implementation is not keeping up.

Half of all organisations cited vulnerability and patch management as their top NIS2 implementation challenge. Nearly one in three had not conducted a cybersecurity assessment in the past 12 months. And 28% take more than three months to patch critical vulnerabilities.

The most concerning forward-looking finding: supply-chain and third-party compromises are the second highest concern for the future (47%), and SMEs — the very organisations most likely to be the entry point — report the lowest confidence in their ability to withstand a cyber incident.

Source: ENISA – NIS Investments 2025 Main Report

Source: ENISA – What’s Driving Cybersecurity Investments and Where Lie the Challenges

3. NIS2 Transposition: 20 Member States Down, the Rest Moving Fast

The original NIS2 transposition deadline was October 2024. Most Member States missed it. Many organisations took this as a signal that enforcement was distant — a reasonable read at the time, but an increasingly dangerous one now.

As of January 2026, over 20 of the 27 EU Member States have formally completed NIS2 transposition into national law. Germany, Portugal, and Austria finalized their legislation in late 2025. Spain, France, and Poland are in the final stages. Ireland remains at an earlier stage, but even there, the legislative process is underway.

The pressure is coming from above. In May 2025, the European Commission issued reasoned opinions — formal legal warnings — to 19 Member States for failing to notify full transposition. The next step would have been referral to the Court of Justice of the EU. The message was received.

One important nuance: national implementations vary. Some countries, including Italy and Slovenia, have extended the list of regulated sectors beyond the EU Directive’s baseline. Belgium has introduced enhanced board-level governance obligations. Others have aligned liability provisions with existing national civil law frameworks. If you operate across multiple EU jurisdictions, you need country-specific analysis — not just the Directive itself.

Enforcement activity is expected to accelerate through 2026 as national supervisory frameworks, registration systems, and entity designations fall into place. There are no major public enforcement actions under NIS2 yet — but that is a function of timing, not intent.

Source: Wavestone – NIS 2 Directive: Transposition Status and What Companies Must Do (January 2026)

Source: Goodwin – Navigating NIS2: What Organisations Need to Know as EU Implementation Unfolds

4. The Cyber Resilience Act: The Clock Is Running

While most attention is focused on NIS2, a second major piece of EU cybersecurity legislation is quietly advancing toward enforcement. The Cyber Resilience Act (CRA) entered into force in December 2024 and begins applying in full from September 2026.

From 11 September 2026, the CRA imposes mandatory reporting requirements for actively exploited vulnerabilities and serious cybersecurity incidents for any product with digital elements placed on the EU market — regardless of where it was designed or manufactured.

Who does this affect? Any organisation that develops or sells software, hardware, or connected products in the EU. This includes manufacturers, ISVs, and device makers across every sector. The CRA is, in scope terms, far broader than NIS2.

The European Commission is currently finalising guidance to help manufacturers and developers meet CRA requirements, with a public consultation on that guidance still ongoing. In parallel, the EU is developing conformity assessment frameworks and certification schemes tied to CRA obligations.

For SMEs that develop or sell digital products, the CRA represents a compliance challenge with a firm deadline. Unlike NIS2 — where timing varied by Member State — the CRA applies at EU level with a single, fixed date.

Source: European Parliament – EU Cybersecurity Act revision (January 2026)

Source: Inside Privacy – What to Watch in 2026: Key EU Privacy & Cybersecurity Developments

5. SMEs: Still the Weakest Link — and Now the Most Targeted

Running through all four of the above stories is a common thread: SMEs are simultaneously the most exposed, the least prepared, and the most consequential element of the EU’s cybersecurity architecture.

The ENISA NIS Investments 2025 data is unambiguous on this point. SMEs consistently report the lowest confidence in their ability to prepare for, withstand, and recover from cyber incidents — across every threat category. They face the same compliance requirements as larger entities, with a fraction of the resources.

The supply chain dynamic makes this urgent. Large enterprises — the ones that are well-resourced and well-audited — increasingly depend on SME suppliers, integrators, and service providers. Attackers know this. Supply-chain and third-party compromises are now the second most feared future threat among EU organisations, at 47%.

The cybersecurity of the EU’s critical sectors is only as strong as the SMEs that sit in their supply chains. And right now, that chain has serious weak links.

The regulatory answer to this problem is clear in intent but imperfect in execution. NIS2 imposes supply chain risk management obligations on essential and important entities — meaning those larger organisations are now required to assess the security posture of their suppliers. This creates both pressure and opportunity for SMEs: pressure to demonstrate compliance, and opportunity to differentiate on security credentials.

What SMEs need most, according to the ENISA data, is accessible guidance, affordable tooling (including managed and cloud services), and practical skills development. The framework exists. The implementation support remains uneven.

Source: ENISA – NIS Investments 2025

What This Means in Practice

These five developments are not isolated news items. They form a coherent regulatory and operational picture:

1. The EU is building a more centralised, more prescriptive cybersecurity framework — and it is moving faster than most organisations realise.

2. The talent and resource constraints are real, structural, and not going away — which makes the quality of your process and documentation more important, not less.

3. Enforcement is arriving market by market, with national supervisory authorities now actively building their frameworks.

4. If you are an SME — whether in scope directly or as part of a supply chain — the time to prepare is before your national authority comes looking, not after.

If you want to understand what compliance actually looks like for a small or medium-sized business — without the jargon and without assuming you have a security team — that is exactly what I wrote NIS2 Practical Compliance for SMEs to address.

Available on Amazon: amazon.com/dp/B0GRQVQG8C

About the Author

Angelos Varthalitis is a CISO with over 20 years of cybersecurity experience, running avsecadvisory and writing at varthalitis.eu. His work focuses on EU regulatory compliance for SMEs and non-technical decision-makers.

Every CISO who has spent the past eighteen months building a NIS2 supply chain programme has been working from the same mental model: assess vendors, contractualise obligations, monitor continuously. It is the right model. As NIS2 transposition laws take effect across Member States and supervisory enforcement accelerates through 2026, that model is being tested in practice.

But the mental model has a blind spot. It frames vendor risk as a question about how suppliers operate. It does not ask whether the products those suppliers provide are inherently secure — and that question now has a regulator attached to it.

The Cyber Resilience Act (CRA) is a product security regulation, not an organisational one. Its obligations fall on manufacturers, importers, and distributors of products with digital elements — a category defined broadly to cover hardware and software that includes software components or network connectivity, encompassing enterprise software, connected devices, embedded systems, OT equipment, and consumer IoT. It is not a directive requiring national transposition; it is a directly applicable regulation. And its first enforcement deadline arrives on 11 September 2026, six months from now.

For CISOs managing NIS2 supply chain programmes, this matters in a specific and underappreciated way: your NIS2 vendor assurance work and your vendors' CRA obligations are part of the same risk problem. They just have different regulators.

The Architecture of Two Frameworks

NIS2 and the CRA were designed as complementary instruments, not competing ones. The European Commission's explicit framing is that NIS2 builds operational resilience for the organisations deploying technology, while the CRA builds product resilience for the technology itself. In practice, as one technical analysis puts it, NIS2 ensures secure operations while CRA ensures secure products — together, they close the loop between governance and engineering.[1]

That complementarity creates a structural dependency that most CISOs have not fully mapped. Consider the logic:

Under Article 21(2)(d) of NIS2, essential and important entities must implement supply chain security measures covering their relationships with direct suppliers and service providers. This includes assessing supplier cybersecurity posture and, under some national implementations such as Poland's KSC amendment, formally excluding vendors that represent unacceptable risk.[2]

Under the CRA, the suppliers those entities are assessing now face their own mandatory obligations: to design products securely, manage vulnerabilities across the product lifecycle, provide security updates, and — from September 2026 — to report actively exploited vulnerabilities to ENISA and national CSIRTs within 24 hours.[3]

The dependency becomes a governance gap when the two frameworks are managed separately. An NIS2 supply chain programme that evaluates operational security practices but does not assess CRA readiness is evaluating half the picture. A vendor can have strong SOC processes and weak product security. Under the converging regulatory architecture, both matter.

The CRA Timeline in Practice

December 2024 — CRA enters into force

11 June 2026 — Conformity assessment body framework operational; notified bodies available for product assessments

11 September 2026 — Vulnerability and incident reporting obligations apply to all in-scope manufacturers

11 December 2027 — Full product conformity requirements enforceable; SBOM obligation formally applies

The September 2026 deadline is the immediate operational pressure point. It is six months away.

What the CRA Reporting Deadline Actually Means

The September 2026 deadline is frequently described as the CRA's "early" reporting obligation, as distinct from the full compliance requirements taking effect in December 2027. That framing, while technically accurate, understates the operational readiness it demands.

From 11 September 2026, manufacturers of products with digital elements must notify via the ENISA-managed single reporting platform, which distributes information to the relevant national CSIRTs, of actively exploited vulnerabilities and severe security incidents within 24 hours of becoming aware. A 72-hour detailed follow-up is required, and a final report within 14 days (for exploited vulnerabilities) or one month (for severe incidents).[4]

Critically, this reporting obligation applies to all products currently on the EU market — including those placed there before December 2027. Legacy products are not exempt from the reporting requirements even though they are exempt from the full conformity obligations.[5]

The operational implication of this is frequently missed: to report an actively exploited vulnerability within 24 hours, a manufacturer must already know what components are in the product. That knowledge requires a Software Bill of Materials (SBOM) and automated vulnerability monitoring. As one analysis summarises the hidden dependency: if you do not have a complete SBOM and real-time vulnerability monitoring, you will not even know whether your product is affected before the 24-hour clock expires.[6]

For CISOs, this has a direct supply chain governance implication. The NIS2 question "does this vendor have good security practices?" needs to be supplemented by a CRA-adjacent question: "does this vendor have the product transparency infrastructure to know when their products are compromised and report it within 24 hours?" Those are different questions with different answers.

The Supply Chain Accountability Chain

The CRA does not restrict accountability to the original manufacturer. It establishes what one legal analysis describes as a cascading chain of responsibility throughout the product lifecycle: manufacturers bear primary obligations, while importers and distributors assume secondary duties including verification of compliance and reporting of non-conformities to competent authorities.[7]

This matters for essential entities in a way that is not obvious from the NIS2 framework alone. Under the CRA:

Importers must verify that manufacturers have met CRA obligations before placing products on the EU market. Distributors must verify that the product bears CE marking and that required conformity documentation is present. Any entity in the supply chain that modifies a product in a way that affects its security characteristics takes on manufacturer obligations for the modified product.

The governance implication: an essential entity that procures digital products — servers, endpoint software, network equipment, IoT devices, industrial control systems — is operating in a supply chain that now has legally enforceable product-security accountability at multiple levels. When something goes wrong with a product that has been placed on the EU market without CRA conformity, the question of who failed their obligations runs from the original developer through importers and distributors to the end customer.

One analysis of the converging frameworks captures this clearly: a product that fails CRA requirements can create downstream compliance risk for customers subject to NIS2 or DORA.[8] The supply chain is not just a source of operational risk — it is a source of regulatory exposure.

The SBOM as a Shared Governance Instrument

The Software Bill of Materials has been discussed in cybersecurity governance circles for several years as a supply chain transparency tool. The CRA makes it something more specific: a product conformity instrument with regulatory teeth.

Under Annex I of the CRA, manufacturers are explicitly required to identify and document vulnerabilities and components contained in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies. That obligation becomes fully enforceable from December 2027. However, it is a practical prerequisite for the September 2026 reporting deadline: to report an actively exploited vulnerability within 24 hours, a manufacturer must already know what components are in the product. Market surveillance authorities may request the SBOM on a reasoned basis once the full framework applies.[9]

The NIS2 Directive does not explicitly require SBOMs from entities or their suppliers. But the ENISA guidance on NIS2 supply chain security — which functions as an interpretive guide for supervisory authorities during inspections — reinforces the expectation that essential entities can demonstrate software component transparency across their vendor relationships.[10]

In practice, the SBOM is becoming the point where CRA product obligations and NIS2 supply chain assurance converge. A vendor that can produce a current, machine-readable SBOM on request is demonstrating both CRA readiness and the kind of software transparency that NIS2 supply chain governance programmes should be requiring. A vendor that cannot is signalling both a CRA compliance risk and a NIS2 assurance gap.

CISOs designing or upgrading vendor risk programmes should treat SBOM availability as a tier-one assessment criterion for technology suppliers, not a future aspiration.

What Has Not Changed — And What This Means

It is worth being precise about scope. The CRA applies to manufacturers, importers, and distributors of products with digital elements. It does not directly impose obligations on essential entities as operators of those products — at least not under CRA's own provisions. The product-security obligations in September 2026 fall on the vendors, not the buyers.

This can create a false sense of separation. The argument runs: "CRA is a vendor problem; we just need to buy from compliant vendors." That argument has three weaknesses.

First, the September 2026 reporting deadline is live in six months. The SBOM and vulnerability management infrastructure required to meet a 24-hour reporting obligation is not trivial to build. Multiple industry analyses published in 2025 and early 2026 note that many manufacturers are still treating CRA as a 2027 problem — systematically underestimating that the September reporting obligation requires operational readiness now.[6]

Second, NIS2 supply chain obligations require essential entities to assess and manage the cybersecurity posture of their suppliers. CRA non-compliance is a material factor in that assessment. The inability to report an exploited vulnerability within 24 hours is not a hypothetical risk — it is an information asymmetry that leaves the downstream customer operating on outdated incident intelligence.

Third, the January 2026 NIS2 amendments explicitly acknowledged that supply chain questionnaire approaches are inadequate and signalled a shift toward certification-based supply chain assurance. The CRA's CE marking and conformity assessment framework is designed to operate at the product level — and the logical direction of the Commission's regulatory architecture is that these two certification layers will eventually reinforce each other. CISOs who design their vendor risk programmes around CRA readiness now are building toward a more coherent compliance model, not running ahead of it.

What CISOs Should Do Now

The governance response to converging NIS2 and CRA obligations is not complex, but it requires deliberate action rather than deferred attention.

Map the product exposure in your vendor base

Identify which of your critical vendors are manufacturers, importers, or distributors of products with digital elements and therefore subject to CRA obligations. This is not all vendors — it is specifically those whose products involve software, firmware, or network connectivity placed on the EU market. Prioritise vendors of OT systems, endpoint software, network infrastructure, and IoT equipment.

Add CRA readiness to vendor risk assessments

For technology product vendors, current NIS2 supply chain questionnaires assess operational security practices. Add a CRA readiness dimension: does this vendor have SBOM capability? Do they have a coordinated vulnerability disclosure process? Are they prepared to notify ENISA within 24 hours of an actively exploited vulnerability in their products? These are answerable questions — and the answers differentiate mature vendors from those that will struggle in September.

Treat SBOM availability as a procurement criterion

For new technology procurements, require that vendors can produce a machine-readable SBOM for relevant products on request. This is not yet a universal market expectation, but it is the direction of regulatory travel and should be embedded in procurement criteria and contractual terms now rather than retrofitted later.

Brief the board on converging regulatory exposure

NIS2 management accountability provisions mean that supply chain governance failures carry personal liability. The CRA adds a product-security dimension to that liability landscape. Boards that understand only the NIS2 operational compliance obligations are missing part of the risk picture. The message to deliver: your supply chain is now subject to two overlapping regulatory frameworks, with different deadlines and different accountability chains — and managing the intersection is a board-level governance question.

Engage vendors proactively on the September deadline

Essential entities have market influence with their technology suppliers. Using that influence proactively — asking vendors about their CRA readiness before the September deadline, rather than discovering non-compliance after an incident — is both a risk management and a vendor relationship action. Vendors that know their customers are tracking CRA readiness have an additional incentive to prepare.

The Governance Question the Frameworks Are Asking

The emerging European cybersecurity framework is no longer separating operational security from product security. NIS2 governs how organisations operate. The CRA governs the security properties of the technology they depend on.

For CISOs, the practical consequence is direct: vendor risk management can no longer stop at organisational controls. It must extend into product transparency, component visibility, and lifecycle security commitments.

Two regulators, one supply chain, and increasingly one governance problem. The organisations that manage them as a unified challenge will be better positioned for the enforcement environment ahead. The organisations that manage them as parallel compliance projects will discover the intersection the hard way.

References

[1] Avatao — CRA vs NIS2: What's the Difference and Why Both Matter (2025)

[2] nflo.tech — ICT Supply Chain Security: Vendor Audit and NIS2 Compliance (January 2026)

[3] European Commission — CRA Reporting Obligations (accessed March 2026)

[4] Bryan Cave Leighton Paisner — The Cyber Resilience Act Is Rewriting the Rules of Digital Products Safety

[5] European Commission — The Cyber Resilience Act: Summary of the Legislative Text (accessed March 2026)

[6] Keysight — One Year Countdown to EU CRA Compliance: September 11, 2026 Changes Everything (September 2025)

[7] Bryan Cave Leighton Paisner — The Cyber Resilience Act Is Rewriting the Rules of Digital Products Safety (November 2025)

[8] SCANOSS — Cyber Resilience Act (CRA) Requirements Explained (March 2026)

[9] TXOne Networks — The Cyber Resilience Act: A Guide for Manufacturers (April 2025)

[10] nflo.tech — ICT Supply Chain Security: Vendor Audit and NIS2 Compliance (January 2026)

[11] Hogan Lovells — EU Cyber Resilience Act: Key 2026 Milestones Toward CRA Compliance

The European Commission’s January 2026 cybersecurity package came with a reassuring headline: simplification. Clearer scope. Reduced compliance costs. Harmonised controls. For organisations still mid-implementation on NIS2 — and for boards who only recently acknowledged that cybersecurity is their problem — that framing is dangerously comfortable.

The reality is more operationally complex. The Commission has proposed substantive changes to a directive that many Member States only recently transposed, and which some are still in the process of implementing. For CISOs, the question is not whether the amendments are welcome — many of them are — but what to do when the rules shift before the ink on your current compliance programme has dried.

This article unpacks what actually changed, what the governance implications are, and what CISOs should do right now.

What the Commission Actually Proposed

On 20 January 2026, the European Commission published a targeted proposal to amend the NIS2 Directive (Directive (EU) 2022/2555), as part of a broader package that also introduced a revised Cybersecurity Act (CSA2). The amendments build on the earlier Digital Omnibus Package from November 2025, which introduced the first wave of streamlining measures — including a single incident reporting entry point covering NIS2, GDPR, DORA, eIDAS, and the CER Directive.^[1]

The January 2026 proposal goes further. Its stated goals: clarify scope, harmonise technical measures, introduce certification-based compliance pathways, and strengthen cross-border supervision through an expanded ENISA mandate.^[2]

These are genuine improvements. But the timeline matters enormously.

The Compliance Paradox

The most operationally significant fact about the January 2026 amendments is buried in the fine print: organisations should not expect to benefit from them anytime soon.

The proposal must first complete trilogue negotiations between the European Parliament and the Council, with political agreement targeted for early 2027. After adoption, Member States will have a 12-month transposition period. Only then will the Commission begin issuing detailed technical requirements at Article 21 level.^[3]

The practical implication: the harmonised, simplified NIS2 that the Commission is describing will not be operationally real for most organisations until 2028 or later. In the meantime, current national rules apply in full. The compliance programmes CISOs are running today remain the operative framework.

This creates a governance dilemma that boards are poorly equipped to navigate. The moment they hear “simplification is coming,” the instinct is to defer investment and wait. That is precisely the wrong response — and part of the CISO’s job right now is to pre-empt it.

What Actually Changes: The Five Threads

1. Gold-Plating Gets a Ceiling

One of the more consequential changes targets the fragmentation created by Member State gold-plating. Under NIS2 as originally transposed, it is a minimum-harmonisation directive — meaning Member States can impose additional obligations beyond the baseline. Belgium, for example, introduced a mandatory coordinated vulnerability disclosure policy on top of Article 21 requirements.^[4]

The January 2026 proposal changes this in a specific and important way. Where the Commission adopts implementing acts specifying technical, methodological, or sectoral risk-management measures under Article 21(5), Member States will no longer be permitted to impose further national requirements for those measures. This effectively shifts the definition of core cybersecurity controls to the EU level.^[5]

For CISOs managing compliance programmes across multiple EU jurisdictions, this is significant. It means that once Article 21 implementing acts are in place, a centralised control framework can be applied without customisation to each Member State’s additional preferences. The compliance overhead of running parallel documentation per jurisdiction — currently estimated at €150,000–€300,000 annually for a mid-sized organisation operating across five Member States — has a defined end state.^[6]

The caveat: this ceiling only applies where the Commission has issued implementing acts. It has not yet done so under existing NIS2 authority. The gold-plating problem persists until the new framework is fully operational.

2. Certification as Compliance Proof

The most board-friendly development in the package is the introduction of certification as a pathway to demonstrating NIS2 compliance — and the explicit limitation it places on supervisory authorities.

Under the proposal, organisations will be able to rely on European cybersecurity certification schemes, including future entity-level cyber-posture certifications, to demonstrate compliance with NIS2 risk-management obligations. Critically, where certification demonstrates compliance, competent authorities will not be permitted to subject the entity to security audits.^[7]

This is a strategic shift. Certification moves from being a voluntary quality label to being a core compliance and risk management instrument. For multinationals, it creates the possibility of a portable, EU-recognised evidence pack that reduces duplicative supervisory demands across jurisdictions.^[8]

The governance implication is clear: investment in certification schemes is no longer purely defensive or reputational. It carries a direct regulatory return — audit exemption. That is a board-level argument for security investment that CISOs have rarely had available to them.

3. The Supply Chain Questionnaire Problem Gets Acknowledged

The Commission explicitly recognises in the proposal that NIS2 supply-chain obligations have generated burdensome and inconsistent supplier questionnaires, often cascading obligations down the supply chain.^[9]

This matters not just as a compliance signal but as a governance validation. The “questionnaire flood” is a real operational problem — organisations receiving dozens of overlapping, inconsistently scoped security assessments from customers and partners, each calibrated to a different national interpretation of Article 21. The Commission’s acknowledgement creates the foundation for a more standardised, certification-based approach to supply chain assurance.

For CISOs managing vendor risk programmes, the direction of travel is toward EU-level certification schemes replacing ad hoc questionnaire-based assurance. The practical implication is that vendor risk governance frameworks should be designed now to accommodate certification-based evidence rather than being locked into proprietary questionnaire formats.

4. Ransomware Reporting Gets Granular — and Legally Exposed

The proposal introduces a significant new disclosure requirement for ransomware incidents. Under the amended framework, incident reports for ransomware attacks must include whether the attack was detected, the attack vector, and whether mitigation measures were implemented.^[10]

More significantly, national authorities will be empowered to request additional information, including whether a ransom demand was made, whether a ransom was paid, the amount paid, the payment method, the recipient, and details of any crypto-asset service providers involved.^[11]

This is not a simplification measure. It is a substantive expansion of incident disclosure obligations with direct legal and commercial implications. Organisations that pay ransoms — and the data suggests a significant proportion still do — will now face disclosure requirements that carry potential regulatory, contractual, and reputational consequences.

CISOs should be updating their incident response playbooks and legal privilege frameworks now. The decision to pay or not pay a ransom has always carried legal risk; under the proposed amendments, it carries disclosure risk regardless of the decision made.

5. New Entities Enter Scope

The proposal expands the scope of NIS2 to include providers of European Digital Identity Wallets, providers of European Business Wallets, and operators of submarine data transmission infrastructure.^[12] Providers of Digital Identity and Business Wallets would be classified as essential entities irrespective of their size.

Additionally, a new “small mid-cap” enterprise category is introduced: entities employing fewer than 750 persons with annual turnover of €150 million or less, or a balance sheet total of €129 million or less. These entities would, as a main rule, be classified as important rather than essential — reducing supervisory intensity for approximately 22,500 companies.^[13]

For CISOs at organisations currently classified as essential, this reclassification at the margins does not change obligations. But it does affect supply chain exposure: important entities face lower supervisory pressure, which may affect the assurance they provide to essential entity partners.

What Has Not Changed

It is worth being explicit about what the January 2026 amendments do not affect.

Article 21 obligations remain in force. The risk management measures — covering incident handling, business continuity, supply chain security, encryption, access control, and multi-factor authentication — apply now under current national transpositions. The amendments do not suspend or defer them.

Board accountability is unchanged. NIS2’s requirement that management bodies approve and oversee cybersecurity risk management measures, and the provision for personal liability in cases of serious negligence, remains fully operative. The amendments do not reduce management exposure.

Enforcement timelines are unchanged. The 24-hour early warning, 72-hour detailed notification, and one-month final report structure remains in place. The Digital Omnibus single entry point, when operational, will streamline how reports are filed — not when.

What CISOs Should Do Right Now

The January 2026 amendments create a specific governance challenge: how to run a compliance programme in a framework that is formally mid-revision, while enforcement under the current framework is active and escalating.

The answer is not to pause. It is to build compliance architecture that is adaptive rather than point-in-time.

Proceed with current Article 21 compliance programmes in full. The amendments do not provide grounds for deferral. Enforcement is active across transposed jurisdictions and supervisory activity is accelerating through 2026.^[14]

Design for certification from the start. Where possible, align current control frameworks and evidence packs with the EU cybersecurity certification schemes that will eventually serve as compliance proof. The investment made now in certification-compatible documentation is not wasted — it is the foundation of the future compliance model.

Update ransomware response playbooks immediately. The expanded disclosure requirements for ransomware incidents represent a near-term operational and legal risk. Incident response plans, legal privilege frameworks, and ransom decision authorities should all be reviewed before the next incident, not after.

Prepare the board for the timeline reality. The narrative that “NIS2 is being simplified” will reach boardrooms before the nuance does. CISOs should proactively brief boards on what the amendments mean in practice: the benefits are real but years away; current obligations apply in full; and the compliance investments being made now are not being made redundant.

Reassess supply chain governance. The Commission’s acknowledgement of the questionnaire problem signals a shift toward certification-based supply chain assurance. Vendor risk frameworks should be redesigned now to accommodate that model.

The Governance Test

The January 2026 NIS2 amendments are, in a technical sense, a simplification exercise. In a governance sense, they are something more demanding: a test of whether organisations have built compliance programmes with the maturity to absorb regulatory evolution without losing momentum.

The organisations that will struggle are those that treated NIS2 as a point-in-time certification exercise — a project with a start date and an end date. The organisations that will benefit from the amendments, when they arrive, are those that have built compliance as an operational capability: adaptive, evidence-based, and embedded in governance rather than delegated to a project team.

For CISOs, the message is unchanged from what it has always been. The threat landscape does not wait for regulatory certainty. Neither should you.

References

[1] Bird & Bird — European Cybersecurity Regulatory Update NIS2 and Beyond (accessed March 2026)

[2] Inside Privacy — European Commission Proposes Targeted Amendments to NIS2, 23 January 2026

[3] DLA Piper — NIS2 Update: EU Moves to Harmonise Cyber Controls, February 2026

[4] Inside Privacy — European Commission Proposes Targeted Amendments to NIS2, 23 January 2026

[5] McDermott Will & Emery — New EU Cybersecurity Package, February 2026

[6] Maiky.io — NIS2 Amendments: What SMEs Need to Know, February 2026

[7] McDermott Will & Emery — New EU Cybersecurity Package, February 2026

[8] IAPP — EU Cybersecurity Reboot: Practical Impacts of the Proposed NIS2 and CSA2 Reforms, 2026

[9] McDermott Will & Emery — New EU Cybersecurity Package, February 2026

[10] Inside Privacy — European Commission Proposes Targeted Amendments to NIS2, 23 January 2026

[11] Ibid.

[12] Freshfields — EU Cybersecurity Package: Commission Proposes Targeted NIS2 Amendments, January 2026

[13] Ibid.

[14] Inside Privacy — What to Watch in 2026: Key EU Privacy & Cybersecurity Developments, 28 January 2026

Over the last year, I’ve sat in more AI strategy conversations than I can count.The energy in those rooms is familiar. Optimism. Curiosity. A little urgency. Sometimes competitive anxiety. AI is framed as acceleration, efficiency, advantage.What I hear less often is a sober discussion about how AI changes our exposure.The latest 2026 X-Force Threat Intelligence Index from IBM, published by IBM X-Force, provides data that should rebalance that conversation. Not because it is dramatic.Because it is directional.

The report shows a 44% year-over-year increase in exploitation of public-facing applications. Forty percent of incidents began with vulnerability exploitation rather than phishing. Ransomware and extortion groups grew by 49%. More than 300,000 AI and chatbot credentials were observed for sale in underground markets.Those numbers are not random spikes. They reflect a shift in tempo. Attackers are becoming faster. More automated. Less dependent on deep expertise. AI reduces the time needed for reconnaissance. It assists with scripting. It helps iterate payloads. It personalizes communication at scale.The barrier to entry is lowering. And when barriers lower, volume rises.

The Compression of Time

What concerns me most is not the sophistication of AI itself. It is the compression it introduces. In cybersecurity, time has always been a silent variable. Time to detect. Time to patch. Time to respond. Time to recover.If reconnaissance once took days and now takes hours, if exploit development can be accelerated with model assistance, if campaigns can be refined dynamically, then the defender’s margin for error shrinks.

The 40% statistic around vulnerability exploitation is particularly telling. For years, phishing dominated board-level discussions. Now exploitation of exposed systems is leading initial access. This does not mean phishing has disappeared. It means automation has matured. When attackers can scan, analyze, and prioritize weaknesses at scale, exposure becomes more visible to them than it is to us.

That is not a technology problem alone. It is a governance problem.

Identity Is Quietly Becoming the Center of Gravity

The discovery of more than 300,000 AI-related credentials for sale should not be dismissed as an isolated statistic. AI platforms increasingly sit inside workflows. They connect to APIs. They process internal context. They often inherit permissions that were granted for convenience rather than scrutiny. Compromise one of those accounts, and you may not just gain access to a tool. You gain insight into how an organization thinks, drafts, analyzes, and sometimes even decides.Identity has been called the new perimeter for years. With AI, that statement becomes literal. If we are not monitoring AI platform access with the same rigor as privileged accounts, we are behind.

The Governance Gap

In executive settings, I often hear thoughtful discussions about how AI can improve productivity and reduce cost. These are valid conversations. But they must be matched with equally disciplined questions:

How does AI change our threat model?

Where does AI sit in our risk register?

What new attack paths does it introduce?

Are we adjusting our incident response assumptions?

Attackers do not wait for policy cycles. They experiment in real time.

Enterprises, understandably, operate within structure and oversight. That structure is necessary. But it also means that we must be deliberate about anticipating risk, not reacting to headlines. AI does not remove fundamentals. It intensifies them. If 40% of attacks begin with vulnerability exploitation, patch discipline and exposure management remain decisive. If ransomware groups are growing by nearly 50%, resilience planning cannot be symbolic.

Sophisticated technology does not compensate for neglected basics.

Leadership in a Compressed Environment

AI is leverage. It increases capability on both sides. The difference is constraint. Adversaries innovate without governance. Enterprises innovate within it. That constraint is not a weakness. It is the price of operating responsibly. But responsible leadership requires clarity. AI is no longer just an innovation topic. It is an enterprise risk variable. It changes the speed of attack, the value of identity, and the scale at which exploitation can occur. The question for 2026 is not whether your organization is experimenting with AI. It is whether your threat model reflects the fact that your adversaries already are.

If that discussion is not happening at the highest level, it should be.

The confrontation between Anthropic and the Pentagon that culminated on February 27, 2026 is already being framed as a battle between AI ethics and government overreach. That framing is partially correct. But as someone who has spent over two decades managing enterprise security, vendor relationships, and regulatory compliance, I see something else entirely: a case study in vendor governance failure with consequences that will reshape how AI companies engage with government clients.
Let me be clear upfront. My position is not binary. On surveillance, Anthropic is right. On autonomous weapons, the Pentagon is right. And on vendor governance, Anthropic made a serious, avoidable mistake.

Where Anthropic Is Right: The Surveillance Line
Mass surveillance of a country’s own citizens is not a gray area. It is a documented, historical pattern of institutional abuse. From COINTELPRO to PRISM, from the Church Committee findings to the Snowden revelations, the evidence is consistent: when governments acquire surveillance infrastructure, the scope expands, the oversight erodes, and citizens pay the price.
COINTELPRO (1956–1971) was a covert FBI program that surveilled, infiltrated, discredited, and disrupted American political organizations — targeting civil rights leaders, anti-Vietnam War groups, feminist organizations, and the Black Panther Party. It operated through illegal wiretapping, forged documents, anonymous harassment campaigns, and physical infiltration of lawful political groups. Its existence was unknown to the public until March 1971, when activists broke into an FBI field office in Media, Pennsylvania and leaked classified documents to the press. [1] The U.S. Senate later concluded that COINTELPRO “was a sophisticated vigilante program aimed squarely at preventing the exercise of First Amendment rights of speech and association.” [2]
The Church Committee (1975–1976) was a U.S. Senate select committee formed specifically in response to COINTELPRO and emerging reports of intelligence agency abuse. Chaired by Senator Frank Church, it investigated the CIA, NSA, FBI, and IRS and uncovered a catalog of previously unknown programs: Operation SHAMROCK (the NSA intercepting all telegrams entering and leaving the U.S. since 1945), Project MINARET (warrantless surveillance of American citizens including Martin Luther King Jr., Jane Fonda, and even Senator Church himself), CIA assassination plots against foreign leaders, and mass mail-opening operations. [3] Senator Walter Mondale publicly warned during the hearings that the NSA’s capabilities “could be used by President ‘A’ in the future to spy upon the American people, to chill and interrupt political dissent.” [4] The committee’s findings directly led to the creation of the Foreign Intelligence Surveillance Act (FISA) in 1978.
PRISM (revealed 2013) was an NSA classified program that collected stored internet communications — including emails, photos, documents, audio, and video — directly from the servers of nine major technology companies including Microsoft, Google, Apple, Facebook, Yahoo, Skype, and YouTube. It operated under Section 702 of the FISA Amendments Act and was revealed to account for approximately 91% of the roughly 250 million internet communications the NSA collected each year. [5] The program’s existence was completely unknown to the public until it was disclosed by Edward Snowden.
The Snowden Revelations (2013) documented the full scope of NSA surveillance through thousands of leaked classified documents provided to journalists Glenn Greenwald and Laura Poitras. Beyond PRISM, Snowden exposed XKeyscore — an analytical tool that allowed NSA analysts to search through vast databases of emails, online chats, and browsing histories of millions of individuals without prior authorization. [6] He also revealed bulk telephone metadata collection requiring Verizon to hand over records of millions of Americans’ calls daily, global financial data tracking, and extensive surveillance of allied foreign governments. In September 2020, a U.S. federal court ruled that the NSA’s bulk phone metadata collection program exposed by Snowden was illegal and likely unconstitutional. [7]
The pattern across all four cases is identical: programs launched with narrow stated purposes, expanded far beyond original scope, operated with minimal or no oversight, and only exposed through leaks or external investigation — never through internal accountability.
Anthropic’s refusal to allow Claude to be used as an engine for domestic mass surveillance is not ideological posturing. It is a reasonable safeguard grounded in this evidence. An AI model capable of processing vast amounts of unstructured data, integrated into classified government networks, used to monitor citizens at scale — that is a fundamentally different proposition than any previous surveillance tool. The potential for abuse is not hypothetical. It is historically documented.
On this point, I support Anthropic’s position without reservation. Certain lines should not be crossed regardless of contractual pressure, and the mass surveillance of citizens is one of them.

Where the Pentagon Is Right: The Weapons Autonomy Argument
The question of autonomous weapons is more nuanced, and here my view diverges from Anthropic’s.
When a sovereign military procures a technology for lawful defense purposes, it operates within an existing legal framework — international humanitarian law, rules of engagement, civilian oversight, command accountability. These are not perfect systems, but they are established governance structures with centuries of development behind them.
A private AI vendor inserting its own restrictions on weapons targeting decisions is a qualitatively different kind of intervention. It assumes that Anthropic’s judgment on acceptable military use supersedes the legal and operational frameworks that already govern these decisions. That is a significant overreach for a commercial technology provider.
If today’s AI models are not reliable enough for autonomous targeting — and there are serious technical arguments that they are not — that concern should be addressed through contractual reliability standards, testing requirements, and operational guardrails negotiated upfront. Not through unilateral vendor restrictions imposed after deployment.
The Pentagon’s position that it must retain operational flexibility for all lawful use cases is not unreasonable. That is how defense procurement works.

Where Anthropic Failed: The Vendor Governance Mistake
This is where I need to be direct, because the industry commentary has largely missed this point.
Anthropic accepted a contract with the Department of Defense. They operated within classified environments. They became embedded in mission-critical systems — reportedly including the operation to capture Nicolás Maduro. [8] And then, after achieving that position of operational dependency, they attempted to impose restrictions that should have been negotiated before the relationship began.
In any mature vendor management framework — ISO 27001, NIST SP 800-161, or basic procurement governance — this behavior would trigger an immediate red flag. It is not how responsible vendors operate.
Think of the analogy in enterprise security: imagine a SIEM vendor, after deployment in your SOC, informing you that they have reviewed your use cases and are uncomfortable with certain threat hunting activities. You would not accept it. You would escalate it. You would terminate the contract and flag that vendor in every future assessment.
The DoD’s reaction, while politically charged in its execution, follows exactly this logic. A critical vendor changing terms on embedded, operational infrastructure is a supply chain risk by definition.
If Anthropic had genuine ethical objections to certain military use cases — and some of those objections are legitimate — the time to raise them was before signing. The options were straightforward: negotiate explicit use restrictions in the contract upfront, decline the engagement entirely, or accept the operational realities of defense contracting. What they could not do, with any integrity, was take the contract, become critical infrastructure, and then attempt to impose conditions mid-relationship.
Dario Amodei is a brilliant researcher and a principled leader. But this decision reflects a gap between AI safety expertise and enterprise vendor governance experience. Those are different disciplines, and conflating them created this crisis.

What This Means for the Industry
This situation will not be the last of its kind. As AI models become embedded in government systems, healthcare infrastructure, financial services, and critical national systems, the tension between vendor ethics and client operational requirements will intensify.
The lesson for AI companies is not to abandon principles. It is to operationalize them earlier in the engagement cycle. Ethical red lines belong in contract negotiations, not in operational disputes after deployment.
The lesson for organizations procuring AI is equally clear. Vendor AI governance is now a distinct risk category that your existing frameworks may not adequately address. You need to assess not just what an AI vendor’s model can do, but what conditions the vendor will unilaterally impose on how you use it — and when.
The lesson for policymakers and regulators is that the gap between AI safety principles and procurement law is real, consequential, and urgently needs to be addressed. We need frameworks that allow AI companies to maintain ethical boundaries without creating operational crises in the institutions that depend on their technology.

Conclusion
Anthropic drew two lines. One of them — surveillance — was the right line to draw. The other — weapons autonomy — overstepped what a commercial vendor should be dictating to a sovereign military operating within legal frameworks.
But the deeper failure was not about where the lines were drawn. It was about when. Principles have no credibility if they only appear after the contract is signed, the systems are deployed, and the dependency is established.
The AI industry is navigating genuinely new territory. The companies that will earn lasting trust — from governments, enterprises, and the public — are those that build governance into the relationship from the first conversation, not those that impose it at the moment of maximum leverage.
That is not ethics. That is vendor risk management. And right now, the industry needs both.

References
[1] Federal Bureau of Investigation. COINTELPRO. FBI Records: The Vault. https://vault.fbi.gov/cointel-pro
[2] United States Senate Select Committee on Intelligence. Senate Select Committee to Study Governmental Operations with Respect to Intelligence Activities (Church Committee). U.S. Senate Historical Office. https://www.senate.gov/about/powers-procedures/investigations/church-committee.htm
[3] Church, F. (1975). Curtailment of the National Security State: The Church Senate Committee of 1975–1976. Frank Church Institute, Boise State University. https://www.boisestate.edu/sps-frankchurchinstitute
[4] PBS Frontline. Pre-Emption: The Church Committee Hearings & The FISA Court. https://www.pbs.org/wgbh/pages/frontline/homefront/preemption/churchfisa.html
[5] Electronic Privacy Information Center. EPIC v. DOJ – PRISM. https://epic.org/documents/epic-v-doj-prism/
[6] MacAskill, E. & Greenwald, G. (2013, July 31). XKeyscore: NSA tool collects ‘nearly everything a user does on the internet’. The Guardian.
[7] Wikipedia. Snowden effect. https://en.wikipedia.org/wiki/Snowden_effect — referencing United States Court of Appeals for the Ninth Circuit ruling, September 2020.
[8] Axios. Trump moves to blacklist Anthropic’s Claude from government work (February 27, 2026). https://www.axios.com/2026/02/27/anthropic-pentagon-supply-chain-risk-claude

There is a pattern playing out in organizations across every sector right now. The board approves an AI strategy. The CTO selects a vendor. The business units begin deploying tools. And somewhere along the way — usually after the fact — the CISO is handed responsibility for securing it all.

This is not anecdotal. The SANS 2025 AI Survey, one of the most comprehensive annual assessments of AI's impact on security, found that 100% of organizations plan to incorporate generative AI within the next year, yet it identifies a "concerning lack of security team involvement in governing GenAI" as one of its most significant findings. Only 20% of security professionals report even limited involvement in governing generative AI at the enterprise level [1].

The result is a structural accountability gap: CISOs are expected to own the risk of systems they had no hand in designing, selecting, or deploying.

This has always been part of the job — CISOs have never controlled every technology decision in their organizations. But AI changes the stakes fundamentally. Traditional software executes instructions. Agentic AI makes decisions and takes autonomous actions. It operates continuously, at machine speed, touching sensitive data across systems in ways that are often invisible to the security team.

As Cybersecurity Insiders' 2025 State of AI Data Security report puts it plainly: "You cannot secure an AI agent you do not identify, and you cannot govern what you cannot see" [2].

The question for CISOs is not whether to accept this responsibility — it will be assigned regardless. The question is how to establish enough control to manage it responsibly.

Why Traditional Security Frameworks Break Under AI

Most organizations are making a critical mistake: treating AI security as a simple extension of their existing privacy and data protection frameworks. The CSA and Google Cloud 2025 State of AI Security and Governance report — based on 300 responses from IT and security professionals — found that organizations are widely "failing to account for new, AI-specific threats," with data exposure (52%) dominating concerns while genuinely AI-native risks like model integrity compromise (12%) and data poisoning (10%) barely register [3].

This approach fails for three reasons.

First, AI introduces a new class of actor into your environment. An AI agent is not a user, and it is not traditional software. It is an autonomous, non-human identity with persistent access to data, systems, and actions. Your existing IAM policies were built for humans. They assume deliberate, observable behavior. According to Obsidian Security's 2025 AI Agent Security Landscape report, AI agents routinely hold 10 times more privileges than required, and 90% of agents are currently over-permissioned [4]. Applying human-centric identity models to machine-speed actors creates compounding blind spots.

Second, the attack surface is fundamentally different. The 2025 Cybersecurity Insiders report found that 76% of security professionals identify autonomous AI agents as the hardest systems to secure, while 57% lack the ability to block risky AI actions in real time [2]. The threat is not only external: a compromised or misdirected agent can operate under valid credentials, execute legitimate-looking workflows, and exfiltrate data before any detection threshold is triggered.

Third, and most critically, visibility is the core problem — not the perimeter. The same Cybersecurity Insiders report found that nearly half of organizations have no visibility into AI usage, and another third have only minimal insight, leaving most enterprises unsure where AI is operating or what data it touches [2].

A Practical Governance Framework for the CISO

What follows is not a compliance checklist. It is an operational framework for CISOs who need to establish meaningful control over AI risk in environments where deployment has already outpaced governance.

Step 1: Build Your AI Asset Inventory

Before anything else, you need to know what AI is running in your environment. This means active discovery — not relying on what the business reports, because shadow AI is a growing and material problem. According to Acuvity's 2025 State of AI Security report, 49% of organizations expect a shadow AI incident within the next 12 months [5]. Use your existing DLP, CASB, and network monitoring tools to detect API calls to known AI services. Conduct departmental audits. The goal is a living inventory that maps every AI tool, the data it accesses, the actions it can take, and who owns it. This inventory is the foundation of everything that follows.

Step 2: Establish a Formal AI Procurement Gate

Every AI tool — whether enterprise platform or departmental point solution — must pass through a security review before deployment. The CSA/Google Cloud research found that organizations with comprehensive governance policies are nearly twice as likely to successfully adopt agentic AI (46%) compared to those with only partial policies (25%) [3]. The gate should include: data handling and residency assessment, third-party risk evaluation, review of autonomous action scope, and explicit sign-off from security, legal, and data protection before any pilot proceeds.

Step 3: Apply Zero Trust Principles to AI Agents

Treat every AI agent as a privileged non-human identity. This means least-privilege access scoped to the minimum data and systems required for each specific function. It means full action logging covering every tool invocation, every data access, every output. It means runtime guardrails that can block unsafe actions before they execute. Microsoft's 2026 Cyber Pulse AI Security Report, drawing on first-party telemetry from tens of thousands of deployed agents, calls this explicitly: organizations must apply Zero Trust principles to AI agents with the same rigor applied to privileged human users, including identity enforcement, scope boundaries, and behavioral monitoring [6].

Step 4: Establish Continuous AI Monitoring

Static assessments are insufficient for systems that adapt over time. The 2025 Acuvity State of AI Security report found that 38% of organizations identify the runtime phase as their most vulnerable AI security point — the moment when AI components interact with real data and users in production [5]. Monitoring must be continuous: prompts and outputs, tool calls, agent-to-agent interactions, data access patterns, and behavioral drift. Build this into SOC workflows now, before volume makes it unmanageable.

Step 5: Reframe AI Risk for the Boardroom

The CISO's ability to govern AI depends significantly on how well they communicate AI risk upward. Technical explanations of model vulnerabilities, prompt injection, or data poisoning will not move a board to action. What will is connecting AI risk to what boards already care about.

Proofpoint's 2025 Voice of the CISO report — based on 1,600 CISOs across 16 countries — found that boards now rank business valuation as their top concern following a cyberattack, up from the bottom of the list in previous years [7]. That is the hook. An ungoverned AI agent accessing sensitive customer data is not a technical incident — it is a GDPR and NIS2 data breach with notification obligations and financial penalties. An AI system making autonomous decisions in a regulated process is an EU AI Act audit finding waiting to happen. Frame it this way: every AI deployment without governance is an unquantified liability. The cost of governance is known and controllable. The cost of a regulatory action or breach is not.

The Bigger Picture

The data is unambiguous. Boardroom alignment with CISOs has declined from a high of 84% in 2024 to 64% this year Proofpoint — even as AI adoption accelerates and the CISO's scope of responsibility expands. The CSA/Google Cloud research found that only 26% of organizations have comprehensive AI security governance in place, and that the gap between those organizations and the majority still developing partial policies is widening across every dimension: leadership awareness, workforce readiness, and confidence in AI protection [3].

The CISO's impossible position — securing what you didn't build — is not going to resolve itself. The pace of AI adoption will not slow to accommodate governance maturity. The governance must be built while the deployment is already in motion.

That is difficult work. But it is the work. The CISOs who build it now — methodically, with business language that boards can act on — will be the ones who remain credible partners to their organizations rather than perpetual firefighters.

The goal is not to stop AI. It is to make AI governable. Those are very different ambitions. Only one of them is achievable.

Sources

[1] SANS Institute. SANS 2025 AI Survey: Measuring AI's Impact on Security Three Years Later. Available at: https://www.elastic.co/pdf/sans-2025-ai-survey-elastic.pdf

[2] Cybersecurity Insiders / Cyera. 2025 State of AI Data Security Report. December 2025. Available at: https://www.prnewswire.com/news-releases/cybersecurity-insiders-warns-ai-adoption-is-outpacing-governance-in-new-2025-report-302630674.html

[3] Cloud Security Alliance / Google Cloud. State of AI Security and Governance Survey Report. December 2025. Available at: https://cloudsecurityalliance.org/press-releases/2025/12/18/csa-and-google-cloud-study-finds-governance-maturity-is-strongest-predictor-of-ai-readiness

[4] Obsidian Security. 2025 AI Agent Security Landscape: Players, Trends, and Risks. January 2026. Available at: https://www.obsidiansecurity.com/blog/ai-agent-market-landscape

[5] Acuvity. 2025 State of AI Security. Available at: https://acuvity.ai/2025-state-of-ai-security/

[6] Microsoft Security. Cyber Pulse: An AI Security Report. 2026. Available at: https://www.microsoft.com/en-us/security/security-insider/emerging-trends/cyber-pulse-ai-security-report

[7] Proofpoint. 2025 Voice of the CISO Report. August 2025. Available at: https://www.proofpoint.com/us/newsroom/press-releases/proofpoint-2025-voice-ciso-report

In my previous article, I wrote about the CISO's dilemma: how we speak a language of risk while boards hear only revenue. The feedback I received confirmed what most of us already know — the communication gap is real, it is persistent, and it has consequences.

But something has changed. A new threat has entered the room, and this time it didn't wait for a boardroom presentation to make itself known. It walked in through every employee's laptop, every SaaS subscription approved without IT review, and every AI assistant quietly embedded into daily workflows.

It's called Shadow AI. And it is no longer a cybersecurity problem the CISO can manage in isolation. It has become a governance liability that sits squarely on the Board's shoulders — whether they know it or not.

What Shadow AI Actually Means

Shadow AI refers to the use of artificial intelligence tools and services within an organisation without the knowledge, approval, or oversight of IT and security teams. Think of employees pasting customer data into ChatGPT to draft a proposal. Developers using an unsanctioned AI coding assistant that sends code snippets to external servers. Finance teams feeding sensitive spreadsheets into AI summarisation tools because it saves them two hours on a Monday morning.

None of this is malicious. All of it is dangerous.

The problem with Shadow AI is not that employees are breaking rules. The problem is that organisations have created conditions where the path of least resistance — the fast, productive, AI-assisted path — runs directly through a governance blind spot.

In my doctoral research on AI governance and enterprise cyber risk (I am currently completing a DBA in Artificial Intelligence, with a dissertation focused specifically on Shadow AI and the security ownership gap), I see this pattern repeated across sectors and organisation sizes. The technology has outpaced the governance. And the gap between them is where incidents are born.

From Shadow IT to Shadow Agents: The Escalation Nobody Is Ready For

For years, security teams have managed Shadow IT — the use of unsanctioned applications and cloud services. It was a manageable problem. Visibility tools improved. Policies were written. Training was delivered.

Shadow AI is different in kind, not just degree.

Where Shadow IT introduced unauthorised tools, Shadow AI introduces autonomous behaviour. According to Google Cloud's Cybersecurity Forecast 2026, the proliferation of sophisticated, autonomous agents — often deployed by employees without corporate approval — "will create invisible, uncontrolled pipelines for sensitive data, leading to data leaks and compliance violations." [1] The report explicitly names this the "Shadow Agent" problem, warning that by 2026, it will escalate into one of the defining security challenges for enterprise organisations.

This is not a fringe prediction from a vendor with something to sell. It is the assessment of the Google Threat Intelligence Group and Mandiant Consulting, drawn from real-world incident response data.

These agents act, make decisions, and move data — often without any human in the loop at the moment it matters. And banning them is not a viable answer. As the same forecast states, banning agents "only drives usage off the corporate network, eliminating visibility entirely." [1] What is needed is governance — clear, proportionate, and actually enforced governance.

Why This Is Now a Board-Level Issue

Here is where boards need to pay attention, and I say this with the same directness I brought to the boardroom communication problem in my previous piece.

NIS2 and Personal Liability

Under the NIS2 Directive (Directive EU 2022/2555), organisations classified as essential or important entities are required to implement cybersecurity risk management measures covering the security of their network and information systems, including supply chain security. Article 20 goes further than its predecessor in one critical way: it places personal accountability on management bodies.

As DLA Piper's analysis of NIS2's management body rules notes, "NIS2 introduces personal accountability for members of the management bodies," requiring that they not only approve but actively oversee the implementation of cybersecurity risk management measures. [2] Article 20(1) mandates this oversight as a standing obligation — not an annual event.

The practical consequence is stark. When an employee sends client data to an external AI service without authorisation, that is not simply a rogue action. In regulatory terms, it is a supply chain event — and Article 21(2)(d) of NIS2 explicitly requires entities to address security in their supply chain relationships, including the services they use. [3] If such an event results in a reportable incident, regulators will not direct their questions at the employee. They will examine the governance structure above them, and whether management was fulfilling its documented oversight obligations.

Fines for essential entities under NIS2 can reach €10 million or 2% of global annual turnover — whichever is greater. [3] And member states have latitude to gold-plate beyond the EU baseline. Germany's national implementation act, which entered into force in December 2025, allows management bodies to be held personally responsible for failures to implement and oversee required measures. [4]

The EU AI Act: Another Layer of Exposure

The EU AI Act adds a separate but overlapping regulatory dimension. The prohibition on certain AI practices has applied since February 2025. GPAI model obligations became effective in August 2025. Most remaining obligations, including the full transparency framework under Article 50, apply from August 2026. [5]

Organisations that deploy AI systems in ways that affect individuals — including employees — carry obligations around transparency, risk classification, and human oversight. Deploying an AI tool to screen job applications, assess employee performance, or make customer-facing decisions without proper governance is not just a cybersecurity risk. It is a direct regulatory exposure under a framework with fines of up to €35 million or 7% of global annual turnover for the most serious violations. [6]

Critically, analysis of current enterprise readiness suggests that over half of organisations lack systematic inventories of AI systems currently in production. [7] You cannot govern, classify, or demonstrate compliance for AI systems you do not know exist. Shadow AI makes this problem structurally worse.

What the Security Ownership Gap Looks Like in Practice

In conversations with security leaders across Europe, a consistent picture emerges. The CISO raises Shadow AI as a risk. It is acknowledged. It is perhaps added to a risk register. And then it sits there, while the organisation continues to grow its AI footprint organically — department by department, tool by tool — without a coherent framework for who owns the risk, who monitors it, and who is accountable when something goes wrong.

This is what I describe in my dissertation as the security ownership gap: the space between identifying a risk and actually governing it. It is not a failure of intent. It is a structural failure. Security teams are asked to monitor a landscape they cannot fully see. Business teams adopt tools they do not fully understand. And boards approve digital transformation strategies without visibility into the shadow infrastructure growing beneath them.

The gap is not filled by a policy document. It is filled by a decision — a deliberate, board-level decision to treat AI governance as a strategic priority, not a compliance checkbox.

What Good Governance Actually Looks Like

There is no simple answer, but there is a defensible starting framework.

Visibility before control. You cannot govern what you cannot see. The first step is an honest inventory of AI tools in use across the organisation — not just the ones IT has approved, but the ones employees are actually using. This requires a combination of technical discovery and cultural honesty: making it safe to report AI tool usage without fear of punishment.

Classification before prohibition. Not every AI tool carries the same risk. A framework that classifies AI usage by data sensitivity, autonomy level, and external connectivity allows proportionate responses. An AI assistant that summarises internal meeting notes is a different risk profile from an agent with API access to your CRM that autonomously contacts customers.

Ownership before accountability. Every AI tool in use should have a named owner — not just a user, but someone accountable for its governance. This means understanding what data it processes, what its terms of service permit, and what the breach notification obligations are if something goes wrong.

Documented decisions at board level. Where AI tools carry material risk, the decision to accept, mitigate, transfer, or avoid that risk should be documented and reviewed at the appropriate governance level. Under NIS2 Article 20, supervisory authorities require digital evidence showing that the board set direction, asked questions, issued challenges, and closed the loop on escalation. [8] Signing off on a policy once a year is no longer sufficient.

The Honest Conversation That Needs to Happen

Most CISOs I know are not surprised by Shadow AI. They have been watching it grow for two years. What surprises them is the speed of escalation — from employees using ChatGPT to draft emails, to business units running autonomous agents that touch production data.

The conversation that needs to happen is not "how do we stop employees using AI." That conversation is over, and AI won. The conversation that needs to happen is: who is accountable for AI risk in this organisation, and what decisions has the board actually made about it?

Because in the absence of that conversation, the default answer is: nobody is accountable, no decisions have been made, and the risk is accumulating quietly in every corner of the business.

That is not a technology problem. That is a governance failure. And governance failures, as NIS2 is now making very clear, have names attached to them.

A Final Thought

In my previous article, I described the CISO's dilemma as the struggle to be heard in a boardroom that only hears revenue. Shadow AI changes that dynamic.

For the first time, the risk is not something the CISO is warning about in the future tense. It is something happening right now, at scale, across every organisation that has not yet built a framework to govern it.

AI is simultaneously the most powerful productivity tool most organisations have ever deployed and one of the most unmanaged risk surfaces they have ever created. The revenue conversation and the risk conversation are about to collide.

The question is not whether boards will have to engage with this. They will. The question is whether they will engage with it before an incident — or after one.

I know which conversation I would rather be in.

References

[1] Google Cloud, Cybersecurity Forecast 2026, November 2025. Available at: https://cloud.google.com/blog/topics/threat-intelligence/cybersecurity-forecast-2026/

[2] DLA Piper, NIS2 Directive Explained: Part 2 – Management Bodies Rules, November 2025. Available at: https://www.dlapiper.com/en/insights/publications/2025/11/nis2-directive-explained-part-2-management-bodies-rules

[3] Codific, NIS2 Directive: Compliance Guide, Fines & Scope, November 2025. Available at: https://codific.com/nis-2-directive-compliance-guide-fines-scope/

[4] Morrison Foerster, Flipping the NIS2 Switch: What Germany's Implementation Means for 2026 Compliance, December 2025. Available at: https://www.mofo.com/resources/insights/251208-flipping-the-nis2-switch-what-germanys-implementation

[5] European Commission, Navigating the AI Act, 2025. Available at: https://digital-strategy.ec.europa.eu/en/faqs/navigating-ai-act

[6] DLA Piper, Latest Wave of Obligations Under the EU AI Act Take Effect, August 2025. Available at: https://www.dlapiper.com/en-us/insights/publications/2025/08/latest-wave-of-obligations-under-the-eu-ai-act-take-effect

[7] Secure Privacy, EU AI Act 2026 Compliance Guide: Key Requirements Explained, 2025. Available at: https://secureprivacy.ai/blog/eu-ai-act-2026-compliance

[8] ISMS.online, NIS 2 Article 20: What Personal Cyber Liability Means for Every Board Director, October 2025. Available at: https://www.isms.online/nis-2/enforcement/board-liability/article-20/

Angelos Varthalitis is Chief Information Security Officer at Ovivio NL (KidsKonnect), a leading European childcare SaaS platform. With over 20 years of cybersecurity experience across SaaS, energy, and transportation sectors, he holds certifications including CISM and NIS2 Lead Implementer. He is currently completing a Doctorate in Business Administration specialising in Artificial Intelligence, with a dissertation focused on Shadow AI and the security ownership gap in enterprise cyber risk governance. He writes at www,varthalitis,eu.

You prepare for weeks. You build the deck. You map the threats, quantify the risks, present the roadmap. You walk in confident. You walk out with 30% of the budget you asked for and a polite suggestion to “prioritize.”(Schmitz-Berndt, 2021)

Three months later, something breaks. And suddenly everyone wants to know why security wasn’t taken seriously.

Sound familiar?

The problem isn’t technical. It’s linguistic.

Boards are not incompetent. They are laser-focused on what they are accountable for — revenue, growth, shareholder value, regulatory exposure. When a CISO walks in talking about CVEs, threat actors, and zero-day vulnerabilities, the board doesn’t tune out because they don’t care. They tune out because they genuinely don’t know what to do with that information.

We are speaking Portuguese in a room that only understands Greek.

The gap between the CISO and the board is not an intelligence gap. It is a translation gap. And for too long, we have expected the board to learn our language instead of learning theirs.

What boards actually respond to

Forget the technical jargon. Start asking yourself one question before every board presentation: “So what does this mean for the business?”

A ransomware risk is not a technical problem. It is 72 hours of operational downtime, €2M in recovery costs, and your company’s name in every major newspaper. Say that instead.

A missing patch management process is not a vulnerability gap. It is a direct NIS2 compliance violation that exposes your board members to personal liability. Say that instead.

Regulatory frameworks like NIS2 are actually a CISO’s best friend in the boardroom — not because compliance is the goal, but because liability gets attention that threat intelligence never will. When board members understand that a security failure can land on them personally, the conversation changes fast.

The other side of the problem

Here is something we don’t say out loud enough: sometimes we make it worse.

We present problems without options. We ask for everything and explain nothing. We lead with worst-case scenarios and then wonder why the board becomes numb to the alarm bells.

The most effective CISOs I know present like business executives, not security engineers. They bring three options with clear trade-offs — not one “right answer.” They quantify risk in euros, not CVSS scores. They connect every recommendation to a business outcome the board already cares about.

They make it easy to say yes.

What I have learned

After more than two decades in cybersecurity — across SaaS, energy, transportation, and critical infrastructure — the hardest lesson I had to learn was this:

My job is not just to protect the organization. My job is to make the board capable of making informed decisions about risk.

That is a fundamentally different mandate. And it changes everything about how you walk into that room.

Stop trying to make them afraid. Start trying to make them informed. Fear creates paralysis. Information creates decisions.

Three things you can do starting Monday

First, audit your last board presentation. Count how many times you used technical terminology without a business translation. That number is your communication gap.

Second, find your CFO before your next board meeting. Understand what financial risks keep them up at night. Then connect your security roadmap directly to those risks. You will be speaking their language before you even enter the room.

Third, stop presenting problems. Start presenting choices. “We can accept this risk, mitigate it with X investment, or transfer it through insurance — here are the trade-offs.” Boards are decision-making bodies. Give them something to decide.

The bottom line

The board is not your obstacle. The board is your most important stakeholder — and right now, most of us are failing to communicate with them effectively.

The organizations that will navigate the next wave of cyber threats, regulatory pressure, and AI-driven risk are not necessarily the ones with the biggest security budgets. They are the ones where the CISO and the board are actually speaking the same language.

That translation starts with us.