Austria extends the EU implementing regulation to every NIS2 sector

What happened

The Austrian supervisor made its first ordinance, and it did not wait. The Netz- und Informationssystemsicherheits-Verordnung — NISV 2026 — was promulgated as BGBl. II Nr. 290/2026 on 1 October 2026, the same day the NISG 2026 entered into force. Under its section 9 it takes effect at the end of its day of promulgation, so it has applied since today.

It is a short instrument: nine sections, made under two enabling provisions of the act, sections 32(5) and 35(3). Those are the two powers we flagged as open when the act arrived — one to set the detail of the risk-management measures, one to add criteria for what counts as a significant incident. Both have now been exercised at once.

Section 2 is the part that changes work already planned

Commission Implementing Regulation (EU) 2024/2690 is the most concrete thing the Union has published on NIS2 measures: an annex of technical and methodological requirements, control by control. It also has a narrow addressee list. In Union law it binds DNS service providers, TLD name registries, cloud and data centre providers, content delivery networks, managed service and managed security service providers, online marketplaces, search engines, social network platforms and trust service providers. Nobody else.

Austria has just made it apply to everybody in scope.

Read plainly: the EU annex is the Austrian standard of detail, for every type of essential and important entity in annexes 1 and 2. An energy utility, a hospital, a water operator, a rail undertaking, a food manufacturer or a public administration body in Austria is now held to the same requirements as a cloud provider, because the ordinance says the requirements written for the one are applicable also to the types the regulation does not cover.

This matters because of what guidance still says. The WKO overview, the most widely read Austrian summary, introduces those technical requirements as something that exists "für digitale Sektoren". That was a correct description of the regulation. It is no longer a correct description of Austrian law. An entity outside the digital sectors that read the implementing regulation and concluded it was reading somebody else's homework was right until yesterday.

The practical consequence is a scoping exercise, not a new policy. If you had built against the ten lettered measures of section 32(4) and stopped there, the annex is now the level of granularity you will be measured at, and the self-declaration due on 30 September 2027 is where you say so.

Four risk categories, named

Section 3 does something small and useful. It names the risk categories a risk analysis must at least be oriented to, and must take into account in the risk management process: technological risks, human risks, ICT supply chain risks, and location-related risks to network and information systems.

Three of those are standard. The fourth is the one most risk registers quietly omit: location-related risk to the systems themselves — where the racks are, what shares the building, what the site depends on. If your risk analysis has no physical dimension, it is now short of a category the ordinance names.

The compensating-measures route, and its limit

Section 4 is the proportionality valve, and it is drafted narrowly enough to be worth quoting in substance rather than paraphrasing loosely. Compensating measures must be implemented where an entity cannot meet individual requirements of section 2 — either temporarily, or because of its size. They must be suitable to serve the purpose of the requirement and to minimise the associated risks, on the basis of a risk assessment. Their implementation must be documented traceably and with reasons. Their effectiveness must be reviewed at regular intervals, and at least annually.

Two things follow that are easy to get backwards. First, this is not an opt-out: it converts an unmet requirement into a documented, annually reviewed alternative, which is more work than the requirement in some cases, not less. Second, there is a carve-out from the carve-out — section 4(4) says no compensating measure is owed for requirements the annex itself qualifies as due only so far as appropriate, applicable or feasible. Where the annex already bends, you do not owe a substitute for the bend.

Nine thresholds that start the 24-hour clock

Sections 5 to 7 answer the question every incident runbook needs answered before an incident, not during one: is this notifiable? The nine criteria of section 5(1) are alternatives — one is enough. An incident is significant where it has caused, or is capable of causing, any of the following.

• A direct financial loss above EUR 500 000 or 5 per cent of the entity's total annual turnover in the preceding financial year, whichever is lower.
• The leak of the entity's trade secrets within the meaning of section 26b of the UWG, or of information subject to secrecy under section 6 of the Informationsfreiheitsgesetz.
• The death of a natural person.
• Serious damage to a natural person's health.
• A successful, presumably malicious and unauthorised access to network and information systems that is likely to cause serious operational disruption.
• The repeated-incident case of section 7.
• An outage or restricted availability of the entity's services for more than 100 000 users or 10 per cent of users, whichever is lower, for more than 24 hours.
• An outage or restricted availability for users in the territory of at least one Bundesland for more than 24 hours.
• The activation of crisis management or of business continuity disaster recovery plans.

Note which way the two-term tests run. In both, the lower figure governs. A mid-sized Austrian entity will cross 5 per cent of turnover long before EUR 500 000, and 10 per cent of its users long before 100 000 of them. Reading those criteria as large absolute numbers gets the threshold backwards for exactly the entities most likely to be reading them.

Restricted availability is defined rather than left to judgement: it exists in particular where a service cannot be provided to the extent regularly to be expected. Degraded is not merely down.

And the last criterion deserves to be read twice, because it is procedural rather than substantive. Activating crisis management or disaster recovery is itself a criterion. An organisation that invokes business continuity, works through the night, restores service and then concludes that no threshold was crossed has already crossed one.

Two limits in the other direction

Section 6 excludes planned operational interruptions, and the planned consequences of planned maintenance carried out by or on behalf of the entity. A maintenance window is not an incident.

Section 7 is the aggregation rule, and it is tighter than it first looks. Incidents that are not individually significant count together as one significant incident only where all three conditions hold: they occurred at least twice within six months, they have the same apparent cause and effect, and taken together they meet the financial criterion of section 5(1)(1). Not any of the nine — the financial one specifically. A series of small outages that never touches the money test does not aggregate into a notifiable event under this rule.

What this ordinance is not

It is not the registration ordinance. Austrian guidance has been saying for weeks that the form of registration remains to be fixed by ordinance, and it still says so today.

The word Registrierung does not appear once in the NISV 2026. Registration is live, the channel is the NIS2 Services application in the Unternehmensserviceportal, and the first filing is due by 4 January 2027 — but the prescribed content of that filing is still unpublished. Register anyway, and expect a second ordinance.

What to do with this in the next fortnight

Three concrete things, in order of how badly they go wrong if skipped. Map the annex of Implementing Regulation (EU) 2024/2690 against what you actually have, whatever sector you are in — not the ten lettered measures, the annex. Where you cannot meet a requirement, start the section 4 documentation now rather than at declaration time, because it has to carry a reason and an annual review. And rewrite the notification trigger in your incident procedure against the nine criteria, with the turnover and user percentages computed for your own figures, so that the person on call at 03:00 is comparing against a number and not against a concept.