Hungary compliance analysis: Act LXIX of 2024 and what the unified Cybersecurity Act actually requires
Geert WarmenbolApril 29, 2026
Key takeaways
Hungary's Act LXIX of 2024, effective January 1, 2025, created a single unified Cybersecurity Act covering both public and private sectors -- unusual in the EU and materially different from the partial 2023 transposition it replaced.
All covered entities must classify their electronic information systems into basic, significant, or high security classes before they can contract with a certified auditor -- the classification is a prerequisite, not a parallel step.
Mandatory cybersecurity audits must use firms from the SZTFH Auditors Registry specifically. Uncertified consultants do not fulfill the legal requirement, regardless of technical competence.
The first mandatory audit deadline is June 30, 2026 for organizations registered before January 2025. This is widely described as a firm deadline with no further extension anticipated.
Hungary extended NIS2 scope beyond the EU baseline to include public transport, certain manufacturing niches, and sole providers regardless of size -- organizations in these categories that self-assessed as out-of-scope under standard NIS2 criteria may be wrong.
Personal manager liability for cybersecurity failures is a real feature of Act LXIX of 2024, requiring formal designation of a person responsible for electronic information systems security from January 1, 2025.
TL;DR
Hungary's compliance landscape changed fundamentally on January 1, 2025. The new Cybersecurity Act unified what were previously separate public and private sector regimes, introduced mandatory third-party audits by SZTFH-certified firms only, and tied control requirements to a three-tier security classification system. Most organizations have not completed the prerequisite classification step. The June 2026 audit deadline is close enough that the gap between current state and audit-ready state needs to be measured now, not in early 2026.
The audit deadline that arrived before the regulatory decree did
When Hungary's 2023 partial NIS2 transposition required covered organizations to sign mandatory audit contracts by December 31, 2024, thousands of Hungarian businesses started looking for certified auditors. There was one problem: the SZTFH decree specifying the maximum allowed auditor fee -- the regulation that would make auditor contracting legally straightforward -- had not been published. Organizations could not negotiate contracts against a regulatory framework that did not yet exist. The deadline passed. The decree arrived on January 31, 2025. By that point the 2023 Cybersecurity Act itself had been repealed by Act LXIX of 2024, which came into force on January 1, 2025 with a new set of deadlines.
The compliance program that was not ready for the 2024 deadline is now operating under a different law entirely, with a June 2026 audit deadline and the same foundational prerequisite still incomplete: security class classification. You cannot contract with a certified auditor until you have classified your systems. You cannot know which NIST SP 800-53 Rev. 5 controls apply to your environment until you have completed the classification. The compliance gap is not documentation. It is the prerequisite step that unlocks everything else.
How Hungary's unified Cybersecurity Act actually works
Act LXIX of 2024 is structurally unlike most NIS2 transpositions in the EU. Most member states maintained separate regulatory regimes for public sector information systems and private sector cybersecurity. Hungary unified them into a single statute, covering administrative bodies, state-owned enterprises, and private entities in scope under NIS2 within the same legal framework. This has practical implications for gap analysis. An organization operating mixed public-private arrangements, or a technology provider serving both government and private clients, faces a single compliance framework rather than two parallel ones. That simplifies some assessment decisions and complicates others, particularly around scope determination.
Example
Hungary also extended the scope of the law beyond the NIS2 baseline in ways that are not obvious from standard NIS2 self-assessment checklists. The Act explicitly includes public transport operators and specific manufacturing categories including cement and plaster production. More significantly, it covers sole providers -- organizations that are the only entity in Hungary providing a specific service -- regardless of company size. A 25-person company that is the sole provider of a specific logistics or processing service in Hungary is in scope under Act LXIX of 2024 regardless of whether it would qualify as a medium-sized enterprise under the standard NIS2 threshold. Organizations that conducted their NIS2 scope assessment before the 2024 Act was published may have assessed against criteria that no longer apply.
The three-tier security classification system (basic, significant, high) determines which protective measures apply, following MK Decree 7/2024 (VI. 24.) and NIST SP 800-53 Rev. 5 as the technical control framework. Classification is not self-assessed freely -- it follows defined criteria based on the risk to integrity and availability of the electronic information system and the sensitivity of processed data. Getting the classification wrong in either direction creates problems. Underclassification means controls that should have been implemented were not. Overclassification means unnecessary investment in controls not actually required, and a classification that may not survive auditor review.
What Hungary compliance assessments find in practice
Assessment base: Vulnox assessment data, 2024-2025, Hungarian organizations across technology, manufacturing, and financial services sectors
Security class classification has not been started, which blocks everything downstream
The most consistent finding in our assessments of Hungarian organizations preparing for the June 2026 audit deadline is that the security class classification has not been completed. In most cases it has not been formally started. Organizations are aware of the audit deadline. They are less aware that the classification is a prerequisite for auditor contracting, and that the classification requires an impact assessment and asset mapping of electronic information systems that is itself a significant piece of work. The sequence -- asset mapping, impact assessment, classification, auditor contracting, audit -- means that organizations starting the process in late 2025 are compressing a multi-step process into a short window.
The client assumption is typically that the audit preparation will proceed in parallel with compliance preparation. The actual structure requires them to happen in sequence. An organization that has not completed its security class classification cannot formally contract with an SZTFH-certified auditor against a defined scope. Starting the classification work is the critical path item, and it requires accurate asset inventory that most organizations do not have.
Asset inventories exclude cloud workloads and third-party managed systems
Hungary's Cybersecurity Act requires an impact assessment and asset mapping of electronic information systems environments. In the organizations we assess, asset inventories consistently exclude cloud workloads provisioned by engineering teams outside IT procurement, systems managed by third-party service providers under managed services contracts, and legacy infrastructure that was supposed to be decommissioned. The gap between the formal asset inventory and the actual electronic information systems environment is typically significant. Classification performed against an incomplete asset inventory produces a classification that does not reflect actual risk.
An auditor reviewing the security class classification will examine whether the scope of classified systems reflects the actual organizational environment. A classification that excludes material systems is not a clean result. It is a finding that the classification process was inadequate, which in turn questions the adequacy of the controls implemented based on that classification.
Incident reporting procedures are designed for GDPR, not for the Cybersecurity Act
Covered entities under Act LXIX of 2024 have specific incident reporting obligations to the SZTFH with timelines and content requirements defined in the Act and implementing decrees. Most Hungarian organizations with existing incident response programs built those programs around GDPR breach notification to the NAIH. The SZTFH reporting obligation has different triggers, different content requirements, and a different recipient. Organizations that have a single incident response procedure designed for GDPR breach notification are not operationally prepared for the Cybersecurity Act reporting obligation. In tabletop exercises we run against realistic incident scenarios, teams consistently default to the NAIH notification process and do not know the parallel SZTFH procedure.
In an incident that triggers both GDPR notification to the NAIH and Cybersecurity Act notification to the SZTFH, an organization running a GDPR-only incident procedure will satisfy one obligation and miss the other. The SZTFH reporting obligation does not have a GDPR grace period. Organizations discover the gap at the worst possible moment.
Manager liability designation has not been formally completed
Act LXIX of 2024 requires covered entities to designate a person responsible for electronic information systems security. This is a named individual with defined responsibilities, not just a general reference to the CISO role in organizational charts. The obligation applies from January 1, 2025. In our assessments of Hungarian organizations subject to the Act, the formal designation -- a documented assignment of the role with defined responsibilities as the Act requires -- has frequently not been completed. The person informally responsible exists. The formal designation that satisfies the legal obligation does not.
Personal manager liability under Act LXIX of 2024 is not theoretical. The Act explicitly ties liability to cybersecurity failures at the management level. An organization that has not formally designated the required responsible person has a compliance gap that is easy to close and carries direct personal exposure for the individual who is informally responsible without the formal designation.
Completing the GDPR compliance program first creates Hungary Cybersecurity Act exposure, not protection
Common belief
Organizations that invest in strong GDPR compliance programs are well positioned for Hungary's broader cybersecurity requirements. GDPR compliance covers data protection, security controls, and incident response, which are the same areas the Cybersecurity Act addresses.
What we found
We have assessed Hungarian organizations with ISO 27001 certification and complete GDPR programs that have not started their security class classification under the Cybersecurity Act, have not identified an SZTFH-certified auditor, and have incident response procedures that do not include SZTFH notification. The GDPR program is genuine and well-maintained. The Cybersecurity Act compliance is at zero. The confidence that the GDPR program covered the Cybersecurity Act gap prevented the gap from being identified until the assessment.
GDPR compliance programs are built around data protection accountability. They produce processing records, data protection impact assessments, breach notification procedures tuned to NAIH timelines, and consent management systems. The Cybersecurity Act compliance program needs system classification against NIST SP 800-53 Rev. 5, asset mapping of electronic information systems (not just personal data systems), incident reporting procedures tuned to SZTFH timelines, and mandatory audit completion by SZTFH-certified firms. These are overlapping but not identical requirements. The specific failure mode we see is that organizations with mature GDPR programs assume the Cybersecurity Act gap is small because the GDPR program already covers security. The gap is in scope and methodology, not maturity. A GDPR compliance program that treats all electronic information systems as personal data processing systems misses the systems that are in scope under the Cybersecurity Act for reasons other than personal data.
Where Hungary compliance assessments consistently miss
Scope assessment errors from pre-2025 NIS2 self-assessment
Many Hungarian organizations conducted their initial NIS2 scope assessment in 2023 or 2024 against the criteria of the 2023 partial transposition. Act LXIX of 2024 changed the scope criteria in several ways, including the sole provider rule and the explicit inclusion of public transport and certain manufacturing categories. Organizations that assessed themselves as out of scope before 2025 may be in scope under the 2024 Act and have not reassessed. The SZTFH will not necessarily notify organizations that their scope status has changed. Non-registration by an in-scope entity is itself a compliance violation.
Third-party service provider systems within scope
Electronic information systems operated by third-party managed service providers on behalf of a covered entity are within the scope of the classification and audit requirements. The system does not need to be operated on the covered entity's premises to be in scope. Organizations that outsource IT infrastructure, cloud operations, or application management frequently assume that the third party's system is the third party's compliance responsibility. Under Act LXIX of 2024, the covered entity is responsible for ensuring that outsourced systems are classified and that controls are implemented, even if the operation is contracted to a third party.
Sole provider status that triggers scope inclusion regardless of size
Hungary's inclusion of sole providers regardless of company size is the scope criterion most likely to catch organizations that would otherwise consider themselves below the NIS2 threshold. A company with fewer than 50 employees that is the only provider of a specific service in Hungary is in scope. The practical challenge is that organizations do not always know whether they meet the sole provider definition. The SZTFH has not published clear guidance on how sole provider status is determined. Organizations in specialized niches should assess whether they fall within the definition before assuming size-based exclusion applies.
Annual cybersecurity supervisory fee obligation
Covered entities under Act LXIX of 2024 are required to pay an annual cybersecurity supervisory fee to the SZTFH. The fee structure was defined in a decree published in January 2025. Organizations that registered with the SZTFH before the fee decree was published may not have incorporated the fee into their compliance budget or may be unaware of the obligation. The fee is not nominal -- it is a recurring cost tied to the scope and classification of systems under supervision.
Where Hungary enforcement is heading after the June 2026 audit deadline
The SZTFH will prioritize enforcement against organizations that are in scope but have not registered, rather than against registered organizations with control gaps, in the 12 months following the June 2026 audit deadline.
The structural enforcement challenge for Hungary after June 2026 is that the SZTFH does not have comprehensive visibility into which organizations are in scope and have not registered. Enforcement against registered entities with audit gaps is straightforward -- the SZTFH has the registration data. Enforcement against unregistered in-scope entities requires the SZTFH to identify them through sector-level mapping. The European Commission's ongoing scrutiny of Hungary's NIS2 transposition completeness will create pressure on the SZTFH to demonstrate active enforcement scope coverage, which points toward an unregistered entity campaign before a control quality campaign.
Confidence: mediumSZTFH enforcement actions in the 12 months post-June 2026 primarily target registered entities with control failures rather than unregistered entitiesThe auditor capacity constraint will produce a two-tier compliance market in Hungary, where organizations that contracted early with SZTFH-certified auditors complete their June 2026 audits and organizations that wait face a shortage of available certified audit capacity.
The certified auditor pool is finite and defined by the SZTFH Auditors Registry. The population of organizations that need to complete their first audit by June 2026 is estimated at approximately 7,500 entities. The SZTFH-certified auditor market was not built to process 7,500 audits in an 18-month window. Organizations that contract auditors in the first half of 2025 lock in capacity. Organizations that wait until late 2025 or early 2026 will find that certified auditor availability is constrained, particularly for the audit timeline that satisfies the June 30, 2026 deadline.
Confidence: highSZTFH Auditors Registry expands to sufficient capacity to service all registered entities by Q1 2026 without scheduling constraints
The debate worth having: unified framework versus parallel regimes
Hungary's decision to unify public and private sector cybersecurity requirements into a single statute is the most interesting structural choice in its NIS2 transposition, and it is genuinely contested among compliance practitioners. The argument for unification is operational efficiency: organizations with mixed public-private operations deal with one framework, one supervisory authority, one audit standard. The argument against is that public sector information systems and commercial cybersecurity have different threat profiles, different operational constraints, and different resource environments. A single framework that works for both tends to be calibrated for the middle, which means it underserves high-risk environments and over-burdens low-risk ones. My view is that the three-tier classification system (basic, significant, high) is Hungary's structural answer to that criticism -- it tries to right-size requirements to actual risk rather than applying a flat standard. Whether it succeeds depends on whether the classification criteria produce accurate risk differentiation in practice, which the first audit cycle will reveal.
Counterargument
The counterargument from practitioners who have worked across both public and private sector environments in Hungary is that the unified framework works better in theory than in the implementation reality. Public sector entities often lack the procurement flexibility and budget mechanisms to contract with SZTFH-certified private auditors in the way the law assumes. The unified framework applies identical procedural requirements to a municipal government and a technology company without adjusting for the structural differences in how those organizations acquire services and manage vendors.
One action before the end of the week
Identify whether your organization has completed the security class classification required under Act LXIX of 2024. If the classification has not been completed, start with the asset mapping -- a full inventory of electronic information systems in your environment including cloud workloads and third-party managed systems. The classification cannot be accurate if the asset inventory is incomplete. The auditor contract cannot be signed until the classification is done. And the June 2026 deadline does not accommodate a sequence that starts in 2026. The one thing to do this week is find out exactly where you are in that sequence.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
mapping your digital footprintEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
Hungary data and cyber compliance gap analysisGDPR Compliance Guidelines
GDPR compliance guidelinesNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideNIST Vulnerability Assessment Definition
NIST vulnerability assessment definition
Frequently Asked Questions
What is Hungary's Act LXIX of 2024 and who does it apply to?
Act LXIX of 2024 on Cybersecurity in Hungary, effective January 1, 2025, is Hungary's complete NIS2 transposition law. It replaced the 2023 partial transposition and the 2013 public sector information security law, creating a single unified cybersecurity framework covering both public and private sectors. This is unusual in the EU -- most member states maintain separate regimes. The Act applies to organizations registered in Hungary or represented by a local representative, across 18 sectors including energy, transport, healthcare, digital infrastructure, and manufacturing. Notably, Hungary extended scope beyond the NIS2 baseline to include public transport and certain manufacturing sectors, and applies the law to sole providers regardless of company size.
What are Hungary's three security classes under Act LXIX of 2024 and how do they work?
Hungary's Cybersecurity Act requires all covered entities to classify their electronic information systems into one of three security classes: basic, significant, or high. Classification is based on the risk to integrity and availability of the system and the confidentiality, integrity, and availability of processed data. Higher security classes carry more demanding protective measures, which follow NIST SP 800-53 Rev. 5 as the underlying technical framework. The classification must be completed as a prerequisite to contracting with a certified auditor, meaning organizations that have not classified their systems cannot proceed with the mandatory audit requirement.
What is the SZTFH and why does Hungary's mandatory audit requirement specifically require SZTFH-certified auditors?
The Supervisory Authority for Regulated Activities (SZTFH) is Hungary's primary cybersecurity supervisory body under Act LXIX of 2024. The mandatory cybersecurity audit requirement for covered entities specifically requires the use of auditors from the SZTFH Auditors Registry -- informal consultants or non-certified firms do not satisfy the requirement regardless of their technical competence. The SZTFH publishes the registry of approved auditor firms. Organizations that engage uncertified auditors do not fulfill the legal obligation, which is a compliance gap that is not immediately visible but produces enforcement exposure when the SZTFH conducts supervisory inspections.
What is the first mandatory cybersecurity audit deadline for Hungarian organizations?
For organizations that existed before January 2025, the first mandatory cybersecurity audit must be completed by June 30, 2026. This deadline was extended from the original December 31, 2025 deadline after it became clear that the SZTFH auditor registry decree was not published in time to allow contracts to be signed. The contract with a certified auditor must be signed within 120 days of registration, or by May 1, 2025 for entities already registered before the new law. After the first audit, entities are subject to audit every two years. The June 2026 deadline is widely described as a firm deadline with no further extension anticipated.
What are the most common Hungary compliance gaps found before the June 2026 audit deadline?
Three gaps appear most consistently in organizations preparing for their first SZTFH audit. First, security class classification has not been completed, which means organizations cannot proceed with auditor contracting and do not know which NIST SP 800-53 controls apply to their systems. Second, asset inventories do not reflect the full scope of electronic information systems in scope under Hungary's broader-than-NIS2 definition, particularly cloud workloads and systems managed by third-party service providers. Third, incident reporting procedures have not been tested against the specific timelines and content requirements under the 2024 Cybersecurity Act, which differ from generic GDPR breach notification procedures.
How does Hungary's compliance framework differ from standard GDPR compliance programs?
Hungary's Act LXIX of 2024 operates independently of GDPR and covers organizational security obligations that go beyond data protection. The SZTFH enforces the Cybersecurity Act. The NAIH (National Authority for Data Protection and Freedom of Information) enforces GDPR. These are separate enforcement tracks with different timelines, different evidence requirements, and different penalty structures. Organizations that run a single compliance program covering both typically have adequate documentation for GDPR purposes and significant gaps under the Cybersecurity Act, particularly around system classification, mandatory audit completion, and incident reporting to the SZTFH rather than the NAIH.
What personal liability does Hungary's 2024 Cybersecurity Act impose on managers?
Act LXIX of 2024 introduces personal manager liability for cybersecurity failures, a significant departure from the 2023 Act. Managers of covered entities can face personal consequences for failure to implement required security measures, not just organizational fines. Organizational fines can reach up to the equivalent of approximately EUR 10 million or a percentage of global revenue. The designation of a person responsible for electronic information systems security is a mandatory requirement under the Act. Organizations that have not formally assigned this role have a compliance gap that applies from January 1, 2025.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.