By Angelos Varthalitis, CISSM | CISO, KidsKonnect (Ovivio NL) | Founder, AVSec Advisory | DBA Researcher — AI Governance & Cyber Risk

On 20 January 2026, the European Commission published its cybersecurity package: targeted amendments to the NIS2 Directive, a revised Cybersecurity Act (CSA2), and a broader Digital Omnibus that touched the AI Act, GDPR, ePrivacy, and the Data Act. The framing was clear: simplification, harmonisation, certification-based compliance.

Four months later, that package no longer exists in the form it was proposed.

Two distinct forces have already started reshaping it. The first is regulatory: on 18 March 2026, the European Data Protection Board (EDPB) and the European Data Protection Supervisor (EDPS) adopted Joint Opinion 4/2026, formally requested by the Commission, with specific recommendations that will likely affect the final text [1]. The second is political: in the early hours of 7 May 2026, after a nine-hour trilogue under the Cypriot Presidency, the European Parliament and the Council reached a provisional agreement on the Digital Omnibus on AI [5]. The new application dates for high-risk AI systems are now the operative planning baseline.

Neither development is a footnote. Together, they tell CISOs that the cybersecurity and AI compliance baseline they were planning against in January is no longer current — and that the convergence of these regulatory tracks is being shaped right now by actors other than the Commission.

This article unpacks both developments, explains what is likely to survive in the final text and what is not, and lays out what CISOs should be doing about it.

Signal One: The EDPB/EDPS Joint Opinion 4/2026

On 21 January 2026, one day after the cybersecurity package was published, the Commission formally consulted the EDPB and the EDPS under Article 42(2) of Regulation (EU) 2018/1725. Their Joint Opinion 4/2026, adopted on 18 March, is a substantive document that does three things: it endorses the package’s overall direction, identifies specific provisions where data protection considerations require amendment, and signals where data protection authorities will assert influence during the trilogue [1].

For CISOs reading the Opinion as a forward indicator of the final text, four points stand out.

The “double-sided” framing matters. The Opinion opens with a principle that recurs across more than sixty paragraphs: cybersecurity serves the protection of personal data by limiting the risks of unwanted access, modification, or unavailability — but some cybersecurity measures can themselves interfere with privacy and data protection [1]. The implication: necessity and proportionality, not effectiveness alone, will be the standard applied to ENISA’s expanded role, to certification schemes, and to any future implementing acts. This is a governance frame CISOs should adopt internally — particularly for AI-assisted security tooling that itself processes personal data.

Single-entry point for personal data breach notification: now politically reinforced. The EDPB and the EDPS strongly support the establishment of a single-entry point for the notification of personal data breaches, framing it as a measure that reduces administrative burden without affecting the level of protection for data subjects [1]. Combined with the parallel position taken in Joint Opinion 2/2026 on the broader Digital Omnibus [9], this is the clearest signal yet that incident reporting consolidation across NIS2, GDPR, DORA, and the CER Directive will survive the legislative process — even if precise mechanics remain under negotiation. For CISOs, the planning implication is that incident response playbooks should already be designed around a single reporting channel for cross-regime incidents by 2027–2028.

ENISA’s expanded role comes with conditions. The Opinion welcomes the strengthening of ENISA but pushes back on three specific design elements. First, it recommends that the EDPS — not only the EDPB — be entitled to request ENISA advice on cybersecurity aspects of EU data protection law (Article 5(1)(h) CSA2). Second, it argues that any ENISA Management Board decisions on additional personal data processing measures (Article 66(2) CSA2) should require prior consultation with the EDPS. Third, it recommends that ENISA consult the EDPB before adopting any cybersecurity certification scheme that intersects with GDPR certification (Article 80(1)(w) CSA2) [1]. These are procedural rather than substantive changes, but they reshape the governance architecture of cybersecurity certification — every scheme will carry a data protection consultation step.

The European Cybersecurity Skills Framework gets pushed beyond professionals. Article 19 of the CSA2 Proposal would limit the European Cybersecurity Skills Framework (ECSF) to cybersecurity professionals. The Opinion pushes hard against this, recommending the inclusion of a “Cybersecurity for generalists” profile covering the minimum skills every working-age EU resident should possess to interact safely with the digital single market — particularly against AI-assisted phishing, deepfakes, impersonation, and social engineering. The Opinion further recommends that the professional profiles integrate a module on data protection by design and by default [1]. For CISOs running security awareness programmes, this signals an incoming EU-recognised competency framework that will include both professional and general workforce profiles — and that will explicitly cover AI-augmented threats.

What the Opinion does not push back on is equally informative. It welcomes the designation of European Digital Identity Wallet and European Business Wallet providers as essential entities. It supports the anti-ransomware objectives of the NIS2 amendments. It endorses the trusted ICT supply chain framework [1]. Those elements are likely to survive the trilogue intact.

The net signal: the January package will become law with strengthened data protection guardrails, deeper interlock between cybersecurity and GDPR certification, and procedural roles for the EDPB and the EDPS in ENISA’s expanded mandate. Plan accordingly.

Signal Two: The Digital Omnibus on AI Provisional Agreement

In the early hours of 7 May 2026, after a nine-hour trilogue session, the Council and the European Parliament reached a provisional political agreement on the Digital Omnibus on AI [5][6]. The text now requires formal endorsement and legal-linguistic revision, with publication in the Official Journal expected before 2 August 2026 — the date the original high-risk obligations would otherwise apply.

For most CISOs, the agreement immediately changes the AI compliance planning baseline. Five elements deserve close attention.

Application dates for high-risk AI systems are postponed. For Annex III stand-alone high-risk AI systems — covering biometrics, employment, education, credit, law enforcement, justice, migration, critical infrastructure, and essential services — application is deferred by sixteen months, from 2 August 2026 to 2 December 2027. For Annex I systems (AI embedded in products covered by EU sectoral product safety legislation), application is deferred by twelve months, from 2 August 2027 to 2 August 2028 [6][8]. The Commission’s original conditional mechanism, under which application would have been triggered by a Commission decision on standards readiness, has been dropped in favour of fixed dates. The political logic was straightforward: the technical standards and harmonised guidance required for compliance are not yet ready, and businesses cannot be held to standards that do not yet exist.

For CISOs, the 2 December 2027 date is now the operative compliance baseline for the majority of in-scope high-risk AI systems. This is meaningful runway — but it is not a licence to defer. Existing readiness work (classification scoping, governance frameworks, technical documentation) should continue and indeed accelerate, because the postponement is calibrated to the time required to actually implement controls — not to permit further delay in starting.

