NISG 2026: Austria's NIS2 deadlines from 1 October

Austria's Network and Information System Security Act 2026 enters into force on 1 October 2026, nine months after its publication. From that day, deadlines run that cannot be extended: three months to register, twelve months to file the self-declaration. Anyone who starts collecting evidence once the authority asks will be describing the state of yesterday.

What the NISG 2026 requires from 1 October

The NISG 2026 transposes Directive (EU) 2022/2555 into Austrian law, and it applies from the day it enters into force, not from the day you register. It was published on 23 December 2025 as BGBl. I No. 94/2025, after the Nationalrat passed it on 12 December 2025 with the two-thirds majority its constitutional provisions require. Supervision and enforcement sit with the cyber security authority at the Ministry of the Interior.

Three deadlines shape the next twelve months:

• Registration: within three months of entry into force, so by the end of December 2026.
• Self-declaration: within twelve months of the registration obligation arising. The structured declaration covers the network and information systems in use, supply chain security and the results of the risk analysis. What is new is that it is due on a fixed deadline rather than on request.
• Incident reporting: an early warning without undue delay and within 24 hours at the latest, a full notification within 72 hours, and a final report within one month.

Penalties follow the directive: up to 10 million euros or 2 per cent of global annual turnover for essential entities, up to 7 million euros or 1.4 per cent for important ones. Accountability sits with the management body, not with the IT department.

Who is affected in Austria

You are affected if you operate in one of the directive's 18 sectors and meet the size thresholds: as a rule from 50 employees or 10 million euros in turnover, and in some sectors regardless of size. The act distinguishes between essential and important entities, which determines both supervisory intensity and the maximum penalty. The glossary entry on the NIS2 directive sets out the classification in detail.

Nobody makes that assessment for you. There is no official notice establishing that you are in scope and no letter marking the start: the assessment itself is part of the obligation. That is where companies which do not think of themselves as critical tend to fail — suppliers in manufacturing, for instance, or operators running data centre services for others.

In Germany the deadline has already passed

Germany went down the same road nine months earlier. The NIS2 implementation act entered into force on 6 December 2025, the BSI registration portal has been live since 6 January 2026, and the original registration deadline of 6 March 2026 was extended to 31 July 2026. That date has passed; anyone not registered by now risks supervisory measures regardless of whether an incident has ever occurred.

For companies with sites in both countries this means two registrations, two authorities and two reporting paths. The technical evidence underneath can be the same, provided it is built from the start to serve both supervisory logics.

Where the self-declaration comes unstuck

The self-declaration does not ask for intentions, it asks for results. Three of its elements are the hardest to produce in practice, because they do not come from a document but from a running process.

The inventory. Which systems are reachable from the internet, running which services, since when? A list from the last audit describes a state that no longer exists: subdomains get created, test environments stay open, cloud resources appear without a ticket.

Vulnerability handling. Article 21(2) of the directive explicitly names vulnerability handling and disclosure. You cannot evidence that with scanner output alone; you evidence it with a chain: found on, assessed by, decided by, fixed by. An annual penetration test gives you a snapshot, not a chain.

The supply chain. The directive requires you to account for risks arising from relationships with suppliers and service providers. That includes incidents that happen at a supplier and only reach you through them — when their data shows up on a leak site, for example.

What you can prepare in the coming weeks

1. Assess and document whether you are in scope. Sector, size, classification, with a date and a rationale. A well-argued "no" is evidence too.
2. Name the accountable people. The management body is liable and must approve and oversee the measures.
3. Map the external attack surface. Not the systems listed in your documentation, but the ones that answer from outside.
4. Put deadlines on the vulnerability process. Who prioritises, by which criterion, within what time. Without a deadline it is a list, not a process.
5. Rehearse the reporting path. 24 hours is short if the question of who reports what to whom is only settled during the incident.

What blacklens.io contributes

blacklens.io provides the technical part of that evidence base: a continuously updated inventory of externally reachable systems with an exposure score, internal scans through the Sentry agent, cloud configuration and dark web findings in one shared findings workflow, plus a supplier watchlist that polls ransomware leak sites roughly every 30 minutes. Prioritisation draws on EPSS, the CISA KEV catalogue, available exploits and CVSS, so the reasoning behind an order of work is documented rather than reconstructed afterwards. Scheduled reports and CSV export hand those records, dated, to your ISMS or GRC system; which evidence maps to which requirement is set out on the NIS2 and vulnerability management page.

One detail that matters for Austrian entities: scanning runs exclusively from Austria, Germany and Switzerland, and the platform is hosted in ISO 27001 and SOC 2 certified data centres in the DACH region. None of this replaces a management system, and this article is technical orientation, not legal advice — which obligations apply to you specifically is a question for your legal team, your auditor or the authority. What blacklens.io adds is the part a document cannot provide: continuous vulnerability data instead of a snapshot.