What Europe Can Learn from Ukraine’s Cybersecurity Experience

Complex law. Clear action.

Reviewed by Oleksandr Sobovyi, Founder & CEO of CORVUS AI — editorial responsibility statement below.

Today, I am attending Cybersecurity Lessons from Ukraine, an event organised by the Netherlands Cybersecurity Coordination Centre (NCC-NL) in The Hague, with the involvement of the Netherlands Enterprise Agency (RVO).

This event is particularly meaningful to me. I previously served as Director of the Legal Department of the Ministry of Defence of Ukraine. Today, working in the Netherlands in the field of European law and regulation, I look at Ukraine’s cybersecurity experience from two perspectives: as a set of practical responses to real threats and as a collection of methods that need to be properly integrated into the European legal and regulatory framework.

Ukrainian specialists have developed unique experience in protecting digital infrastructure during a full-scale war. However, a method that proves effective in responding to a cyberattack cannot always be transferred unchanged to a Dutch company.

My central question today is: how can European organisations benefit from proven Ukrainian practices without creating new criminal-law, regulatory or contractual risks?

Four Areas of Ukrainian Experience

The official NCC-NL programme includes four practical workshops, organised across two rounds:

• Investigate, Decide, Respond — real-time digital forensics and incident response (DFIR).

• From Infostealer Logs to Actionable CTI — using data stolen by malicious software to identify compromised access at an early stage.

• Digital Forensics Under Pressure — reconstructing a real cybersecurity incident in Ukraine.

• Breaking AI Systems — offensive security testing of AI systems.

Each area offers practical value. For European businesses, however, that value depends on more than technical effectiveness. The legality of access to information, allocation of responsibility, evidential reliability of findings and compliance with regulatory obligations are equally important.

1. Infostealer Logs: When Threat Intelligence Meets Criminal Law

One of the subjects I find particularly interesting is the use of infostealer logs in cyber threat intelligence (CTI).

Infostealers extract passwords, cookies, access tokens and other data from infected devices. Detecting such information may allow an organisation to block compromised accounts before attackers exploit them to launch further attacks.

From a technical perspective, the advantages are clear. From a legal perspective, the situation is more complicated.

In the Netherlands, Article 139g of the Dutch Criminal Code (Wetboek van Strafrecht), introduced through the Computercriminaliteit III legislation, establishes criminal liability for certain activities involving non-public data obtained through criminal offences.

The provision covers, among other things, acquiring or possessing such data where the statutory knowledge requirement concerning their criminal origin is met. It also separately regulates the transfer and disclosure of such data, as well as possession or use for financial gain.

An exception exists where a person reasonably and in good faith believes that the relevant conduct is necessary in the public interest. However, a company's commercial interest in protecting its own cybersecurity does not automatically mean that this exception applies.

I would therefore distinguish between three situations:

1. A company receives an alert that its accounts have been compromised.

2. A company receives extracts of stolen data from a CTI provider.

3. A company independently purchases complete datasets from criminal marketplaces.

These models present different legal risk profiles.

My conclusion: where indicators are sufficient to protect an organisation's infrastructure, it is preferable to obtain verified indicators of compromise without acquiring the underlying stolen datasets.

At the same time, engaging an external CTI provider does not automatically release the client from liability. The origin of the data, contractual arrangements, actual conduct of the parties and lawfulness of processing must all be assessed.

GDPR: An Additional Layer of Responsibility

Where information can identify an individual, its processing must comply with the General Data Protection Regulation (GDPR).

For a private company, legitimate interests under Article 6(1)(f) GDPR may provide a legal basis. Recital 49 expressly recognises network and information security as a potential legitimate interest.

However, this requires an assessment of the necessity and proportionality of the processing, the interests of data subjects, access restrictions, retention periods and, where applicable, appropriate arrangements with service providers.

It is particularly important to determine when information received from a CTI provider triggers an investigation into a possible personal data breach.

Under Article 33 GDPR, a supervisory authority must be notified without undue delay and, where feasible, within 72 hours after the controller becomes aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals.

The discovery of a stolen password does not automatically mean that a reportable GDPR breach has occurred within the organisation concerned. However, such a finding may require immediate investigation. The reporting period depends on actual awareness of the breach, rather than the date on which management receives a formal report.

The European Data Protection Board's Guidelines 9/2022 on personal data breach notification provide further guidance on when a controller can be considered aware of a breach.

For me, this leads to an important practical conclusion: threat monitoring must be linked to a pre-established procedure for the legal classification of incidents.

2. Incident Response: Why Management Decisions Become Evidence