A new Article 5 prohibition: AI systems generating non-consensual intimate imagery and CSAM. The agreement inserts a new prohibited practice covering AI systems whose primary purpose is to generate child sexual abuse material or non-consensual sexual or intimate content (the so-called “nudifier” prohibition). It applies from 2 December 2026. The drafting reaches beyond purpose-built tools to systems whose functionality renders such misuse reasonably foreseeable — a standard of foreseeability rather than intent [6][7]. In practical terms, providers and deployers of generative image, video and audio systems will need to evidence design-stage and deployment-stage controls, including content filtering, prompt-level safeguards, fine-tuning constraints, and incident response procedures. For CISOs governing internal generative AI use, this is now a board-level reputational and legal exposure question.

Watermarking grace period: compressed, not extended. Article 50(2), which requires providers of generative AI systems to mark synthetic audio, image, video, or text content as machine-readable, retains its 2 August 2026 application date. The agreement introduces a transitional period for providers with systems already on the market before that date — but the period was compressed from the Commission’s proposed six months to three. The effective compliance date for existing generative AI is 2 December 2026. New systems placed on the market or put into service from 2 August 2026 onwards must comply from the date of placement [6]. For CISOs at organisations operating generative AI internally or externally, 2 December 2026 should be read as a hard engineering deadline.

Reinstated obligations. Two obligations that the Commission’s original proposal had relaxed have been restored. First, providers must register high-risk AI systems in the EU database even where they have concluded the system is exempt from high-risk classification. Second, the strict necessity standard for processing special categories of personal data for bias detection and correction is preserved [7][8]. Both reinstatements reflect a Parliament priority that constrained the simplification narrative.

SME privileges extended to small mid-caps. The regulatory privileges available to small and medium-sized enterprises under Article 99 of the AI Act are extended to small mid-cap enterprises (SMCs) — a new category created across multiple Omnibus tracks [6][8]. This mirrors the small mid-cap category introduced in the NIS2 amendments, and signals a coherent EU policy shift toward proportionate regulation for growing companies.

The wider AI Act architecture is intact. GPAI obligations under Articles 50 to 55, in force since 2 August 2025, are not amended. Article 4 AI literacy obligations continue. Governance provisions remain. The deal is recalibration, not relaxation.

Where the Two Signals Converge

These developments are easy to read in isolation. The harder and more useful reading is together. Two observations.

The Brussels machine is moving — but not in one direction. The EDPB and the EDPS are adding obligations and procedural safeguards to the cybersecurity package. The Council and the Parliament are postponing application dates for AI compliance. The first tightens. The second loosens. For CISOs running converged cyber-and-AI governance programmes, the operational implication is that planning baselines need to be updated against two different vectors simultaneously. The 2027–2028 horizon for AI compliance has more runway than the January proposal suggested. The cybersecurity package is on track to become law with more rather than fewer governance hooks than the Commission originally envisaged.

The single-entry point for incident reporting is now the most reliable forward indicator. Both signals — the EDPB/EDPS Opinion and the broader Digital Omnibus track — explicitly back this consolidation. The remaining open question is mechanics and timing. For CISOs, that means incident response infrastructure built for a fragmented reporting landscape (separate NIS2, GDPR, DORA, CER channels) is being engineered for obsolescence. Investment now should be designed for a single-channel future, even if today’s transposed national rules still require parallel reporting.

What CISOs Should Do Now

The combined signal from these two developments points to five concrete actions.

Update your 2027 compliance roadmap to the new AI Act dates. The 2 December 2027 / 2 August 2028 timeline is the new planning baseline. Internal communication should reframe existing AI readiness work as being on the right trajectory rather than ahead of schedule. The risk is board complacency in response to a perceived delay.

Treat 2 December 2026 as a hard engineering deadline for generative AI. Watermarking under Article 50(2) and the new Article 5 prohibition both bite from this date. Foreseeability-of-misuse standards require design-stage and deployment-stage controls evidenced in documentation, not just in policy. Bring AI governance, legal, and security teams together on this milestone now.

Map your data breach reporting against a single-channel future. Design incident response playbooks for a single-entry reporting model even while operating under current parallel obligations. The legislative direction is settled; the timeline is what remains uncertain. The architectural decision is not.

Anticipate stronger EDPB/EDPS roles in cybersecurity certification. If your organisation is planning to rely on the future European cybersecurity certification schemes as a compliance pathway under NIS2, expect those schemes to carry explicit data protection consultation steps and to be calibrated against GDPR security controls. This is good news — it lowers the cost of demonstrating GDPR compliance through a cybersecurity certification — but it means the certification process will not be purely technical.

Refresh board communication. Both signals are board-relevant. The AI Act dates change the urgency framing of AI governance investment. The EDPB/EDPS Opinion changes the governance architecture of certification. A short briefing note that translates these developments into your organisation’s planning baseline avoids the perception — common among non-technical board members — that “Brussels is loosening the rules.”

The Reshape Is the Story

The January 2026 package was not a finished product. It was a Commission proposal that has now passed through two of the three institutional filters that will determine its final form — regulatory consultation and political compromise. Trilogue on the NIS2/CSA2 amendments will follow, with political agreement targeted for early 2027 and full operational impact extending into 2028 and beyond.

For CISOs, the lesson is governance more than it is regulation. The organisations that will struggle are those that read the Commission’s January text as a stable target. The organisations that will benefit are those that have built compliance architecture able to absorb ongoing legislative evolution without losing momentum — those that treat regulatory shaping as a continuous input rather than a one-off event.

The package is changing. The timeline is moving. The architecture is being reshaped before it is enacted. None of this is reason to pause. All of it is reason to plan against the direction of travel, not the original proposal.

References

1. EDPB / EDPS — Joint Opinion 4/2026 on the Proposal for a Cybersecurity Act 2 and the Proposal on amendments to the NIS 2 Directive, adopted 18 March 2026

2. EDPB — Press release: EDPB and EDPS support strengthening EU’s cybersecurity and easing compliance while protecting individuals’ personal data, 19 March 2026

3. European Commission — Proposal for a Directive amending Directive (EU) 2022/2555 (NIS2), COM(2026) 13 final, 20 January 2026

4. European Commission — Proposal for a Regulation on ENISA, the European cybersecurity certification framework, and ICT supply chain security (Cybersecurity Act 2), COM(2026) 11 final, 20 January 2026

5. White & Case — EU agrees Digital Omnibus deal to simplify AI rules, May 2026

6. Bird & Bird — Digital Omnibus on AI: Provisional Agreement Reached at the May Trilogue, May 2026

7. Hogan Lovells — EU legislators agree to delay for high-risk AI rules, May 2026

8. Lexology — EU Digital Omnibus Deal: Simplification of AI Act and Postponed Deadlines, May 2026

