Hungary’s Cybersecurity Act Starts With Registration and Audit
Hungary moved early on NIS2-style supervision. Its 2023 cybersecurity act made identification, registration, system classification and independent audit the opening stages of a regulated security programme.
Act XXIII of 2023 on Cybersecurity Certification and Cybersecurity Supervision took effect on 23 May 2023. It assigned the Supervisory Authority for Regulated Activities, SZTFH, responsibility for cybersecurity supervision of companies and organisations providing services important to society, the economy and digitalisation, alongside certification functions.
The framework has since been amended and integrated with later Hungarian cybersecurity legislation. The 2023 Act remains an important starting point for understanding why Hungarian implementation places so much weight on formal registration and auditable controls.
Scope cannot be delegated to the security team alone
The regulated sectors and size rules require legal-entity and service analysis. A security department may know the technology but not the employee thresholds, group structure or statutory service definitions. Legal and finance may know the entity but not which system actually provides the service.
The scope record should connect those views. It should identify the legal entity, covered activity, relevant thresholds, registration decision and systems supporting the service. Corporate reorganisations, acquisitions and new digital services should trigger reassessment.
Late or incomplete registration is more than an administrative problem. It delays the authority’s view of the entity and compresses the time available for classification and audit.
System classification should follow business impact
The Hungarian model requires electronic information systems to be assigned a security class and the organisation itself to a security level under the detailed framework. That classification drives applicable protection measures.
An inventory should group systems by the regulated service they support, including cloud platforms, identity services, network management, operational technology and outsourced components. A shared system may require the higher treatment associated with its most critical supported use.
Classification decisions need reasons. Teams should record confidentiality, integrity and availability impacts, interdependencies, recovery needs and public consequences. A label without a service map cannot guide controls or survive audit questioning.
Audit changes what counts as evidence
The supervised organisation must arrange cybersecurity audit through an authorised auditor on the statutory cycle. An audit is not the moment to discover that a control exists only as an unwritten practice.
For each required measure, the entity should identify the owner, system scope, implementation evidence, test result and remediation. Screenshots captured shortly before the audit are weak evidence if they cannot show that the control operated consistently.
Cloud and managed services need a shared-responsibility map. A provider certificate may support part of the evidence, but the customer’s configuration, access decisions, logging and continuity remain relevant. Contracts should permit the entity to obtain the evidence needed for supervision and audit.
Vulnerability and incident processes need authority routes
Formal supervision also requires operational contact. The organisation should know which event is handled internally, which is notified to the authority or incident-response body and which needs customer or sector communication.
Incident exercises should test an outsourced failure and a vulnerability affecting a widely used product. These scenarios reveal whether the entity can identify all affected systems, contact suppliers, preserve evidence and make a reporting decision before certainty is available.
Vulnerability management should connect public advisories and supplier notices to the asset inventory. If the organisation cannot determine where a component is used, the classification and audit work have not produced an operational benefit.
The Hungarian evidence chain
Organisations should be able to trace:
- the scope decision to the legal entity and service;
- registration to current organisational details;
- service criticality to system classification;
- classification to the required security measures;
- measures to operating and tested evidence;
- gaps to funded remediation; and
- the complete chain to an authorised independent audit.
Hungary’s model makes cybersecurity legible through formal stages. The risk is treating each stage as separate paperwork. The value appears when registration, classification and audit describe the same living service and expose weaknesses early enough to fix them.
Official sources
Continue the series
- Next in Hungary: Hungary’s Whistleblower Law Turns Follow-Up Into a Timed Process
- European National Cyber & Digital Law Series index
This article provides general information and is not legal advice.
