NISG 2026: Austrian Cybersecurity Duties and NIS2 Consulting in Vienna

#NISG 2026 is in force: what businesses need to establish

The main provisions of Austria’s Network and Information Systems Security Act 2026, or NISG 2026, have applied since 1 October 2026. The act implements NIS2 in Austria. Entities within scope face registration, management responsibility, proportionate security measures, evidence requirements and timely reporting of significant cyber incidents. The competent authority is the Federal Office for Cybersecurity. Austria’s Interior Ministry confirms the start date and the NIS2-Services application.

Businesses searching for NIS2 Wien or NIS2 Beratung need three practical answers: Is this particular entity covered? Which duties and dates apply? Who will implement the measures and produce the evidence?

This guide connects the legal framework with a technical implementation plan for businesses in Vienna and Austria. Legal statements were checked against RIS and the authority’s publications on 21 October 2026. The article and tool provide orientation; individual legal assessment and an administrative classification remain separate tasks.

Start with the free NISG 2026 six-question scope check. The result is visible without email and can be saved. The German guide is available for Austrian teams working in German.

#NIS2, NISG 2026 and NISV 2026: three layers

NIS2 is EU Directive 2022/2555. NISG 2026 is Austria’s implementing act, published as Federal Law Gazette I No. 94/2025. NISV 2026 specifies requirements and significant-incident criteria; published as Federal Law Gazette II No. 290/2026, it entered into force on 2 October 2026. The primary texts are the NISG in RIS and the NISV in RIS.

Implementation therefore needs to account for the relevant regulation as well as the act. Section 2 NISV extends the detailed risk-management requirements in Implementing Regulation (EU) 2024/2690 to additional covered entity types. Section 4 addresses justified and documented compensating measures. A fixed shopping list of security products cannot replace a risk-based assessment.

Vienna does not have a separate NIS2 size threshold. Location matters for jurisdiction, coordination and delivery. Legal classification follows the Austrian framework and any relevant European sector rules.

#Who is covered by Austria’s NISG 2026?

The basic assessment connects actual activity, company size, special cases and jurisdiction. It then distinguishes essential from important entities. Both groups have security and reporting obligations; supervision and sanctions differ. The starting point is section 24 NISG 2026.

#Match the activity to a specified entity type

Annex 1 covers energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, B2B ICT service management, public administration and space. Annex 2 covers postal/courier services, waste management, chemicals, food, selected manufacturing, providers of digital services and research.

A sector heading is only the beginning. The exact entity description, sometimes a specified NACE code, and particular activity conditions determine the mapping. Running an online shop does not automatically make a business an online marketplace. A secondary activity can also matter, while certain categories explicitly refer to a principal activity. The authority’s sector FAQ explains these distinctions.

Working example: A Vienna software company should record more than “IT.” Does it develop software, or also continuously administer customers’ applications and systems? Contracts, service descriptions, access rights and operating responsibility help establish the appropriate classification.

#The financial size test contains an AND

Section 25 NISG 2026 establishes these thresholds:

The staff route and financial route are alternatives. Within the financial route, both thresholds must be exceeded. The incorporated EU SME rules govern the calculation, including annual work units and the applicable accounting periods.

Data from partner and linked enterprises may need to be added. The section 25(4) exception requires organisational, technical and operational independence of the relevant network and information systems. A separate company name or legal entity does not establish that independence.

Working example: With 35 staff, €13 million turnover and an €8 million balance sheet, the financial medium-size test alone is not met. Group data and special cases still need assessment.

#Smaller organisations can also be covered

DNS service providers, TLD registries and qualified trust service providers can be essential regardless of size. Public electronic communications networks/services and other trust service providers also have special rules. Administrative designations and entities identified as critical need separate consideration.

Domain registrars and certain resellers have their own duties, particularly under sections 29 and 30. This alone does not establish the full essential/important duty package. Owning a corporate domain does not make a business a DNS service provider.

#Groups, public bodies and DORA need specific treatment

For certain digital services, section 28 uses main-establishment rules. Public telecom services have rules tied to providing services in Austria. Having an Austrian customer therefore does not establish Austrian jurisdiction in every case.

Public administration, education and section 24(6) exclusions need a tailored assessment. DORA also requires a duty-by-duty analysis: sector rules may displace risk-management or incident-reporting provisions while registration remains relevant. The authority’s current interpretation appears in its sector FAQ.

#The checker: six questions and an explained result

The tool below helps identify the next assessment task. It evaluates your selections in the browser. It requests no exact financial figures or documents and does not inspect systems or verify implementation. An unresolved answer remains unresolved in the result.