9. EDPB / EDPS — Joint Opinion 2/2026 on the Proposal for a Regulation as regards the simplification of the digital legislative framework (Digital Omnibus), adopted 10 February 2026

10. Regulation (EU) 2024/1689 (EU AI Act)

11. Directive (EU) 2022/2555 (NIS2 Directive)

It was not built to function as a regulatory disclosure document.

That distinction mattered less before. Under the January 2026 proposed amendments to NIS2, it matters a great deal.

What the Amendments Actually Require

The proposed amendments introduce a two-tier ransomware disclosure framework for significant incidents affecting NIS2-covered entities.

The first tier is mandatory for all covered entities: standard incident notification timelines remain (24-hour early warning, 72-hour incident report, one-month final report), but the reporting scope now explicitly includes attack vector, detection timeline, and mitigation measures implemented. Ransomware incidents are named as a specific notification category.

The second tier is triggered on request from competent authorities: organisations that paid a ransom must be able to disclose the ransom demand, the amount paid, the payment method, and the recipient — including crypto-wallet details.

The practical implication is this: while the on-request nature of payment disclosure may appear to limit exposure, it does not. Any significant ransomware incident creates the predicate for a payment inquiry. The boundary between "did this happen" and "what did you pay" is now a regulatory decision, not yours.

The Scale of the Problem

According to Sophos's 2025 State of Ransomware report, 37% of organisations affected by ransomware paid the ransom. Verizon's 2025 DBIR corroborates this range. Chainalysis estimates global ransomware payments at approximately $820 million in 2024, with GuidePoint Security noting a 58% increase in victim organisations listed on leak sites.

That 37% figure means a substantial proportion of NIS2-covered entities are making payment decisions that will now sit inside a regulator-accessible disclosure architecture — regardless of whether the payment was successful, partial, or made under legal advice.

The payment decision has always been consequential. Under NIS2, it is also a disclosure event.

The Governance Gap in Your Playbook

Most incident response playbooks address the technical sequence: isolate, assess, recover, report. They often include a legal review step and an insurance notification step. Very few address the following:

Who owns the regulatory disclosure of payment details? This is not a technical question. It requires legal, compliance, and executive alignment — in real time, under pressure.

How does legal privilege interact with NIS2 disclosure obligations? Legal advice obtained during the payment decision process may not be privileged in all disclosure contexts. This requires explicit pre-incident legal mapping, not ad hoc analysis during a live incident.

What is the protocol when a competent authority requests crypto-wallet transaction history? If the payment was made via a third-party negotiator or broker, does the organisation have access to the transaction details? Who retains this data, and for how long?

How does payment disclosure interact with your cyber insurance policy? Some policies restrict or complicate disclosure of payment details. Others require notification before payment. These obligations need to be sequenced, not discovered post-incident.

Has the board been briefed on the regulatory consequences of a payment decision? Under NIS2, management bodies bear explicit responsibility. A board that authorises payment without understanding the disclosure implications is not acting with adequate oversight.

The UK government's parallel legislative thread — the ransomware notification and licensing regime proposed in the Cyber Security and Resilience Bill — adds a further dimension for organisations with UK operations. While still in development, the direction of travel across both EU and UK frameworks is consistent: payment decisions are becoming regulated acts, not private operational choices.

The Core Reframe: A Payment Is Now a Disclosure Event

The traditional framing of the payment decision is: weigh business continuity against ethical and strategic concerns, consult legal counsel, decide.

The NIS2 framework adds a third axis: whatever you decide, that decision — and its financial details — may be subject to regulatory disclosure.

This does not make payment illegal. It does not create a blanket prohibition. What it does is remove the discretion that previously existed around the decision. The confidentiality of the payment — the amount, the method, the recipient — is no longer assured simply because you manage it internally.

Organisations most exposed are those that: operate across multiple NIS2 member states with inconsistent playbooks; use third-party incident response firms without clear contractual data retention obligations; have not mapped the intersection of insurance policy terms and regulatory disclosure requirements; or have boards that treat the payment decision as purely an operational matter rather than a governance one.

Five Operational Actions Your Playbook Needs Now

1. Map payment decisions into your decision authority framework. The payment decision should have a defined owner, a defined escalation path, and a defined documentation standard — before an incident occurs. This is not a gap-fill; it is a governance requirement under NIS2's management accountability provisions.

2. Redesign decision authority for the disclosure context. The individual authorising payment and the individual responsible for regulatory disclosure may not be the same person. Both roles need to be defined, with clear handoff protocols and documentation obligations.

3. Establish legal privilege frameworks pre-incident. Work with legal counsel now to understand which communications during a ransomware incident are potentially disclosable and which may attract privilege. This analysis cannot be done effectively at 2am on day one of an incident.

4. Map your insurance policy against your disclosure obligations. Identify any conflicts between policy notification requirements and NIS2 disclosure timelines. Identify what payment-related data your insurer will require, and ensure you can produce it without conflicting with regulatory obligations.

5. Brief the board — specifically on the regulatory consequences of a payment decision. The NIS2 management liability provisions are explicit. Board members who approve a ransom payment without understanding the disclosure framework are exposed. This briefing should be documented.

The Practical Reality

There are no blanket payment prohibitions in the NIS2 amendments as currently proposed. The debate about whether to prohibit ransomware payments entirely — actively argued in some EU policy circles — has not yet produced legislation. What has emerged is a disclosure framework that fundamentally alters the risk calculus.

The ransom decision is no longer a private operational choice made under pressure with confidentiality largely assured. It is a regulatory event, with documentation requirements, disclosure obligations, and management accountability implications that attach regardless of the outcome.

Your playbook was built for the old model. The amendments describe the new one.

The gap between the two is exactly where your governance exposure lives.

Angelos Varthalitis is the founder of AVSec Advisory. This analysis is for informational purposes and does not constitute legal advice. The NIS2 amendments discussed reflect the January 2026 proposed framework and remain subject to legislative process.

It is also, less visibly, a CISO deadline — even for organisations that manufacture nothing.

Every in-scope NIS2 entity procures products with digital elements. From industrial control systems in energy infrastructure to connected medical devices in hospitals to network equipment in managed service providers, the supply chain that NIS2 Article 21(2)(d) requires CISOs to govern is about to become the object of a parallel regulatory regime operating on a different timeline, through a different reporting platform, to a potentially different CSIRT. The two frameworks were designed to coexist. The operational interfaces between them were not designed jointly.

This article unpacks where NIS2 and the CRA intersect in a CISO’s supply chain programme, five operational ambiguities that the September deadline will surface, and what to do about them before the first dual-reporting incident occurs.

Two Frameworks, One Supply Chain

