NIS2
WORKING GROUP
Practical help for compliance
The European Union's NIS2 Directive (2022/2555/EU) raises cybersecurity requirements to a new level. We help you navigate the regulations and answer practical questions.
What is NIS2?
The European Union's cybersecurity directive, which sets mandatory information security and risk management requirements for relevant organizations to protect digital infrastructures and services.
Who does it apply to?
The NIS2 Directive primarily applies to medium-sized and large companies operating in critical and important sectors, as well as organizations whose operations are of paramount importance for the digital security of the country and the economy.
Why is it important?
It helps organizations prepare for cyberattacks, reduces business and operational risks, and increases trust in security among customers, partners, and authorities.
Comments received so far
Conduct a comprehensive impact assessment and system assessment: Before any significant changes are made to the current NIS2 environment, a comprehensive impact assessment should be conducted that systematically analyses the situation based on the experiences of the past two years. This should examine the motivations, capacity issues and often conflicting incentives of individual stakeholders (affected organisations, auditors, consultants, authorities, suppliers). The second part (or phase) of the study would assess the market, operational and cybersecurity impacts of each regulatory or methodological change in the short and long term.
Establishing a phased, maturity-based implementation model (but more effectively than the organizational security level under the old IBtv.): One of the biggest problems with the current system is that it tries to force a very high level of compliance from organizations of extremely different maturity levels in too short a time. It would be advisable to gradually introduce obligations at least along the “essential” and “important” categories, but even based on actual cybersecurity maturity. For a medium-sized company with low maturity, stable operation of basic controls should first be achieved, and then more complex requirements could be moved along a multi-year (tracked) roadmap. This would not weaken security, but would ensure a more realistic and sustainable development path.
Simplifying the requirements for smaller and less mature organizations: NIST SP 800-53 is an extremely detailed and complex control framework that was originally optimized for larger and more advanced organizations for US critical infrastructures. For many Hungarian organizations, the current goal is not to fine-tune controls, but to establish basic security operations. It would be worthwhile to use a simpler baseline model (for example, moving towards the NIST Cybersecurity Framework or a maturity-based approach) that would better support gradual development and not push audit compliance practices towards "paperwork".
Introduction of a separate OT/ICS methodology and requirements set: The current approach is too IT-centric, while many affected organizations operate in industrial, manufacturing or other OT environments. The operational logic, risks and technological limitations of OT systems are fundamentally different from the classic IT environment. It would be worthwhile to develop separate guidelines and audit expectations based on the logic of NIST SP 800-82 or IEC 62443, so that the PLC network of a production line is not audited with the same approach as an enterprise Active Directory environment.
Development of a separate cloud security requirements system and audit methodology: The current regulatory and auditing logic is fundamentally based on traditional, on-premise infrastructures, while a significant part of modern organizations already operate in hybrid or fully cloud-based environments. The operation, responsibility model and security risks of a cloud-native architecture are fundamentally different from a classic server-centric infrastructure. In many cases, current controls are difficult to interpret in a SaaS, PaaS or multi-cloud environment, and they cause excessive administrative burden. It would be advisable to develop a separate cloud security guide and audit methodology that takes into account the shared responsibility model, modern identity and access management, CSPM solutions, DevSecOps operation, and the boundaries of responsibility between cloud service providers and the organizations involved. This would reduce the uncertainty of audits, create a more uniform interpretation and better fit the real operation of modern infrastructures.
Introduction of a separate AI governance and AI security requirements system: The explosive spread of AI tools is fundamentally changing the compliance, regulatory and auditing environment, while the current NIS2 system practically does not address this area. Organizations are starting to use AI en masse for policy generation, control interpretation, documentation preparation or even audit support, in many cases without appropriate controls. This can easily lead to an “AI-optimized compliance” that works well on paper, but lacks real operational maturity or human understanding. In addition, AI tools that are increasingly used in everyday life also cause a lot of security problems, for which this EIR-centric system (especially with the current requirements system) is not suitable. It would be advisable to develop separate AI governance and AI security requirements.
Real support and enforcement of risk-based operations: The law provides the opportunity to customize, exclude or apply substitute protection measures, but in practice many organizations do not understand or dare to apply this. For this reason, organizations often try to mechanically comply with all controls, without real risk analysis. The authority and the professional community should support actual risk-based decision-making much more strongly, with concrete examples and methodological guidelines.
Publish detailed regulatory guidelines and evidence catalogs: Currently, a significant portion of the market operates in uncertainty because there is no uniform interpretation of exactly what evidence is acceptable for the fulfillment of a control. It would be worthwhile to define for each type of control whether, for example, a policy, screenshot, configuration export, log file, interview or functional test is required. This would significantly reduce conflicts between organizations, consultants and auditors, and increase the comparability of audits.
Rethinking the audit fee system: The current fee structure creates perverse incentives in many cases, especially due to the multipliers related to the number of ERPs. As a result, many organizations try to consolidate their systems in a way that is not optimal from a business or professional point of view, just to reduce the audit cost. A model should be developed that does not penalize a more detailed and professionally correct system assessment.
Standardizing EIR identification and grouping: The concept of EIR is still unclear to many organizations, especially in complex or mixed IT/OT environments. Detailed, sector-specific examples, reference architectures, and concrete model models are needed to help organizations and auditors think along similar lines. This would be especially important for large enterprises and multi-site groups.
Strengthening management responsibility and education One of the most important goals of NIS2 would be to ensure that cybersecurity is not presented as a purely technological issue, but rather becomes a (real) management and business responsibility, as it is currently in theory, but in practice this has not had an encouraging effect on anyone. However, in many places the entire burden of compliance falls on the IBF or the IT department, while senior management does not understand the business and risk implications of decisions. It would be advisable to introduce mandatory management training, similar to some Western European models.
Driving operational resilience instead of compliance: The current environment is pushing the market towards being too document-centric. This can lead to a situation where an organization demonstrates high levels of compliance on paper while remaining weak in real-world operations. Audits should place greater emphasis on operational evidence, vulnerability assessments, incident response capabilities, real-world technical controls, and even red teaming-style validations.
Gradual and controlled expansion of the audit market: The current capacity shortage is unsustainable in the long term. However, rapid market expansion can easily come at the expense of quality. A mentored or multi-level audit model could be developed, where junior auditors develop alongside experienced senior auditors, while ensuring professional quality and a uniform methodology.
Creating a more stable and predictable regulatory environment: With new, complex cybersecurity regulations, it is natural that modifications will be needed over time. However, it would be important that changes are made along a transparent roadmap, with appropriate transition periods and clear communication. Legal certainty and predictability are key to ensuring that organizations do not just try to survive compliance, but view it as a real development program.
Rethinking EIR-based operations and supporting it with practical guidance: The EIR-based compliance model is not necessarily flawed in itself, but in its current form it is often too theoretical and difficult to apply in practice. This is particularly problematic as audit fees depend to a significant extent on the number of EIRs, which creates perverse incentives and can lead to professionally unjustified system mergers. The EIR model can only work well if detailed, sector-specific practical guidance, reference architectures and concrete examples support identification and grouping.
Rethinking the defined audit fee cap and market operation: While the current audit fee cap may protect the affected organizations in the short term, it may cause capacity and quality problems in the audit market in the longer term. It is likely that the market would be able to naturally price in audits of different complexity, especially if the requirements system and audit methodology were to become simpler, more proportionate and better standardized. The current model may place excessive cost pressure on auditors, which may be at the expense of quality and further strengthen mass-production auditing operations.
Adapting international best practices to the Hungarian market: Several European countries (e.g. Belgium) use a maturity-based, gradual approach that is more in line with the operational reality of organizations. For example, the CyberFundamentals Framework combines maturity models, practical controls and international standards. It would be worth examining which elements of these could be adapted to the Hungarian regulatory environment.
Less is sometimes more: the current regulation, its implementation and the audit decree all work in the direction that the audit has become entirely a paperwork. It is possible to pass the audit with all the regulations and documents of the given organization, but it has neither MFA, nor backups, nor a strong password policy. But it has a 70-page system security plan. The current regulation does not help companies increase their cybersecurity level, but in return it consumes significant resources. It would be more appropriate to formulate fewer expectations, but to control the fewer expectations more strictly. Backups, admin MFA, authorization management, education should be mandatory, but at a basic level, does it really add to the life of an organization if it classifies jobs from a security perspective? Or if it holds anti-forgery training? In my opinion, the existence of independent auditors and the audit obligation are a good thing, but if we are already "using" them, then we could do well: to truly examine real security expectations.
The number of enterprises to be audited, the number of audit firms and auditors, and the number of audits expected during a period should be compatible with reality, should be in line with it, it would be worth regulating how many/what audit-required enterprises an audit firm can audit with its available auditor capacity (employee/subcontractor) during a certain period (e.g. 1 year). Currently, most audit firms are overloaded, which has an impact on the quality of auditing and the quality of communication with audited organizations; it is not certain that the number of auditors required to meet the current conditions is currently available in the country.
How does the NIS2 working group help?
The NIS2 working group of the Hungarian Cybersecurity Cluster was established to provide practical assistance in managing the technical, legal and organizational challenges arising during the transition to the NIS2 directive. Numerous questions, comments and development proposals are being formulated by obligated organizations, consultants, information security officers, auditors and other professional actors regarding the domestic implementation, audits, EIR and the definition of the scope of stakeholders.
The aim of the working group is to collect, systematize and forward these experiences and professional opinions to the legislative side, thereby supporting the development of a broader professional dialogue. The initiative creates an opportunity for the necessary modifications and clarifications to be made based on professional consensus.
On the site, interested parties can also ask their questions directly to the working group's experts, who will provide assistance in areas such as risk management, incident reporting, supply chain security, and compliance documentation.
Ask your question - Secure the future of your organization!
Please share your comments, experiences, or suggestions regarding the domestic requirements, application, and applicability of NIS2 with us, even anonymously!
If you agree, we will display your suggestions on the site to promote further joint thinking and professional discourse!