#What must a covered business organise?

#Registration and assigned responsibility

Essential and important entities, as well as domain-registration service providers, must address the applicable register duties. For entities already covered on 1 October, the authority gives 4 January 2027 as the latest initial registration date. Entities meeting the criteria later generally have three months. Changes to registered information must be reported within two weeks or three months, depending on the item. Source: BCS registration guidance.

In practice, organise USP access, ID Austria, permissions, a responsible person and a substitute. Registration should not fail because only one unavailable employee holds the necessary rights. The authority operates the register; commissioning a consultant does not itself submit the registration.

#Management and training

Section 31 NISG 2026 requires management bodies to ensure and supervise compliance with risk-management measures. Management must attend specifically designed cybersecurity training. Staff must regularly be offered appropriate training.

For implementation, we recommend an accountable decision-maker, regular risk reporting and recorded approvals. External IT can help execute the work. Decisions about accepted risks and resources still need to be traceable within the organisation.

#Ten areas of security measures

Section 32 requires suitable and proportionate technical, operational and organisational measures. The areas include risk analysis, incident handling, business continuity/backups, supply-chain security, secure procurement/development, effectiveness assessment, cyber hygiene/training, cryptography, personnel/access/asset management, and MFA/secure communications. The authority explains these measure areas.

Each practical measure should connect to a system, an owner and verifiable evidence. The following are AppWebSeo technical working examples, rather than an exhaustive legal control catalogue:

#What constraints does this place on IT and business decisions?

NISG 2026 does not establish a general ban on particular cloud services, frameworks or automation tools. It requires assessment and management of relevant risks. Depending on the environment, this changes procurement, development, outsourcing and operations.

New suppliers: Before switching a provider, establish which critical data and processes depend on it, how access works and what evidence supports its security arrangements. Missing information becomes an explicit decision to resolve before rollout.

Product changes: A CRM integration, customer portal or AI assistant may introduce new permissions, data flows and dependencies. The project needs time for security assessment and testing. Our work on ERP/CRM integrations and web architecture can fit within this bounded technical scope.

Legacy systems: When a requirement cannot temporarily be met, the approach needs assessment and justification. Compensating measures under NISV are not permission to ignore the issue indefinitely. Document the rationale and assess effectiveness.

Supplier relationships: Directly covered organisations must consider risks involving immediate providers. Small suppliers may consequently receive questionnaires, contractual requirements or requests for evidence. These indirect demands need to be distinguished from the supplier’s own statutory coverage.

#Registration, self-declaration and incident deadlines

The conditions are set out in the registration guidance, evidence FAQ and section 33. Existing administrative decisions and transitional cases also require review.

Following a section 33(2) request, essential entities must provide organisational and operational evidence within two months; the technical evidence period is generally two years. Important entities generally have two years for both areas, and the request requires substantiated indications of suspected infringements. The BCS independent-verification page explains the distinction. Maintaining the organisational evidence package continuously makes the shorter response period more manageable.

#A different clock runs for significant incidents

Covered entities must report significant incidents affecting a service to the competent CSIRT without delay: early warning no later than 24 hours, notification generally no later than 72 hours after awareness. Trust services have a special 24-hour notification rule. A final report is normally due no later than one month after notification. Ongoing handling requires progress reporting and subsequent final reporting; interim reports may be requested. Other duties, including GDPR notifications, need separate assessment. Source: BCS incident reporting and deadlines.

Significance requires assessment. Section 35 NISG and NISV set criteria; potential severe effects can matter as well as confirmed damage. Do not wait for a completed forensic report before preparing the reporting decision for a potentially significant incident.

A useful operational fact: Having a backup does not establish whether the application can restart in time. A rehearsed restore offers a stronger planning basis than a “backup successful” status alone.

#What consequences can follow a breach?

For specified infringements by essential entities, section 45 NISG provides a maximum fine of €10 million or 2% of the relevant worldwide turnover in the preceding financial year, whichever is higher. For important entities, the maxima are €7 million or 1.4%. Certain organisational infringements can attract up to €50,000, rising to €100,000 for repeated infringements. These are ceilings; the actual penalty depends on the offence and statutory assessment rules.

The authority can require information and corrective measures and perform inspections. Essential entities can face further enforcement measures under the statutory conditions. Restrictions on management functions, for example, require their own legal assessment. Source: BCS enforcement guidance.

Operational consequences also matter: downtime, recovery costs, delays in customer assessments and contract disputes. These can affect a supplier even when it is not directly regulated. Personal liability depends on specific duties, conduct and other applicable rules; being a managing director does not automatically create a personal multi-million-euro fine.