The conceptual division is clean enough. NIS2 regulates entities — the organisations that operate critical services. The CRA regulates products — the hardware and software placed on the EU market with digital elements.² For the European Commission, this is a coherent framework: organisational resilience on one side, product security on the other.

For the CISO, it is the same supply chain viewed from two regulatory angles. A hospital running CRA-regulated medical devices is both an in-scope NIS2 essential entity and a downstream user of CRA manufacturers. An energy utility deploying grid control systems is both an Article 21 obligation holder and a party dependent on Article 13 manufacturer obligations. A financial institution running NIS2-regulated digital infrastructure is simultaneously a supply chain obligor and a beneficiary of its suppliers’ product-level security controls.

The practical reality is that most organisations now face one cybersecurity supply chain with two regulatory overlays. The governance question is not how to comply with each framework separately. It is how to architect a supply chain programme that operates coherently under both.

Where Article 21 Meets Article 14

The intersection points sit in specific articles that CISOs should read together, not separately.

NIS2 Article 21(2)(d) requires essential and important entities to implement cybersecurity risk management measures covering supply chain security, including “security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” ENISA’s technical implementation guidance, published to support the Commission Implementing Regulation (EU) 2024/2690, expects organisations to maintain a register of in-scope suppliers updated with regular risk management activity, including unscheduled reviews and incident reviews.³

NIS2 Article 21(2)(e) goes further: it requires entities to address “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” This sub-paragraph is the direct operational interface with the CRA. The products that the NIS2 entity acquires are, increasingly, products whose vulnerability handling obligations sit with a CRA-regulated manufacturer.

NIS2 Article 23 establishes the incident reporting timeline for the entity: an early warning within 24 hours of awareness of a significant incident, a detailed notification within 72 hours, and a final report within one month, addressed to the national competent authority or CSIRT.⁴

CRA Article 14 establishes a parallel but structurally different reporting timeline for the manufacturer. Within 24 hours of becoming aware of an actively exploited vulnerability, the manufacturer submits an early warning notification to its designated CSIRT coordinator and simultaneously to ENISA through the Single Reporting Platform. A full vulnerability notification follows within 72 hours, and a final report within 14 days of a corrective measure being made available. For severe incidents affecting product security, the final report is due within one month.⁵

CRA Article 16 establishes the Single Reporting Platform itself, which ENISA will operate from 11 September 2026. The CSIRT initially receiving the notification then disseminates it to CSIRTs in other Member States where the product has been made available.⁶

These regimes were intended to operate in parallel. They were not designed to report to the same point, on the same schedule, about the same incident. That is where the governance gap lives.

Five Operational Ambiguities

1. Dual-channel reporting when one incident straddles both regimes.

Consider a concrete scenario that legal commentators have begun to model: a ransomware exploit of a vulnerability in a connected medical IoT gateway deployed in a hospital. The manufacturer is a CRA-regulated entity. The hospital is a NIS2 essential entity. Staff credentials are affected, triggering GDPR.⁷

Within the first 24 hours, the manufacturer must submit a CRA Article 14 early warning to its designated CSIRT coordinator and to ENISA via the Single Reporting Platform. Simultaneously, the hospital must submit a NIS2 Article 23 early warning to its own national CSIRT. The two notifications may go to different CSIRTs operating under different national transpositions. The Digital Omnibus single incident reporting entry point — which will eventually streamline notifications across NIS2, GDPR, DORA, eIDAS, and the CER Directive — does not currently include the CRA Single Reporting Platform.⁸

The operational consequence is that incidents originating from a product-level vulnerability require two coordinated reporting streams with no EU-level orchestration defined between them. The entity and the manufacturer must each meet their own 24-hour clock independently, and the two clocks start at different moments — the manufacturer’s when it becomes aware of the actively exploited vulnerability, the entity’s when it becomes aware of the significant incident affecting its operations.

2. The contractual timing gap between manufacturer notification and customer notification.

CRA Article 14 obliges the manufacturer to notify the authority within 24 hours. CRA Article 14(8) obliges the manufacturer to inform impacted users “in a timely manner,” without specifying a hard deadline.⁹ If the manufacturer fails to do so, the CSIRT “may” provide information to users where proportionate and necessary.

NIS2 Article 23, by contrast, gives the NIS2 entity 24 hours from its own awareness of a significant incident. But the entity cannot be aware of an incident rooted in a supplier’s product vulnerability until the supplier tells it.

The governance asymmetry is this: the manufacturer’s regulatory obligation runs to the authority before it runs to the customer. The customer’s own regulatory obligation runs in parallel but depends on information flowing from the supplier. Unless the contractual relationship between them explicitly requires sub-24-hour customer notification for actively exploited vulnerabilities, the NIS2 entity can find itself structurally unable to meet its own Article 23 obligation on product-originated incidents — not because it failed to detect or respond, but because its supplier was not contractually required to tell it fast enough.

Most supplier contracts in operation today do not contain this clause. They will need to.

3. Customer notification down the chain.

The problem compounds one layer further. When a NIS2 essential entity becomes aware of a significant incident, Article 23 may require it to inform recipients of its services where appropriate. If the incident originates in a CRA-regulated product, there are now three notification layers operating on three different regulatory logics: the manufacturer notifying the authority and users under CRA Article 14, the NIS2 entity notifying its competent authority under Article 23, and the NIS2 entity notifying its own customers under Article 23.

No EU-level instrument currently defines the orchestration between these three layers. The CISO of a NIS2 entity that sits mid-chain — a managed service provider delivering CRA-regulated products to other NIS2 entities, for example — inherits an orchestration responsibility that the regulations gesture towards but do not specify. The governance architecture must come from the entity itself, drafted into supplier contracts above it and customer contracts below it.

4. The questionnaire flood persists until certification arrives.

The European Commission’s January 2026 amendment proposal explicitly acknowledges that NIS2 supply chain obligations have generated burdensome and inconsistent supplier questionnaires, often cascading down the chain.¹⁰ The proposed solution is certification-based compliance: European cybersecurity certification schemes, including future entity-level cyber-posture certifications, will serve as portable evidence of compliance with Article 21 obligations.

The CRA creates the parallel mechanism on the product side. CRA conformity — CE marking, Software Bill of Materials (SBOM), technical documentation, conformity declarations — is by design portable evidence usable across the single market.¹¹ A NIS2 entity’s supply chain audit of a CRA-regulated supplier should, in principle, be a review of that supplier’s standardised CRA conformity documentation rather than a bespoke questionnaire.

In practice, that “compliance handshake” does not yet exist at scale. The EU cybersecurity certification schemes that the January 2026 proposal anchors on are years from operational reality. Until they arrive, NIS2 entities continue to issue questionnaires and CRA manufacturers continue to respond to them — even though the underlying evidence base is, by regulatory design, converging. Vendor risk management frameworks built around proprietary questionnaire formats today will carry migration costs later. Those architected now to accept portable conformity evidence will compound in value.

