
In October 2024, the European Union is moving to a new stage of cybersecurity regulation for critical organizations and digital infrastructure. Directive NIS2 expands the scope of covered sectors, strengthens requirements for risk management, management responsibility, supply chain protection, and reporting of significant cyber incidents. For Ukrainian IT companies, integrators, cloud providers, and corporate customers, this creates new requirements for infrastructure documentation, access control, backup, and information resource management.
October 2024: European Union Strengthens Cybersecurity Regulation
On October 17, 2024, the deadline set by Directive NIS2 expired, during which EU member states were required to adopt and publish the necessary national measures for its implementation.
From October 18, the relevant national norms were to begin applying according to the schedule foreseen by the directive.
NIS2 – EU Directive 2022/2555, adopted on December 14, 2022 – replaces the previous NIS Directive of 2016 and forms a broader system for ensuring the cybersecurity of critical and important sectors of the economy.
The new approach covers not only traditional critical infrastructure but also a significant portion of digital services, data centers, cloud providers, and managed IT service providers.
On October 17, the European Commission also adopted an implementing regulation that clarifies the technical and methodological requirements for defined categories of digital providers.
It was published on October 18 as Regulation (EU) 2024/2690. The document concerns, among others, cloud computing providers, data centers, DNS, CDNs, managed IT services, and managed security services.
For corporate IT, these changes are of strategic importance.
Cybersecurity is increasingly viewed not as a collection of technical protection measures, but as a formalized system of risk management, responsibility, and business continuity.
However, there is an important legal nuance. The expiry of the NIS2 transposition period does not mean that all EU member states have simultaneously completed its transposition into national law.
As of October 2024, the actual state of implementation varies between countries. In particular, in Germany, the completion of the legislative procedure is delayed, which is important for determining the specific national obligations of enterprises.
Therefore, companies must check not only the text of the directive but also the current legislation of the respective country.
This is particularly important for Ukrainian suppliers, as cooperation with a European client may create cybersecurity contractual requirements, even if the Ukrainian company itself is not the direct addressee of NIS2.
2. How NIS2 Differs from the Previous Directive
The previous NIS directive laid the foundation for regulating the security of network and information systems in defined critical sectors.
However, the development of digital technologies, increased reliance of businesses on external IT providers, and the growing number of cyberattacks have demonstrated the need for a broader approach.
NIS2 strengthens requirements in several areas.
Firstly, the list of covered sectors is expanded.
Secondly, a clearer distinction is introduced between essential entities and important entities.
Thirdly, the role of governing bodies in cybersecurity oversight is strengthened.
Fourthly, more attention is paid to the risk management of suppliers.
Fifthly, the procedures for reporting significant incidents are detailed.
Comparison
| Characteristic | NIS 2016 | NIS2 |
|---|---|---|
| Sectoral Coverage | Narrower | Expanded |
| Organization Classification | Operators of essential services and digital providers | Essential and Important Entities |
| Risk Management | General requirements | More detailed list of measures |
| Management Responsibility | Less detailed | Directly strengthened |
| Supply Chains | Less emphasis | Separate focus |
| Incident Reporting | Depending on the regime | Multi-stage procedure |
| Supervision | Less unified | Strengthened and differentiated |
However, the categories of essential and important do not mean that all organizations in the relevant sector automatically have the same obligations.
It is necessary to assess the size of the company, the type of activity, legal criteria, and specific provisions of the directive and national legislation.
3. Which companies may fall under NIS2
The directive covers a number of sectors listed in Annexes I and II.
Sectors of high criticality include energy, transport, banking, financial market infrastructure, healthcare, drinking water, wastewater, digital infrastructure, B2B ICT service management, and defined categories of public administration.
Other critical sectors include postal and courier services, waste management, chemical industry, specific manufacturing sectors, digital providers, and scientific research.
Examples for Corporate IT
| Organization | Potential NIS2 Relevance |
|---|---|
| Electricity grid operator | Critical energy infrastructure |
| Data center | Digital infrastructure |
| Cloud provider | Cloud computing services |
| Managed Service Provider | ICT service management |
| Managed Security Service Provider | Managed security services |
| Manufacturing enterprise | Depends on specific sector and criteria |
| ERP Integrator | May have contractual obligations or fall under defined categories |
| Ukrainian software exporting company | Requires separate legal assessment |
First and foremost, an enterprise needs to determine if its own activities fall under the relevant categories.
However, it is equally important to assess the status of customers.
For example, a Ukrainian IT company might service a European cloud infrastructure provider or an industrial enterprise that falls under NIS2.
In such a case, the client may require the contractor to provide confirmation of security measures, incident response procedures, and access protection.
This is not equivalent to the automatic extension of all direct legal obligations of NIS2 to the contractor, but it can create significant contractual obligations.
4. From Technical Security to Risk Management
One of the main principles of NIS2 is a risk-based approach.
An enterprise should not just install antivirus or a firewall, but identify the risks to its information systems and apply proportional protection measures.
To do this, it is necessary to understand:
- which business functions are critical;
- which information systems support them;
- what data is used;
- which external suppliers are involved;
- what the consequences of an availability breach would be;
- what are the risks associated with compromise;
- what recovery mechanisms exist.
NIS2 directly includes the following areas in cyber risk management: risk analysis policies, incident response, business continuity, supply chain security, vulnerability management, cryptography, access control, and multi-factor authentication.
The relevant principles are set out in Article 21 of the directive.
For a large enterprise, this means the need for a unified cyber risk management system.
Architectural Model
Leadership and Governance
Policies · responsibility · risk appetite · performance control
- Risk Management
- Critical Assets
- Threats and Vulnerabilities
- Suppliers
- Security Controls
- IAM and MFA
- Segmentation
- Data Protection
- Incident Response
- Detection
- Containment
- Notification
- Business Continuity
- Backup
- Disaster Recovery
- Data Integrity
- Audit · testing · performance metrics · continuous improvement
This architecture shows that cybersecurity is not a separate technical component, but an end-to-end corporate governance function.
5. Management Responsibility
An important feature of NIS2 is the increased responsibility of management bodies.
According to Article 20, the competent authorities of essential and important entities must approve cybersecurity risk management measures and oversee their implementation.
The directive also provides for training of management body members, and Member States shall ensure appropriate accountability mechanisms under national law.
For corporate practice, this means that cybersecurity can no longer be considered solely the responsibility of the system administrator.
For example, the decision on acceptable ERP downtime must be agreed upon with business management.
Similarly, the choice of redundancy level must consider the economic consequences.
The IT director can determine the technical possibilities, but the final risk acceptance requires a management decision.
Role Distribution
| Role | Primary Responsibility |
|---|---|
| Governing Body | Approval and Oversight |
| CEO / Executive Management | Business Risk Management |
| CIO | Information Architecture |
| CISO | Cybersecurity |
| Data Owner | Critical Information Assets |
| Process Owner | Business Continuity |
| IT Operations | Operation and Recovery |
| Internal Audit | Compliance Verification |
For small organizations, roles may be combined, but responsibility must remain defined.
6. Supply Chain Security
One of the most important aspects of NIS2 is the focus on the security of suppliers and external IT services.
A modern enterprise rarely maintains all information systems independently.
It uses cloud infrastructure, commercial software products, system integrators, support providers, and external developers.
Compromise of one such provider can create risks for many customers.
Therefore, the entire chain of dependencies must be considered.
For example, a Ukrainian company services an ERP system of a European manufacturer.
To perform tasks, its engineers have remote administrative access.
The customer must understand which accounts are used, how the contractor’s workstations are protected, whether MFA is applied, and how administrative actions are logged.
Vendor Verification Matrix
| Area | Questions |
|---|---|
| Access | Who has administrative rights? |
| Authentication | Is MFA applied? |
| Workstations | What protection measures are used? |
| Secrets | How are keys and passwords stored? |
| Incidents | How does the contractor notify the client? |
| Subcontractors | Are third parties involved known? |
| Backup | Who is responsible for recovery? |
| Documentation | Are up-to-date procedures available? |
| Contract Termination | How is access revoked? |
For IT providers, this means the need to formalize internal procedures.
It is not enough to state that the company has experience in system integration or server support.
It must be possible to confirm access control, logging, backup, and incident responsibility.
7. Reporting of Significant Cyber Incidents: 24, 72 Hours, and Final Report
One of the most notable NIS2 requirements is the multi-stage procedure for reporting significant incidents.
For relevant organizations, Article 23 provides for early warning within 24 hours of the organization becoming aware of a significant incident.
Within 72 hours, a notification with an initial assessment of its severity and impact must be provided.
The final report shall be submitted no later than one month after the incident notification, with foreseen exceptions for ongoing events. Specific deadlines are set for certain trust service providers.
Typical Sequence
Detection of a significant incident
Recording of awareness and initial assessment
Up to 24 hours
Early warning to the competent CSIRT or authority
Up to 72 hours
Initial impact assessment notification
Upon request
Interim incident status information
No later than one month after notification
Final report or progress report as per directive
Crucially, the notification obligation arises for defined significant incidents, not for any technical error or temporary malfunction.
Significance criteria are defined by the relevant legal framework.
For businesses, the ability to quickly gather necessary information is practically important.
If logs are stored in different systems, responsible employees are unknown, and infrastructure documentation is outdated, preparing a reliable notification is difficult.
Therefore, Incident Response must include not only technical problem resolution but also evidence collection, documentation, and notification management.
8. Data as the Foundation for Incident Response
Effective response requires reliable information about the state of the corporate infrastructure.
Among the main sources:
- authentication logs;
- operating system events;
- network logs;
- EDR records;
- VPN logs;
- configuration change data;
- backups;
- ERP and application system logs;
- integration status information.
However, collecting all available logs without a defined purpose can create excessive costs and confidentiality risks.
Therefore, it is necessary to form a logging policy in accordance with system criticality.
Example
| Source | Primary Purpose |
|---|---|
| IAM | Access and privileged actions |
| VPN | Remote connections |
| ERP | Critical business transactions |
| DBMS | Data changes and administration |
| Backup | Copy operations |
| Firewall | Network interaction |
| EDR | Endpoint security events |
| ETL | Information flow status |
It is especially important to synchronize time between systems.
Without correct timestamps, it is difficult to reconstruct the sequence of events.
For critical logs, it is also advisable to provide independent storage so that the compromise of one server does not allow the destruction of all evidence.
9. Data Governance for Cybersecurity
Cyber risk management requires understanding which information assets are critical.
An inventory of servers is not sufficient for this.
It is necessary to know what data is stored on each asset, who owns it, and which business processes depend on it.
For example, two servers may have the same technical configuration but different criticality.
One serves a test environment, the other serves a financial transaction registry.
The loss of the latter will have significantly more serious consequences.
Therefore, Data Catalog and Data Governance can be used to form an information risk map.
Criticality Model
| Information Asset | Confidentiality | Integrity | Availability |
|---|---|---|---|
| ERP Transactions | High | Critical | Critical |
| MDM Counterparties | High | Critical | High |
| DWH | Depends on data | High | Per business requirements |
| Public Catalog | Low | High | High |
| Test Database | Depends on content | Moderate | Lower |
| Backups | According to the original | Critical | Per RTO/RPO |
This model helps prioritize protection and recovery.
Irrecoverable historical data is of particular importance.
Even if they are used rarely, their loss can be irreversible.
10. Cyber Resilience of ERP, CRM, and Data Warehouse
For large enterprises, it is important to ensure the protection of not only servers but also the logical connections between systems.
Suppose the ERP operates in the main data center, CRM is in the cloud, and DWH is in a separate analytical environment.
Compromise of the integration service can affect all three systems.
An attacker is potentially capable of modifying messages, using privileged accounts, or disrupting information flows.
Therefore, integration services must have limited privileges.
For example, a process that only reads ERP data for analytics should not have permission to modify financial transactions.
And a directory synchronization service should only receive necessary permissions.
Protection Principles
Segmentation. Critical systems should not be accessible from all corporate networks.
Least Privilege. Service accounts must have only the necessary permissions.
Independent Backup. Backups are protected from compromise by production accounts.
Data Integrity. Critical records are verified after incidents.
Audit Trail. Changes must be reproducible.
Disaster Recovery. The recovery plan is practically tested.
For Data Warehouse, it is also important to control information sources.
If the DWH receives data from a compromised ERP, it can store and propagate corrupted metrics.
Therefore, analytics recovery must consider the trustworthiness of source systems.
11. Backup and Recovery as a Component of NIS2
Article 21 of NIS2, among the cybersecurity risk management measures, directly provides for Business Continuity, including backup, Disaster Recovery, and crisis management.
This means that the presence of backups should be considered part of a broader resilience system.
The enterprise needs to define:
- critical information resources;
- RPO and RTO;
- independence of backups;
- responsible parties for recovery;
- response procedures;
- testing frequency;
- business readiness confirmation procedure.
Example Recovery Matrix
| System | RPO | RTO | Verification |
|---|---|---|---|
| ERP | 15 min | 4 hrs | Financial transactions |
| CRM | 1 hr | 8 hrs | Orders and clients |
| MDM | 1 hr | 8 hrs | References |
| DWH | 24 hrs | 48 hrs | Analytical indicators |
| SED | 1 hr | 8 hrs | Documents and approvals |
| Archive | 72 hrs | 5 days | Integrity |
The values provided are conditional.
NIS2 does not establish universal RTO/RPO, the same for all enterprises.
They must be determined according to the nature of the activity and risks.
12. New EU Implementing Regulation 2024/2690
On October 17, the European Commission adopted Regulation 2024/2690, which details the application of NIS2 for specified categories of digital providers.
The document was published on October 18, 2024, and sets out technical and methodological requirements for cyber risk management measures.
It is particularly important that it specifically concerns defined types of activities, including:
- DNS providers;
- top-level domain registries;
- cloud providers;
- data centers;
- CDNs;
- Managed Service Providers;
- Managed Security Service Providers;
- certain digital platforms;
- trust service providers.
The document also clarifies the criteria for significant incidents for the relevant categories.
For Ukrainian IT providers, its practical value lies in understanding what technical and organizational mechanisms European customers may expect.
However, it should not be treated as a universal technical instruction that automatically applies to any company creating websites or implementing ERP.
The scope of application needs to be determined separately.
13. Practical Scenario: Ukrainian Integrator and European Customer
Consider a hypothetical Ukrainian IT company that provides support for the corporate information system of a European manufacturing enterprise. The contractor has access to application servers, integration services, and part of the corporate documentation.
The European customer is reviewing its cybersecurity policy in light of NIS2.
Initial State
Contractor access is organized via VPN. Administrative accounts were created at different times.
Part of the documentation is stored in employees’ local directories.
Incident notification procedures are not defined clearly enough.
Stage 1. Access Inventory
All employees and contractor service accounts are identified.
Unused accesses are revoked.
Stage 2. MFA and Administrative Control
Critical accounts are migrated to enhanced authentication.
Privileged session control is applied where possible.
Phase 3. Documentation
Administration regulations, a list of systems, an integration map, and an emergency response procedure are developed.
Phase 4. Incident Response
Contact persons, escalation timelines, and the format for transmitting information about suspicious events to the client are defined.
The contractor’s internal timelines must allow the client to fulfill their own applicable legal obligations.
Phase 5. Data Protection
Access rights to production databases, logs, and backups are reviewed.
Phase 6. Change Control
Administrative changes are performed through a defined procedure with log retention.
Stage 7. Recovery Verification
A test scenario for recovering a critical integration or application service is performed.
Stage 8. Evidence Preparation
An agreed-upon package of documents is transferred to the customer, confirming the fulfillment of relevant requirements without disclosing excessive confidential information.
This is a hypothetical scenario of organizational preparation, not an actual completed project.
14. How to Automate Control of Measure Implementation
For large organizations, the challenge lies not only in creating policies but also in regularly confirming their execution. For example, an enterprise may have a requirement for quarterly review of administrative access.
However, without an appropriate control system, such a procedure easily turns into a formality.
Therefore, it is advisable to use a registry of control measures.
SQL Model
CREATE TABLE security_controls (
control_id VARCHAR(50) PRIMARY KEY,
control_name VARCHAR(200) NOT NULL,
owner_department VARCHAR(100) NOT NULL,
review_interval_days INTEGER NOT NULL,
last_review_date DATE,
next_review_date DATE,
status VARCHAR(30) NOT NULL
);
Control for overdue reviews:
SELECT
control_id,
control_name,
owner_department,
next_review_date
FROM security_controls
WHERE next_review_date < CURRENT_DATE
AND status = 'ACTIVE'
ORDER BY next_review_date;
Such a model can be integrated with BPM or enterprise document management. For example, after the deadline expires, the system creates a task for the responsible employee.
However, the mere fact of closing a task should not be automatically considered proof of compliance.
It is necessary to store the verification result, relevant documents, and, if necessary, confirmation of independent control.
15. Technological base as of October 2024
A wide range of technologies are available to enterprises for organizing technical cybersecurity measures.
| Direction | Examples |
|---|---|
| IAM | Corporate directories, MFA, privilege control |
| Monitoring | SIEM, Prometheus, Grafana |
| Network Security | Firewall, VPN, segmentation |
| Backup | Backup platforms, object storage |
| Data Integrity | PostgreSQL, checksums, Data Quality |
| Automation | Ansible, BPM, orchestration |
| Integrations | Apache Kafka 3.8.0 |
| Data Processing | Apache Spark 3.5.3 |
| ETL Orchestration | Apache Airflow 2.10.2 |
As of October 25, 2024, Apache Kafka 3.8.0 remains the available release for its branch: version 3.8.1 will be released only on October 29.
Apache Spark 3.5.3 was released on September 24, and Apache Airflow 2.10.2 was released in September.
It is important that NIS2 compliance is not achieved by implementing a specific set of technologies.
The directive requires systematic risk management, rather than the use of a defined DBMS, message broker, or software product.
16. 120-Day Preparation Roadmap
| Period | Key Activities | Outcome |
|---|---|---|
| Days 1–20 | Scope definition, risk audit | Initial compliance map |
| Days 21–40 | Asset, access, and supplier inventory | Critical dependencies registry |
| Days 41–60 | Security policies and Incident Response | Documented procedures |
| Days 61–80 | Backup, DR, privilege control | Technical mechanisms |
| Days 81–100 | Supplier testing and verification | Verified results |
| Days 101–120 | Training, internal audit, adjustments | Further improvement plan |
The timelines are provided as a guideline for the organizational program.
For enterprises subject to specific legal requirements, the internal roadmap does not alter legally mandated deadlines.
Additionally, not all companies are obligated to implement the same measures.
The level of control should align with risks, organizational size, and applicable regulations.
17. Cybersecurity Resilience and Audit Readiness KPIs
| KPI | What it assesses |
|---|---|
| Critical Asset Coverage | Completeness of inventory |
| Risk Assessment Coverage | Proportion of assets with assessed risks |
| MFA Coverage | Account protection |
| Privileged Access Review | Regularity of privilege review |
| Backup Restore Success | Suitability of backups |
| RTO/RPO Compliance | Adherence to recovery parameters |
| Incident Detection Time | Detection speed |
| Incident Escalation Time | Internal notification speed |
| Supplier Risk Coverage | Assessment of critical suppliers |
| Security Control Compliance | Implementation of defined measures |
| Audit Finding Resolution | Resolution of audit findings |
| Management Review Completion | Management oversight |
Metrics should be used not only for reporting.
Their main goal is to identify weak points and confirm the effectiveness of security measures.
For example, the presence of MFA does not guarantee the security of the entire infrastructure if shared administrative accounts remain uncontrolled.
Therefore, a comprehensive assessment is needed.
18. Economics of Compliance
Preparation for NIS2 may require additional costs.
Among them:
- audit of information architecture;
- modernization of access systems;
- centralized logging;
- backup;
- recovery testing;
- employee training;
- vendor assessment;
- process documentation;
- independent audits.
However, part of these costs creates direct operational value. For example, organizing administrative access reduces the risk of compromise.
Documenting integrations speeds up disaster recovery. Verifying backups allows detection of problems before a real incident.
Therefore, the NIS2 preparedness program should be considered an investment in digital resilience.
Conditional Priority Levels
| Measure | Risk Impact | Priority |
|---|---|---|
| Critical Asset Inventory | High | Priority |
| MFA for Administrators | High | Priority |
| Independent Backups | High | Priority |
| Incident Response Plan | High | Priority |
| Vendor Assessment | High for dependent systems | High |
| Centralized Logging | Depends on architecture | High |
| Audit Automation | Reduction of manual costs | Gradual |
| Advanced Security Analytics | Additional detection | Based on analysis results |
Such prioritization should be adapted to the actual needs of the organization.
19. Risks and Common Mistakes
Automatic propagation of NIS2 to all suppliers. It is necessary to check the legal scope of application. Ignoring national transposition. Specific obligations may depend on the legislation of the EU member state.
Formal documentation without practical implementation. A cybersecurity policy does not replace real measures. Lack of management involvement. Risk management requires business decisions.
Underestimation of suppliers. Compromise of external services can affect the customer’s critical infrastructure. Undefined escalation timelines. Slow internal communication complicates regulatory compliance.
Lack of independent redundancy. Replication does not replace secure backup. Incomplete inventory. It is impossible to protect information resources whose existence is unknown.
Confusion between technical and business criticality. A powerful server is not necessarily the most important for the enterprise. Perception of compliance as a one-time project. Cyber risks and information architecture are constantly changing.
20. Intecracy Group Competencies
Ensuring cyber resilience requires comprehensive competencies covering information systems, data, infrastructure, and automation. Data Management IG (dmig.com.ua) specializes in ETL, MDM, Data Quality, Data Warehouse, Data Lake, Data Governance, and corporate analytics. These competencies can be applied to inventory information resources, identify critical datasets, verify Data Integrity, and ensure the recovery of information flows after incidents.
IQusion IT (iqusion.com) provides system integration, electronic document management, BPM, and business process automation. These competencies can be useful for organizing controlled response procedures, change approvals, documentation management, and formalizing responsibilities. Softline IT (softline.kiev.ua) specializes in server and network infrastructure, storage systems, and infrastructure projects. These technological areas are important for segmentation, redundancy, monitoring, and ensuring the availability of corporate systems.
SL Global Service (sgs4business.com) operates in the areas of cloud integration, virtualization, and hybrid infrastructure. These competencies can be used for designing resilient distributed environments, backup sites, and controlled deployment of corporate resources.
In a comprehensive project, these specializations can complement the work of cybersecurity specialists, compliance officers, legal consultants, and auditors. It is important to note that NIS2 compliance cannot be guaranteed solely by implementing a single software product or a set of technical tools.
It depends on the actual activities of the organization, applicable regulations, internal procedures, and audit results.
Cybersecurity Becomes Part of Corporate Governance
October 2024 marks a significant milestone in the development of European cyber regulation.
NIS2 expands the scope of organizations for which cybersecurity becomes a subject of formalized management, oversight, and accountability.
For large enterprises, this means the necessity of considering information risks at the corporate strategy level. It is not enough to have an antivirus, firewall, or backup.
It is necessary to understand which business processes depend on information systems, what data is critical, who is responsible for its protection, and how the company will act after an incident.
Supply chain management is becoming particularly important.
External IT companies, integrators, and cloud providers may have access to critical components of the customer’s infrastructure.
Therefore, European companies will increasingly require confirmation of security procedures and access control from their partners.
For Ukrainian IT companies, this creates not only additional requirements but also an opportunity to increase the trust of international customers.
Having documented procedures, independent backups, privileged access control, and the ability to quickly report incidents can become a significant competitive advantage. At the same time, it is necessary to avoid incorrect legal generalizations.
NIS2 does not automatically apply to any company that cooperates with the EU. It is necessary to determine the organization’s status, the nature of services, coverage criteria, and the applicable requirements of the relevant state.
For corporate Data Management, the integration of data management with cyber risk management is becoming important. Data Governance helps define information resource owners.
MDM supports the integrity of critical reference data. Data Quality allows for the detection of validity violations.
Data Warehouse can provide controlled incident analytics. And verified recovery procedures ensure that the enterprise can return to a defined level of operability.
Key takeaway from October 2024: cyber resilience can no longer be considered solely an IT department technical function. It is becoming a measurable component of corporate governance, management responsibility, and trust between business partners.
This approach is of particular value to Ukrainian enterprises operating in wartime conditions while simultaneously developing cooperation with the European Union.
It allows for the combination of accumulated experience in disaster recovery and critical data protection with the systemic requirements of the European digital market.
And for the Data Management IG, the management of corporate information resources is increasingly linked not only to the efficiency of processing and analytics but also to ensuring their integrity, controllability, and security throughout their entire lifecycle.

Author