#How AppWebSeo can help with NIS2 in Vienna

Our contribution concerns technical discovery, implementation and documentation for web platforms, applications, integrations and their operation. The introductory conversation establishes whether your needs fit that scope. Individual legal advice, administrative decisions and independent verification under section 33 must be handled separately by the appropriate professionals or bodies. We do not claim accreditation or certification for those roles.

#Record scope and responsibility

We structure the available information: entity, services, critical applications, hosting, data flows, providers and existing assessments. The output is a scope record with open legal/technical questions, owners and an evidence request list. Final legal classification remains with qualified legal advisers or the authority.

#Prioritise technical gaps

After agreement on a specific assessment brief, we examine the relevant applications and workflows: accounts, permissions, deployment, dependencies, backups, logging and integrations. Each finding receives a risk statement, action, owner and acceptance criterion. Access rights, test boundaries and methods are agreed first.

#Implement and test measures

Work proceeds in bounded packages, such as access-role cleanup, API safeguards, secrets management, an update process or a restore test. A completed package contains changes, test evidence and remaining limitations. Effort and dates depend on the systems and starting position and are agreed after discovery. Our discovery and scope-definition process provides the basis.

#Hand over evidence and operating tasks

We assemble technical evidence, operating instructions, recurring checks and open issues. Your internal team can use these for governance, supplier responses, self-declaration preparation and cooperation with independent assessors. Acceptance by an assessor cannot be guaranteed.

Request NIS2 technical support: Discuss next steps with AppWebSeo. Bring the entity name, key services and known open questions to the initial conversation. Credentials, vulnerability reports and sensitive documents should stay out of the initial enquiry.

#A realistic plan for the next 30 days

This is a suggested work plan, not a statutory 30-day deadline or a promise of complete compliance within a month.

1. Assign responsibility: Management appoints an internal lead and substitute, involving existing legal, IT and security owners.
2. Document scope: Record activity, size calculation, group relationships, special rules and jurisdiction with supporting evidence. Obtain professional input on unresolved points.
3. Prepare filing: Check USP, ID Austria, registration data and permissions. The responsible person confirms the deadline and submission route.
4. Inventory operational risks: Record critical applications, data, access and suppliers in a manageable register.
5. Review initial controls: Inspect privileged access, recovery arrangements, update responsibility and escalation contacts.
6. Rehearse the incident path: Use a scenario to establish who assesses significance, reports, substitutes and preserves evidence.
7. Approve implementation: Adopt a prioritised backlog with acceptance criteria, budget, owners and review dates.

Use the scope, actions and evidence working template to support the discussion. It is available without registration.

#Frequently asked questions about NIS2 support

#Are businesses with fewer than 50 staff automatically exempt?

No. Financial criteria, group calculation and size-independent entity types may still matter. The checker treats these separately and does not issue a confident clearance when relevant information is missing.

#Does ISO 27001 automatically establish NISG compliance?

A suitable, valid certificate can support organisational and operational evidence. Its scope, technical verification and other duties need separate consideration. Certification does not automatically replace registration or incident reporting. See the authority’s evidence FAQ.

#Can we wait until 2028?

The earliest request for independent evidence under section 33(2) is a separate milestone. Security, governance, registration and reporting duties must be considered independently. The later evidence date is not a general permission to postpone work.

#A customer requests NIS2 evidence. Does that make us directly covered?

Not by itself. Assess your own statutory scope separately from the contractual request. A useful supplier response identifies which systems/services are covered, what was tested and what limitations remain.

#What will technical support cost?

A reliable price requires a defined scope: number and type of systems, access, existing documentation, assessment depth and implementation needs. The initial conversation identifies the requirement; a concrete scope, price and acceptance conditions can follow. A broad compliance guarantee cannot replace this discovery.

#Sources and maintenance

Research date: 21 October 2026. We researched the intents “NISG 2026,” “NIS2 Wien” and “NIS2 Beratung” and checked legal statements against primary sources. The legal texts govern, supplemented by current authority guidance. Where older FAQs and newer guidance show different registration dates, we use the registration page updated on 2 October with its explicit calculation. Changes in legislation, regulations or administrative practice require a fresh assessment.

• NISG 2026: consolidated act and annexes in RIS
• Section 24: essential and important entities
• Section 25: company size
• Section 31: governance
• Section 33: evidence
• Section 45: administrative fines
• NISV 2026: current implementing regulation
• BCS: registration
• BCS: sectors and special cases
• BCS: incident reporting and deadlines
• BCS: evidence and self-declaration
• BCS: independent verification