5. End-of-life components and the lifecycle asymmetry.

CRA obligations on manufacturers extend throughout a defined “support period” that manufacturers must specify to users, which the regulation expects to reflect the reasonable useful life of the product.¹² NIS2 entity-level obligations have no such sunset. Article 21 measures remain operative as long as the entity operates.

This creates a quiet liability that most CISOs have not yet surfaced. When a CRA-regulated product reaches the end of its declared support period but remains deployed in a NIS2 entity’s operations, the manufacturer’s reporting obligation does not terminate cleanly — it narrows and eventually exits. The vulnerability monitoring obligation, however, does not disappear. It shifts in practice to the NIS2 entity under Article 21(2)(e), which requires vulnerability handling in acquisition and maintenance of systems.

For CISOs currently operating fleets of industrial control systems, connected devices, or embedded software that will age through 2028–2030, the question is whether the in-use inventory has been mapped against anticipated supplier support periods, and whether the decommissioning plan aligns with the regulatory point at which the NIS2 entity inherits full operational responsibility for vulnerability handling.

The Compliance Handshake — Where the Frameworks Help

The picture is not entirely adversarial. The structural direction of travel is towards portable, EU-recognised evidence that reduces the duplicative supervisory burden across jurisdictions.

CRA technical documentation can, architected correctly, feed NIS2 supply chain evidence directly. SBOMs satisfy both NIS2’s vulnerability handling expectations (Article 21(2)(e)) and CRA’s Annex I requirements. Conformity declarations, technical documentation retained for ten years, and CE marking under CRA create standardised artefacts that supplier risk programmes can ingest at scale.¹³ The January 2026 amendment proposal makes this alignment explicit: where a CRA-style certification demonstrates compliance, supervisory authorities will be precluded from subjecting the entity to additional security audits on those matters.

The practical implication for CISOs is that CRA conformity evidence is not only a supplier’s burden — it is the CISO’s future evidence base. Vendor risk frameworks that are redesigned now to accept this evidence in standardised form will capture the efficiency gains as soon as the certification schemes become operational. Those locked into proprietary questionnaire-based assurance will face a migration project later.

What CISOs Should Do Before September

The September 2026 deadline is not a date at which compliance architecture becomes necessary. It is the date at which the absence of that architecture becomes operationally visible.

Map the intersection in your supplier base. Identify which of the products in your current NIS2 compliance scope are also in CRA scope. For most organisations, this is a larger subset than expected — the CRA’s definition of products with digital elements is deliberately broad, covering almost any hardware or software with direct or indirect network connection.¹⁴ The mapping exercise itself surfaces the scale of the interface.

Rewrite supplier contracts to close the notification timing gap. Master service agreements and product purchase contracts with CRA-scope suppliers should explicitly require customer notification of actively exploited vulnerabilities and severe incidents within a window that allows the NIS2 entity to meet its own Article 23 obligation. Sub-24-hour customer notification is not a contractual default. It must be negotiated in, and the negotiation is easier before September, when suppliers’ own programmes are still being designed, than after.

Build an integrated incident response playbook. Incident response plans drafted under NIS2 should be updated to pre-coordinate with the CRA Article 14 reporting flow. This includes identifying which CSIRT is the manufacturer’s designated coordinator, how dissemination from that CSIRT propagates to the entity’s own CSIRT, and where the entity’s own 24-hour clock starts relative to the supplier’s notification. Test the playbook before it is needed.

Align the vendor risk framework to accept CRA conformity evidence. The SBOM, technical documentation, and conformity declaration structures that CRA manufacturers will produce from September onwards should be ingestible by the vendor risk programme without reformatting. This is an architectural choice that the programme owner makes now or later, at different cost points.

Have the conversation with critical suppliers. Ask CRA-scope suppliers directly: are they on track for September readiness, what is their designated CSIRT coordinator, and what contractual notification flows will they support for NIS2-regulated customers. Their answer is a real input to your own risk posture. Their gap becomes your gap.

The Governance Principle

The first generation of NIS2 compliance programmes tested whether organisations could treat cybersecurity as governance rather than a project. The NIS2–CRA interface tests whether they can treat supply chain governance as architecture rather than paperwork.

The organisations that will struggle through autumn 2026 are those whose vendor risk programmes are built as annual questionnaire cycles rather than as continuous evidence pipelines; whose supplier contracts presume a pre-CRA notification regime; whose incident response playbooks assume a single reporting channel; and whose supplier inventory has not yet been mapped against the CRA scope they already rely on.

The organisations that will come through it with structural advantage are those that have recognised a basic governance reality: the regulatory architecture of European cybersecurity is now converging on portable evidence, coordinated reporting, and standardised conformity. The CISOs who build their programmes to that architecture — not to the current patchwork — are building the infrastructure that compounds.

The deadline is September. The governance question is earlier.

References

1. European Commission — CRA Reporting Obligations, accessed April 2026

2. Hyperproof — Understanding the Relationship Between NIS2 and the EU Cyber Resilience Act, February 2026

3. DLA Piper — NIS2 Directive Explained Part 3: Supply Chain Security, December 2025

4. NIS2 Directive (EU) 2022/2555, Article 23

5. Cyber Resilience Act (EU) 2024/2847, Article 14

6. ENISA — Single Reporting Platform (SRP), accessed April 2026

7. CRA vs NIS2 vs GDPR vs EU AI Act — Regulatory Decision Tree, March 2026

8. DLA Piper — NIS2 Directive Explained Part 3: Supply Chain Security, December 2025

9. Cyber Resilience Act (EU) 2024/2847, Article 14(8)

10. IAPP — EU Cybersecurity Reboot: Practical Impacts of the Proposed NIS2 and CSA2 Reforms, March 2026

11. European Commission — Summary of the CRA Legislative Text, December 2025

12. Cycode — The Complete Guide to the Cyber Resilience Act, December 2025

13. Bird & Bird — CRA’s Phased Entry into Application Starts in September 2026, March 2026

14. OpenSSF — EU Cyber Resilience Act, accessed April 2026

The Hidden Provision in the January 2026 Package

The commentary on the European Commission’s January 2026 cybersecurity package has focused, understandably, on the high-visibility changes: the gold-plating ceiling, the certification-as-compliance pathway, the expanded ransomware disclosure obligations. Those are consequential. But buried in COM(2026) 13 is a provision that will define a significant portion of every CISO’s medium-term roadmap — and it has received almost no operational attention.