Ukraine's experience in responding to cyberattacks under conditions of continuous threat is particularly relevant to organisations operating critical infrastructure.

In the Netherlands, however, this experience must be considered within the context of the new legislation.

The Cyberbeveiligingswet (Cbw), which implements the provisions of the NIS2 Directive (Directive (EU) 2022/2555), has been in force since 15 August 2026.

For organisations within the scope of the legislation, this creates obligations relating to cybersecurity risk management, registration, notification of significant incidents and the responsibility of management bodies.

Article 20 NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures and establishes requirements for their training.

Article 23 provides for a multi-stage notification procedure for significant incidents, including an early warning within 24 hours, an incident notification within 72 hours and a final report, generally no later than one month after submission of the incident notification. The specific recipients and significance criteria must be determined under Dutch legislation and the applicable sector-specific rules.

This changes the nature of management accountability.

Following a serious incident, the sequence of management decisions becomes as important as the technical reconstruction of the attack:

• When did the organisation become aware of the compromise?

• Who assessed its scale and consequences?

• Which measures were approved?

• When did the notification obligation arise?

• What documentary evidence supports the decisions taken?

I believe European companies should adopt, above all, the discipline of rapid decision-making developed through Ukrainian operational experience, while ensuring that these decisions are properly documented.

A Separate Issue: Confidentiality of Forensic Investigations

A forensic report may subsequently attract the attention of regulators, insurers, contractual counterparties or courts.

Its preparation should therefore be structured in advance.

In the Netherlands, professional confidentiality and verschoningsrecht do not arise automatically simply because a legal adviser has been engaged. Certain materials connected with legal assistance provided by an advocate (advocaat) may benefit from specific protection, but its existence and scope depend on the circumstances.

Accordingly, organisations should determine the status of external advisers, the arrangements for commissioning investigations, access to materials and evidence-preservation procedures before an incident occurs.

The Dutch Public Prosecution Service's Aanwijzing waarborgen professioneel verschoningsrecht provides relevant guidance on professional legal privilege.

My practical conclusion: the contractual and legal framework for an investigation should be established before a serious cyberattack takes place.

3. Breaking AI Systems: AI Cybersecurity Is Becoming a Legal Obligation

The offensive security testing of AI systems is particularly relevant to CORVUS AI's work.

For European manufacturers and providers of AI systems, this is no longer solely a matter of voluntary technical recommendations.

At least two regulatory regimes must be distinguished.

AI Act

Article 55(1)(a) of Regulation (EU) 2024/1689 expressly requires providers of general-purpose AI models with systemic risk to perform model evaluation, including conducting and documenting adversarial testing.

For high-risk AI systems, Article 15 establishes requirements concerning accuracy, robustness and cybersecurity, including protection against certain types of attack.

Following the adoption of Regulation (EU) 2026/1744 — Digital Omnibus on AI, the application dates for the relevant high-risk AI requirements were postponed:

• 2 December 2027 — for systems classified under Article 6(2) and Annex III.

• 2 August 2028 — for systems classified under Article 6(1) and Annex I.

This postponement does not automatically extend to other obligations under the AI Act that are already applicable.

Cyber Resilience Act

Products with digital elements falling within the scope of Regulation (EU) 2024/2847 — the Cyber Resilience Act (CRA)are subject to a separate regulatory regime.

Since 11 September 2026, manufacturers have been subject to obligations under Article 14 CRA to notify actively exploited vulnerabilities and severe incidents affecting the security of products.

However, discovering a weakness during authorised red-teaming does not, in itself, establish the existence of an actively exploited vulnerability. Such a classification requires reliable evidence of unauthorised exploitation by a malicious actor.

Manufacturers must distinguish between an identified vulnerability, confirmed exploitation and an incident that triggers a notification obligation.

The European Commission's guidance on CRA reporting provides further information on these obligations.

My position: AI security testing results should be integrated into a single, legally sound vulnerability and incident management process. At the same time, it should not be assumed that every AI component automatically brings a product within the scope of the CRA. The scope of the Regulation and possible exclusions must first be assessed.

4. Ukrainian Military Experience and the European Market: Limits on Transferring Practices

In my view, this is the most important issue for Ukrainian–European technological cooperation.

A substantial part of Ukraine's cybersecurity experience has been developed within government and military organisations carrying out national security and defence functions.

Their powers, the legal regime governing information and the methods of counteraction available to them are not identical to those applicable to private companies in the Netherlands.

This distinction is particularly important for dual-use technologies.

For example, Article 2(3) of the AI Act provides exclusions for systems used exclusively for military, defence or national security purposes, subject to the conditions established by the Regulation.

