NIS2: Security Incident Reporting Obligations at a Glance

The Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026, Austrian Network and Information Systems Security Act 2026, BGBl. I No. 94/2025) transposes the NIS2 Directive in Austria. It was promulgated on December 23, 2025, and its obligations have applied since October 1, 2026 (§ 51 para. 2: nine months after promulgation, on the first day of the following month).

The reporting obligation under § 34 applies to essential and important entities. Who qualifies is governed by § 24 (classification), § 25 (company size), and § 26 (size-independent classification), together with the sectors in Annexes 1 and 2.

Even organizations that are not covered by the law can voluntarily report cybersecurity incidents, cyber threats, and near misses to the national CSIRT (§ 37 para. 2), anonymously if they wish (§ 37 para. 3).

You must report every significant cybersecurity incident. A cybersecurity incident is an event that compromises the availability, authenticity, integrity, or confidentiality of data or services (§ 3 no. 30). Under § 35 para. 1, it is significant if it

• has caused or is capable of causing severe operational disruption of the services or severe financial losses for the entity, or
• has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

The assessment takes into account, among other things, the dependence of other sectors on your service, possible effects on the environment, public safety, and health, your market share, the geographic area affected, and the systems affected (§ 35 para. 2). The cybersecurity authority has set out more detailed criteria in the NISV 2026 (§ 35 para. 3; BGBl. II No. 290/2026, in force since the end of October 1, 2026). According to the explanatory notes of the Federal Office for Cyber Security (Bundesamt für Cybersicherheit), its § 5 applies to entities in sectors outside Implementing Regulation (EU) 2024/2690. Under it, an incident is significant in any case if it

• has caused or is capable of causing a direct financial loss exceeding €500,000 or 5% of annual turnover in the previous financial year, whichever is lower (§ 5 para. 1 no. 1 NISV 2026),
• has caused or is capable of causing the leakage of trade secrets (§ 26b UWG, Austrian Unfair Competition Act) or of information that must be kept secret under § 6 IFG (Austrian Freedom of Information Act) (no. 2),
• has caused or is capable of causing the death of a person or serious damage to a person's health (no. 3 and 4),
• involves successful, suspected malicious, and unauthorized access to network and information systems that is likely to cause severe operational disruption (no. 5),
• causes or is capable of causing the services to fail or be restricted for more than 100,000 users or 10% of users, whichever is lower, or in the territory of at least one federal state for more than 24 hours (no. 7 and 8),
• has triggered crisis management or disaster recovery plans of business continuity management (no. 9), or
• counts as a recurring incident: at least twice in six months, with the same apparent root cause and impact, and together above the loss threshold from no. 1 (no. 6, § 7). Scheduled maintenance does not count as a significant incident (§ 6).

For DNS service providers, TLD name registries, cloud and data center service providers, content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers, Implementing Regulation (EU) 2024/2690 sets specific thresholds, such as a direct financial loss exceeding €500,000 or 5% of annual turnover, whichever is lower (Art. 3(1)(a)). Scheduled maintenance work does not count as a significant incident (Art. 3(2)).

• The deadlines run from becoming aware of the significant incident, not from when it began.
• Trust service providers report incidents affecting their trust services within 24 hours instead of 72 (§ 34 para. 2, sentence after no. 5).
• You must provide all information that enables the CSIRT and the authority to assess cross-border impact (§ 34 para. 2).
• The CSIRT responds no later than 24 hours after receiving the early warning with initial feedback and, on request, guidance on mitigation measures (§ 34 para. 4).

Reports go to the sector-specific CSIRT responsible for you or, if there is none, to the national CSIRT. The CSIRT forwards the report to the cybersecurity authority without undue delay (§ 34 para. 1). The competent authority is the Federal Office for Cyber Security (§ 3a para. 1).

• Public administration: GovCERT as the sector-specific CSIRT (§ 8 para. 4).
• Healthcare: Austrian HealthCERT (§ 8a para. 3 Gesundheitstelematikgesetz 2012 (GTelG 2012, Austrian Health Telematics Act 2012), as amended by BGBl. I No. 94/2025).
• Other sectors: the sector-specific CSIRT; as long as none exists, the national CSIRT (§ 8 para. 3). Until a national CSIRT is authorized under the new law, for no more than two years, the previously authorized national CSIRT performs these tasks (§ 51 para. 6).

The cybersecurity authority publishes which CSIRTs are authorized (§ 8 para. 5). Record the reporting address and reporting channel before you have to look for them during an incident.

If the incident affects your services, inform the recipients of your services without undue delay and, where possible, name measures they can take themselves (§ 34 para. 3).

If personal data is affected, the General Data Protection Regulation also applies: the controller notifies the supervisory authority of the breach without undue delay and, where feasible, within 72 hours, unless it is unlikely to result in a risk to the rights and freedoms of natural persons (Art. 33(1) GDPR). In Austria, this is the Austrian Data Protection Authority (Datenschutzbehörde) under § 18 para. 1 DSG (Austrian Data Protection Act).

Two reports, two recipients: the NIS2 report goes to the CSIRT, the data protection notification to the Data Protection Authority. Check both for the same incident.

• The competent CSIRT and the reporting channel are defined and documented (§ 34 para. 1).
• The people responsible for reporting, including deputies, are named and reachable outside office hours.
• The criteria from § 35 are applied to your services: which outages, damage, or data leaks trigger a report?
• The time of becoming aware is recorded immediately during an incident, because the 24 and 72 hours run from that point.
• Templates for the early warning, notification, and final report contain the content required by § 34 para. 2.
• An incident log is planned: timeline, decisions, affected systems, indicators of compromise.
• Informing the recipients of your services under § 34 para. 3 is prepared: who, to whom, and through which channel.
• Data protection is involved; the review under Art. 33 GDPR runs in parallel.
• IT service providers and suppliers pass on incidents that affect you without undue delay; this is governed by contract.
• The reporting chain is practiced regularly, for example as a tabletop exercise with management, IT, and communications.

This checklist is a TOMORIS recommendation for preparation. The law prescribes the deadlines, content, and recipients of the reports (§ 34 NISG 2026).

Anyone who breaches the reporting obligation, including the reporting duties (§ 34 para. 1 and 2), or the obligation to inform the recipients of the services (§ 34 para. 3) commits an administrative offense (§ 45 para. 1 no. 4 and 5).

• €10 millionEssential entity

  or 2% of the company's total worldwide annual turnover in the previous year, whichever is higher (§ 45 para. 2).

• €7 millionImportant entity

  or 1.4% of the company's total worldwide annual turnover in the previous year, whichever is higher (§ 45 para. 3).