The proposed new Article 7(2)(k) requires Member States to adopt policies within their national cybersecurity strategies “for the transition to post-quantum cryptography, taking into account the transition timelines and relevant requirements set out in applicable Union legal acts and policies.”^[1] This is not a recital aspiration. It is a named, operative requirement inserted directly into the directive text.

At the same time, Recital (8) of the proposal goes further than any prior EU legislative text in naming the quantum threat explicitly. It identifies ‘harvest now, decrypt later’ attacks as attacks “likely occurring already now”^[2] — a statement that transforms post-quantum readiness from a future-dated risk into a current operational exposure.

For CISOs, the governance implication is immediate: the interpretive gap that previously allowed quantum risk to be deferred on the grounds that ‘NIS2 doesn’t specifically require PQC’ has closed. The proposal eliminates it by name.

What Changed — and What Was Already There

Understanding why Article 7(2)(k) matters requires understanding what existed before it.

NIS2 Article 21(2)(h) already required organisations to establish “policies and procedures relating to the use of cryptography and, where appropriate, encryption.”^[3] The ENISA Technical Implementation Guidance, published in mid-2025, encouraged quantum-safe cryptographic algorithms as part of implementing this requirement.^[4] The EU’s Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, also issued in 2025, established milestones for national transition strategies.^[5]

The legal logic connecting Article 21(2)(h) to PQC was sound but interpretive. It required connecting the directive’s general ‘state-of-the-art’ language to external guidance documents. That argument was defensible — but it was still an argument. COM(2026) 13 converts that argument into a legislative requirement. Once transposed, PQC migration planning is not a CISO’s recommended best practice. It is a named component of national cybersecurity strategy that supervisory authorities will assess.

The broader regulatory context reinforces this. The Cyber Resilience Act, with its key enforcement provisions applying from December 2027, will require products to be designed with cryptographic agility — the capacity to update cryptographic mechanisms as threats evolve.^[6] eIDAS 2.0 drives digital identity wallet rollout across PKI-heavy infrastructure that carries some of the longest cryptographic migration lead times in any enterprise.^[7] The Commission is not building a single PQC mandate — it is assembling an interlocking framework across NIS2, CRA, and eIDAS simultaneously.

The Threat That Doesn’t Wait for Regulation

Harvest now, decrypt later is not a theoretical attack pattern. It is an active data collection strategy. Adversaries — primarily nation-state actors — are already exfiltrating encrypted data at scale on the assumption that a cryptographically relevant quantum computer will eventually be available to decrypt it. The value of the data determines the attack horizon: government communications, long-lived intellectual property, financial records, critical infrastructure configuration data.

The EU PQC Roadmap is explicit about the timeline exposure. By the end of 2030, critical infrastructure should have transitioned to quantum-resistant algorithms for high-risk use cases — specifically those where “data confidentiality must be protected for over ten years.”^[8] That ten-year window, measured backwards from 2030, reaches 2020. Encrypted data captured since 2020 is, on this model, potentially in scope.

NIST published the first post-quantum cryptography standards — ML-KEM, ML-DSA, and SLH-DSA — in August 2024.^[9] Those standards are available now. The migration is not waiting for mathematical readiness. It is waiting for organisational will.

The EU Timeline and What It Means Operationally

The EU PQC roadmap establishes three milestones that CISOs should be building into governance frameworks today:

• End of 2026: Member States should initiate national PQC transition strategies. Organisations in NIS2 scope should treat this as a signal that supervisory enquiries on cryptographic readiness are forthcoming.

• End of 2030: Critical infrastructure entities should have completed transition for high-risk use cases. This is the operative planning deadline for most essential entities.

• End of 2035: Complete transition for as many systems as practically feasible. This is the long tail — legacy systems, low-criticality infrastructure, complex multi-party dependencies.

The 2030 milestone is the operationally significant one. At typical enterprise migration velocity, organisations that do not begin cryptographic inventories in 2025–2026 will not complete high-risk migrations by 2030. PKI infrastructure, in particular, has some of the longest transition lead times of any enterprise cryptographic dependency — certificates, trust chains, and identity infrastructure cannot be migrated in a single programme cycle.

The Article 7(2)(k) requirement adds a governance layer to this timeline. When the Commission’s implementing acts under Article 21(5) arrive — setting harmonised technical requirements — they are highly likely to reference PQC readiness directly, given that the proposal explicitly tasks Member States with PQC transition planning. CISOs who have not begun that planning will find themselves defending gaps to supervisory authorities who are, by then, operating against a regulatory framework that explicitly anticipated it.

What CISOs Should Do Now

The Article 7(2)(k) requirement is proposed, not yet enacted. Member States have not yet transposed it. But the operational steps it points toward are not dependent on transposition — they are risk-management actions that are independently justified by the threat landscape and the existing Article 21 obligations. The regulation provides governance cover for actions CISOs should be taking regardless.

1. Commission a cryptographic inventory

The foundational action. Organisations cannot plan a PQC migration without knowing where RSA, ECC, and other classically vulnerable algorithms currently live. This means mapping keys, certificates, algorithms, and protocols across cloud, hybrid, and on-premises environments — including those embedded in vendor software and third-party components. A Cryptography Bill of Materials (CBOM) extends the SBOM concept to capture algorithm-level dependencies, not just component-level ones.^[10] This is the step that organisations consistently underestimate.

2. Classify assets by confidentiality lifespan

Not all encrypted data carries the same quantum exposure. Crown-jewel data with a confidentiality requirement extending beyond 2030 is already in the harvest-now window on the EU roadmap’s model. That data — and the systems protecting it — should be the first priority for PQC migration planning, irrespective of broader programme timelines.

3. Map cryptographic risk to Article 21(2)(h) obligations

The existing NIS2 requirement for cryptography policies is the operative hook for supervisory engagement today. CISOs should review whether current policy documentation under Article 21(2)(h) addresses quantum risk — even in general terms. A documented risk acceptance position, grounded in the EU PQC roadmap timeline, is significantly stronger than silence. Supervisory authorities will ask; having a documented position is the difference between a governance programme and an audit finding.

4. Engage procurement on cryptographic agility

The Cyber Resilience Act will, from December 2027, impose cryptographic agility requirements on products entering the EU market. Organisations that are currently procuring or renewing technology contracts should be including cryptographic agility requirements in procurement specifications now — particularly for long-lived infrastructure, PKI-dependent systems, and any technology with update mechanisms. This is not a future compliance action; it is a current procurement governance requirement.

5. Bring quantum risk to the board

The Article 7(2)(k) proposal, and Recital (8)’s explicit naming of harvest-now-decrypt-later as “likely occurring already now,” provides CISOs with primary regulatory source material for a board briefing. Quantum risk has typically been positioned as a 2030-era concern. The EU is, in this proposal, explicitly disputing that framing. The board should understand that data captured today under current encryption may be decryptable in a regulatory and threat environment that already anticipates this — and that NIS2 obligations are beginning to name the required response.