The Cyber Resilience Act also contains specific exclusions, including for certain products developed or modified exclusively for national security or defence purposes.

NIS2 establishes its own limitations on scope and specific rules.

These exclusions, however, differ in their conditions and do not automatically cover all activities of a defence company.

Where a Ukrainian developer adapts military technology for the European civilian market, it is necessary to assess separately:

• The applicability of the AI Act, CRA, GDPR and national cybersecurity legislation.

• Rights to technologies, source code and the results of joint development.

• Export controls and possible restrictions on transferring technical information.

• Allocation of contractual liability between partners.

• Cybersecurity requirements and access to critical infrastructure.

It is particularly important that joint development agreements address rights of use, transfer of technical documentation, incident response, confidentiality and allocation of liability.

The Dutch Government is already using a consortium-based model to support this cooperation. One example is the Netherlands–Ukraine Cybersecurity Grant 2026 (NL-UA CF), coordinated by NCC-NL, with a total budget of €2.5 million. Applications for that round closed on 29 April 2026.

Such mechanisms demonstrate how the exchange of experience can develop into joint practical projects. However, participation in a programme does not replace the need to verify technology rights, eligibility requirements and applicable legislation.

5. What I Recommend to European Companies

Based on my legal analysis of the subjects addressed at today's event, I would identify five practical actions.

First — verify the sources of cyber threat intelligence. Organisations need to understand what data they receive, how it was collected, who can access it and which legal risks arise from its processing.

Second — connect technical incident response with legal classification. Security operations centres, cybersecurity specialists, data protection officers and management should apply agreed criteria for identifying incidents and determining notification obligations under the Cbw, NIS2, GDPR and, where applicable, the CRA.

Third — ensure that management decisions can be evidenced. Decisions concerning escalation, incident response, notifications and system recovery should be documented promptly and remain available for subsequent review.

Fourth — consider the regulatory consequences of AI security testing. Security assessments should be accompanied by an analysis of the applicability of the AI Act and CRA, vulnerability classification and documentation of corrective measures.

Fifth — establish a sound legal framework for cooperation with Ukrainian developers. Before sharing source code, technical documentation or access to systems, the parties should address intellectual property, confidentiality, export controls, cybersecurity and contractual liability.

Conclusion

Today's meeting in The Hague is important because it provides a platform for direct exchanges between Ukrainian specialists working under wartime conditions and the European professional community.

For me, as a former head of the Legal Department of Ukraine's Ministry of Defence and the founder of CORVUS AI, a Netherlands-based legal and regulatory advisory practice, it is particularly important that such exchanges lead to practical results.

Ukraine's experience can strengthen Europe's cyber resilience. But transferring technical methods alone is not enough. They must be adapted to the legal requirements, contractual environment and accountability framework of the European market.

Effective cybersecurity and legal certainty should reinforce each other.

I see this as one of the most promising areas of technological and legal cooperation between Ukraine and the Netherlands.

Disclaimer

This article has been prepared by CORVUS AI for general informational and educational purposes only. It is intended to make complex legal and regulatory developments easier to understand.

It does not constitute legal advice and does not create a professional adviser–client relationship. The information should not be relied upon as a substitute for advice based on the specific facts, circumstances and applicable law relevant to your organisation or project.

The article reflects our understanding of the law and regulatory framework as of the date of publication. Legislation, case law, regulatory guidance and administrative practice may subsequently change. While reasonable care has been taken in preparing this article, CORVUS AI does not warrant that the information is complete or remains current after the date of publication. We do not undertake to update this content.

To the fullest extent permitted by applicable law, CORVUS AI excludes liability for loss arising from reliance on this article. Nothing in this article constitutes an offer or solicitation to provide regulated legal services in any jurisdiction where doing so would be unlawful.

AI-assisted preparation: This article was prepared with the assistance of AI tools. Its legal analysis, conclusions and final text were subject to human review and editorial control and were reviewed and approved prior to publication by Oleksandr Sobovyi, Founder & CEO of CORVUS AI. CORVUS AI retains editorial responsibility for the published content.

For advice tailored to your organisation, project or specific circumstances, please contact CORVUS AI.

Oleksandr Sobovyi
Founder & CEO, CORVUS AI
EU Legal & Regulatory Advisory
The Netherlands

www.corvusai.eu

Legal analysis prepared as of 10 November 2026. This article is based on the official NCC-NL programme and applicable EU and Dutch legislation. It is not a verbatim account of statements made by participants at the event.

Editorial responsibility: This article was prepared with AI assistance and is intended for publication following human legal review and editorial approval by the author. It is provided for general information and does not constitute legal advice.