Austria publishes the reasoning behind its NIS2 ordinance

What happened

On 2 October we published the NISV 2026 — Austria's first ordinance under the NISG 2026, in the gazette as BGBl. II Nr. 290/2026 — and ended that piece with a warning that the supervisor's own legal page did not list it. The gazette was ahead of the guidance, and an entity reading only the authority's site would not have known that a binding ordinance applied to it.

That is no longer true, and the correction is worth making as plainly as the warning was. Read today, the Recht und Dokumente page of the Bundesamt für Cybersicherheit carries the NISV 2026 among its legal bases, with the RIS link to BGBl. II Nr. 290/2026 and, beside it, the explanatory notes to the ordinance as a PDF — along with the explanatory notes to the act. The FAQ page, which records its own last update as 20 October 2026, now has a NISV 2026 section with entries on sections 2, 3, 4, 5 and 7.

The FAQ is explicit about its own limits, which is a good sign rather than a bad one.

It then sends you to the explanatory notes. So that is where the substance is, and that is what the rest of this piece is about: seven pages that settle four questions the ordinance leaves implicit.

First: who does not have to read the annex at all

Section 2 of the NISV 2026 extends the technical annex of Implementing Regulation (EU) 2024/2690 to every type of essential and important entity in annexes 1 and 2 of the act. That is the change we called the one that reorganises work already planned, and it stands. What the notes add is the boundary.

The section 32 requirements — and therefore the ordinance made under them — do not apply so far as an entity is obliged to take cybersecurity risk-management measures by sector-specific Union law that secures an at least equivalent level of cybersecurity. That is section 27 of the NISG 2026 and article 4 of the directive, and the notes name the case that matters: DORA expressly applies as such a sector-specific act for financial entities that are essential or important entities.

A bank, insurer or market infrastructure already running DORA is not mapping the annex a second time. That was arguable from the act; it is now written down by the authority that will supervise it.

Second: the nine thresholds are addressed to the non-digital sectors

This is the most consequential sentence in the document, and it is a reading rather than a rule. Section 5(1) of the ordinance says only that an incident counts as significant "in Bezug auf die betreffenden Einrichtungen" — in relation to the entities concerned. It does not say which. The notes do.

And in the general part: the provisions of the implementing regulation, and its application to the entities that fall under it, remain unaffected by the criteria this ordinance sets.

On that reading there are two notification threshold sets in Austria, not one. A cloud, DNS, data centre, managed service or marketplace provider stays on article 3 of the implementing regulation. Everybody else — energy, transport, health, water, manufacturing, public administration — uses the nine criteria of section 5. An entity that is both, which is not rare, needs to know which of its services puts it in scope of what.

Third: size is a reason, not an excuse

Section 4 lets an entity implement compensating measures where it cannot meet individual requirements of section 2 temporarily or because of its size. The text says nothing about how size is measured, or how temporary is temporary. The notes answer both.

Size is tied to the size categories of section 25 of the NISG 2026 — micro, small, medium and large, by headcount and annual turnover or balance sheet total — and existing organisational complexity, such as operating across several sites, may be taken into account. The temporary case is given concrete examples: the timetable of a procurement procedure for the products or services you need, or a long-running implementation project such as replacing a control system. Those are recognisable constraints, not excuses, and naming them is useful.

Then the door closes.

Read that twice if you were planning to be small. Your protection need is not derived from your size, and size is not a blanket argument. What the route gives you is a documented, annually reviewed alternative that serves the purpose of the requirement as far as possible — the notes are clear that compensating measures are not held to the same standard as the requirement itself, and equally clear that outside the two cases they do not satisfy section 2 at all.

One genuine relief sits in section 4(4), and the notes make it plainer than the text does. Where the annex itself says a requirement applies only so far as appropriate, applicable or feasible — and it says so often, in sub-requirements like 1.1.2, 1.2.5 and 3.2.2 — documenting your reasons in a comprehensible way is enough. No compensating measure is owed for a bend the annex has already built in. That is comply-or-explain, and explaining is the whole of the obligation.

Fourth: what counts as a financial loss

The EUR 500 000 or 5 per cent criterion is the one most likely to be argued about after an incident, so the inclusion list matters. The notes say an entity should take into account all financial losses incurred as a result of the incident:

• replacing or relocating software, hardware or infrastructure;
• staff costs, including replacing or relocating staff, hiring additional staff, overtime, and restoring lost or impaired competences;
• fees for failing to meet contractual obligations;
• compensation and indemnity payments to customers;
• lost revenue;
• internal and external communication costs;
• consultancy costs, including legal advice, forensic services and remediation services.

And what does not count: fines, and the costs needed to run the business as usual — general maintenance of infrastructure, equipment, hardware and software, ongoing staff training to keep competences current, the internal or external cost of strengthening the business after the incident including upgrades, improvements and risk-assessment initiatives, and insurance premiums. Where the actual figure cannot be determined, estimate it.

The asymmetry is the point. The money you spend becoming more resilient after an incident does not push you over the threshold; the money the incident took from you does. An organisation that books its post-incident hardening into the incident cost will overstate the loss, and one that forgets lost revenue and contractual penalties will understate it.

The turnover half of the test has a defined denominator too: the annual total turnover by reason of which the entity falls within scope, under section 25(1) of the act applying the EU SME definition of Recommendation 2003/361/EC, with the exception of article 3(4) of its annex.

Users, geography, and what "restricted availability" means

Two of the nine criteria count users, and the notes define the word. Users are in particular those who actually use the entity's services, or whose use is concretely planned or already initiated — for a health care entity, that includes people admitted or registered during the incident. A merely abstract possibility of using your service in future does not count. Nor is the Bundesland criterion territorial: it is assessed on the number of users in that Bundesland, so far as attributing them to it is factually possible.

Restricted availability gets a sharper edge than the ordinance gives it.

Noticeably slower than your average response time, or missing some functions, for more than 24 hours, across enough users. If you have no baseline response time, you have no way to apply that test — which makes the baseline an incident-reporting prerequisite, not a performance nicety.

One criterion gets a probability standard. For the unauthorised-access case of section 5(1)(5), the notes say it is not enough that serious operational disruption be possible: it must be probable, which they define as more reasons speaking for it than against, judged by an objective third party on the known facts and in the ordinary course of events.

Repeated incidents: the same effect, not just the same cause

Section 7 aggregates individually insignificant incidents only where they share the same apparent cause and effect. The notes say what can indicate that: the same threat actor, the same modus operandi, the same attack vector, the same point in time, the same kind of affected asset, or the same attack target. They also give the reason the rule exists — repeated incidents can point to real deficiencies in the risk-management process and to the entity's cybersecurity maturity.

Note what that does to incident records. You cannot apply a six-month aggregation rule across threat actors and attack vectors unless you have been recording them in a form you can compare.

Two procedural points, easy to miss

A report under section 34 may be filed by a third party on the entity's behalf where the authority to represent it exists. If an incident response retainer is going to notify for you, the representation needs to be in place before the 24-hour clock starts, not negotiated during it.

And a report can be withdrawn. Where an entity notifies and the conditions of section 35 turn out not to be met, the notes say it is, where applicable, to make that withdrawal known when it updates its information under section 34(2)(2). Over-reporting in the first 24 hours is therefore correctable, which is an argument for notifying on a reasonable suspicion rather than waiting for certainty.

What the ordinance does not displace

The notes close the general part by recording that other reporting duties stand, and name two: the Resilienz kritischer Einrichtungen-Verordnung, BGBl. II Nr. 91/2026, and section 123(4) of the TKG 2021, under which providers must immediately inform the regulator, affected holders of emergency number allocations and affected emergency call answering points of incidents with considerable effects on the reachability of emergency numbers. An Austrian entity can owe three notifications for one event.

What to change this week

If you are in a financial sector entity running DORA, record the section 27 carve-out in your scoping file with the citation, and stop treating the annex as a second workstream. If you are anywhere else, check which threshold set your incident procedure is written against — the nine criteria, or article 3 of the implementing regulation — and fix it if the answer is "both, vaguely". Establish and record an average response time per service, because one of the nine criteria cannot be applied without it. Where you have invoked section 4, write the reason and the annual review date into the document now rather than at self-declaration time; the declaration is due on 30 September 2027 for entities in scope at entry into force, and the notes make clear the documentation is what the authority will examine. And if an external party may notify on your behalf, put the representation in writing before you need it.