The Governance Dimension

There is a pattern in EU cybersecurity regulation that CISOs have seen repeatedly: a risk category moves from industry best practice to regulatory expectation to enforcement surface, often faster than compliance programmes can absorb the shift. Supply chain security followed this trajectory. Non-human identities are following it now. Post-quantum cryptography is next.

The organisations that manage this transition well will not be those that waited for the implementing acts and then launched a crash programme. They will be those that treated the proposed Article 7(2)(k) — and the existing Article 21(2)(h) — as a governance signal to begin the inventory, classification, and planning work that a structured migration requires.

The transition to post-quantum cryptography is not primarily a cryptography project. It is an enterprise risk governance programme. It requires asset classification, vendor engagement, procurement policy, board awareness, and incident response planning — all of which fall squarely within the CISO’s remit regardless of where the regulatory text sits on its transposition timeline.

The regulation is telling you where the threat is heading. The threat is already there.

References

[1] European Commission, COM(2026) 13 final — Proposal for a Directive amending NIS2 (January 2026)

[2] Ibid., Recital (8)

[3] Directive (EU) 2022/2555 (NIS2), Article 21(2)(h)

[4] ENISA, Technical Implementation Guidance for NIS2 (2025)

[5] NIS Cooperation Group, Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (June 2025)

[6] Regulation (EU) 2024/2847 (Cyber Resilience Act), enforcement provisions from December 2027

[7] Regulation (EU) 2024/1183 (eIDAS 2.0) — European Digital Identity framework

[8] NIS Cooperation Group, Coordinated Implementation Roadmap for PQC, milestone end-2030

[9] NIST Post-Quantum Cryptography Standards (ML-KEM, ML-DSA, SLH-DSA), August 2024

[10] SCANOSS — NIS2 and Cryptography Bills of Materials (CBOM) (April 2026)

On April 7th, Anthropic released Claude Mythos Preview — a model that discovered thousands of zero-day vulnerabilities across every major operating system and web browser, some of which had gone undetected for up to 27 years. The model created working exploits on the first attempt in 83% of cases.

Anthropic decided not to release it publicly. Instead, access was granted to approximately 40 organizations — primarily major tech companies like AWS, Microsoft, Google, CrowdStrike, and Palo Alto Networks — through an initiative called Project Glasswing, backed by $100 million in usage credits.

It’s worth noting that these 40 organizations are among the most well-resourced in the world. They have security teams numbering in the hundreds or thousands, budgets in the billions, and some of them are cybersecurity companies themselves. They are, by definition, the organizations that needed this tool the least to survive. The rest of us — hospitals, energy providers, SaaS companies, transport operators — defend critical infrastructure with a fraction of those resources.

This is not a criticism of that decision. The safety concerns are real. But it raises questions that every CISO in Europe should be thinking about right now.

The Timeline Problem

Anthropic’s own researchers estimate that comparable AI capabilities will emerge from other labs within 6 to 18 months — potentially through open-source models. That means the ability to discover and exploit vulnerabilities at machine speed will eventually be available to threat actors, while the majority of defenders worldwide currently have no access to equivalent defensive tools.

For CISOs managing critical infrastructure, healthcare systems, SaaS platforms, or any organization under NIS2, this creates a planning challenge: how do you prepare for a threat landscape where attackers can find decades-old vulnerabilities in minutes?

The NIS2 Angle

Article 21 of the NIS2 Directive requires essential and important entities to implement security measures reflecting the “state of the art.” If AI-powered vulnerability discovery is becoming the new standard, there is a growing gap between what regulations expect and what most organizations can access.

This isn’t about blame — it’s about readiness. National cybersecurity authorities and ENISA should be engaging with this question now, not after the first wave of AI-augmented incidents.

What CISOs Can Do Today

Even without access to Mythos-class tools, the fundamentals become more urgent:

Accelerate patching cycles, especially for open-source components. The vulnerabilities Mythos found were in widely used software — Linux kernel, OpenBSD, FFmpeg, major browsers. If your infrastructure depends on these (and it almost certainly does), your patching window just got shorter.

Review your asset inventory with a focus on open-source dependencies. Know exactly what you’re running and where your exposure is.

Reduce your attack surface. Every unnecessary service, every unpatched legacy system, every forgotten endpoint is a potential entry point for an attacker armed with AI-powered exploit discovery.

Invest in detection and response. When prevention alone isn’t enough, your ability to detect and contain a breach becomes critical.

The Bigger Picture

Mythos is a signal, not an isolated event. Every major AI lab is pursuing the same improvements in reasoning and code capability that gave Mythos its cybersecurity edge. This is the direction of the industry.

The security community — through organizations like the Cloud Security Alliance, ENISA, and national authorities — should be exploring how to ensure that defenders at all levels get access to AI-powered defensive capabilities, not just the largest players.

The question for 2026 is no longer whether AI changes cybersecurity. It’s who defends the defenders — and whether they’ll have the tools to keep pace.

On 25 February 2026, three committees of the European Parliament voted to push back against one of the more consequential definitions in the January 2026 NIS2 amendment package. The Commission had proposed classifying entities with fewer than 750 employees and annual turnover of up to €150 million as a new ‘small mid-cap’ category — shifting them from essential to important status, and with it, from proactive supervisory scrutiny to reactive enforcement.^[1]

The Parliament wants that threshold raised. Fewer than 1,000 employees. Turnover up to €200 million. Balance sheet up to €172 million.^[2]

The gap between the two positions is not a rounding error. It is the difference between tens of thousands of organisations being subject to full essential entity obligations — including mandatory ex ante audits, the highest fine ceilings, and personal management liability — and operating under the lighter-touch important entity regime.

For CISOs at organisations near any of these thresholds, the message is straightforward: a compliance classification that feels settled today may not be settled at all. And the governance response to that uncertainty is not to wait.

What the Commission Proposed — and Why It Matters

The January 2026 amendment package introduced the ‘small mid-cap’ category for the first time in NIS2’s scope architecture. Under the Commission proposal, qualifying entities — fewer than 750 employees, turnover ≤ €150 million or balance sheet ≤ €129 million — operating in NIS2-covered sectors would, as a main rule, be classified as important rather than essential.^[3]

That reclassification has direct operational implications. Under NIS2, essential and important entities share the same Article 21 risk-management obligations. But the supervisory architecture is fundamentally different. Essential entities face ex ante oversight: regular audits, proactive inspections, ongoing supervisory engagement. Important entities are generally supervised ex post, meaning authorities intervene primarily when incidents occur or non-compliance is evidenced. Fine ceilings are also higher for essential entities: up to €10 million or 2% of global turnover, versus €7 million or 1.4% for important entities.^[4]

The Commission estimates that the small mid-cap category as drafted would ease compliance for approximately 22,500 companies across the EU.^[5]

Parliament Pushes the Ceiling Higher — Significantly

The Parliament committees’ February 2026 position would expand that number considerably. By raising the employee threshold from 750 to 1,000, and the turnover ceiling from €150 million to €200 million, the Parliament is proposing to reclassify a substantially larger population of entities from essential to important.^[6]

The logic behind the Parliament’s position reflects a consistent concern in the simplification debate: that the Commission’s definition of ‘small mid-cap’ maps too closely onto existing SME definitions and leaves a large cohort of mid-sized businesses — operationally significant, but not large by EU standards — subject to supervision intensity calibrated for major critical infrastructure operators.

The Parliament also specified that the thresholds should be reviewed every five years, and that SME support should not be diluted in the process.^[7]

Neither position is final. The proposal now enters trilogue negotiations between the Commission, Parliament, and Council, with political agreement targeted for early 2027. The final threshold could land anywhere between the two positions — or be modified further during negotiation. That is precisely what makes the current period operationally hazardous for CISOs who treat NIS2 classification as a fixed input.

Essential vs Important Is Not Just a Label

The governance significance of the essential/important distinction is sometimes underestimated in compliance programme design. Classification is treated as a scoping question resolved at programme initiation and then set aside. In a stable regulatory environment, that approach is defensible. In the current environment, it is not.

Consider the practical exposure for a critical sector organisation currently sitting at 820 employees and €160 million in annual turnover. Under the Commission proposal, it would qualify as a small mid-cap and shift to important status. Under the Parliament’s proposed threshold, it would remain essential. If the trilogue outcome lands anywhere between the two positions, the organisation could be reclassified in either direction depending on the final text — and the compliance obligations attached to that classification would change accordingly.

That uncertainty has immediate governance implications. Boards that have been briefed on a specific supervisory profile need to be aware that the profile is not yet fixed. CISOs managing audit exposure, documentation requirements, and incident response obligations calibrated to essential entity standards need to design compliance architecture that can absorb reclassification without requiring a programme rebuild. And management bodies operating under the assumption that personal liability provisions apply — or do not apply — based on current classification may need to revisit that assumption when the final text is adopted.

The Supply Chain Ripple Effect

The threshold debate also has a less obvious but equally significant implication for supply chain governance. NIS2 imposes explicit supply chain security obligations on essential entities: they must assess and manage the cybersecurity risks posed by their suppliers and service providers.

When a supplier is reclassified from essential to important, its supervisory intensity decreases. It faces less frequent audits, less proactive regulatory scrutiny, and — in the event of non-compliance — lower fine exposure. That reduction in regulatory pressure does not necessarily translate into a reduction in risk. It may simply mean that the risk becomes less visible to regulators.

For essential entities that rely on mid-sized suppliers currently sitting near the reclassification thresholds, this matters. A supplier that moves from essential to important under the amended framework may face reduced incentive to maintain documentation, audit trails, and incident response capabilities at the level previously expected. The essential entity receiving services from that supplier retains its own Article 21 supply chain obligations regardless of how the supplier is classified.

CISOs managing vendor risk programmes should be mapping which of their key suppliers sit near the relevant thresholds now — before the final text is adopted — and assessing what reclassification would mean for the assurance those suppliers provide.

What CISOs Should Do Before the Trilogue Concludes

The instinct in a period of regulatory uncertainty is to pause investment and wait for clarity. That instinct is understandable. It is also the wrong response.

Article 21 obligations apply in full under current national transpositions, regardless of how the small mid-cap debate resolves. Enforcement is active and accelerating across Member States through 2026. The reclassification discussion is a future-state variable; the compliance obligations attached to current classification are operative now.

Within that context, four actions are immediately relevant:

• Map your classification threshold exposure. Identify whether your organisation — or any subsidiary or affiliate — sits within a plausible range of the competing threshold proposals. Document the analysis. If the final text shifts your classification, the governance response should be a structured reassessment, not an emergency exercise.

• Design compliance architecture for portability. The core Article 21 control framework applies equally to essential and important entities. Build your compliance evidence pack, documentation structure, and audit trail to the essential entity standard regardless of which classification you hold. If you are reclassified to important, the compliance overhead decreases but the evidence remains usable. If you remain essential, you have not over-invested.

• Reassess your vendor risk framework through the reclassification lens. Identify suppliers near the threshold thresholds. Update your supply chain assurance model to account for the possibility that key suppliers’ supervisory profiles may shift. Move toward certification-based assurance where possible — the amendment package’s broader push toward EU-level cybersecurity certification schemes is directly relevant here.

• Brief the board accurately. The ‘simplification is coming’ narrative will reach boardrooms before the nuance does. CISOs need to be ahead of that conversation. The governance message is consistent: current obligations apply in full; classification certainty will not exist until 2027 at the earliest; and the correct response to that uncertainty is programme maturity, not deferral.

The Broader Governance Signal

The threshold debate between the Commission and the Parliament is, at one level, a technical legislative negotiation. At another level, it is a symptom of a wider problem: NIS2 is a compliance framework that arrived before the regulatory architecture supporting it was complete, and which is now being refined mid-implementation.

That dynamic is not unique to NIS2. It is characteristic of the current phase of EU digital regulation more broadly. CISOs who have spent the last two years treating NIS2 as a point-in-time implementation project — with a defined scope, a defined classification, and a defined endpoint — are discovering that the framework does not stay still long enough for that model to work.

The organisations that will navigate this period most effectively are those that have built compliance as an operational capability rather than a project: adaptive, evidence-based, and embedded in governance rather than delegated to a programme team. Whether the threshold lands at 750, 1,000, or somewhere in between, that capability will be the difference between reclassification as a managed transition and reclassification as a disruption.

The threshold is still being negotiated. Your compliance programme should not be.

References

[1] Global Regulation Tomorrow — European Parliament committees endorse proposals for simplified rules for small ‘mid-cap’ companies (25 February 2026)

[2] Ibid.

[3] Morrison Foerster — Easing the NIS2 Burden: Targeted Reforms to Europe’s Cybersecurity Rules (March 2026)

[4] DLA Piper — NIS2 Update: EU Moves to Harmonise Cyber Controls (February 2026)

[5] IAPP — EU Cybersecurity Reboot: Practical Impacts of the Proposed NIS2 and CSA2 Reforms (March 2026)

[6] Global Policy Watch — European Commission Proposes Targeted Amendments to NIS2 (January 2026)

[7] Global Regulation Tomorrow — European Parliament committees endorse proposals (February 2026

)

“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.