NISG 2024 in Austria: What Public Contracting Authorities and IT Suppliers Must Do

NISG compliance Austria is now a live operational requirement for every public contracting authority and IT supplier working in the Austrian market. The Netz- und Informationssystemsicherheitsgesetz (NISG) transposes the European Union’s NIS-2 Directive into Austrian federal law, extending cybersecurity obligations to a far wider range of entities than the previous regime and placing new demands on how public tenders are drafted, how suppliers evidence their security posture, and how incidents are reported. For procurement teams, in-house counsel and vendors competing for public contracts, the practical consequences are immediate: tender documents must be updated, contract clauses must allocate cybersecurity risk clearly, and incident-reporting workflows must be mapped to the correct Austrian channels before the first qualifying incident occurs.

This guide sets out a must-do checklist covering scope, procurement updates, model contract clauses, supplier readiness and incident reporting.

The purpose here is practical rather than theoretical. Rather than summarising the legislation at a high level, this article focuses on what buyers and suppliers must change in documents and processes, with drafting prompts, a comparison table allocating responsibilities, and an incident-reporting workflow aligned to Austrian authorities. Where sample clause language appears, it is offered strictly as a drafting example for guidance only; local legal review remains essential before any clause is used in a live procurement. Because the Austrian transposition of NIS-2 has been subject to legislative delay, the exact title, numbering and entry-into-force date of the governing statute should be confirmed against the official text before relying on it.

Which organisations are in scope under the Austrian NIS-2 transposition?

The starting point for any NISG compliance Austria exercise is determining whether an organisation falls within scope. The Austrian transposition follows the architecture of the NIS-2 Directive (Directive (EU) 2022/2555), which significantly broadens the categories of regulated entities compared with the original NIS framework. Under the Directive, entities are classified as either essential entities or important entities, with differing levels of supervision and enforcement, but with substantially similar baseline obligations around risk management and incident reporting.

The broadened scope captures a wide range of sectors and organisation types. For Austrian procurement and supply arrangements, the entities most likely to be in scope include:

• Operators in highly critical and critical sectors. Entities providing services critical to the functioning of society and the economy, such as energy, transport, banking, drinking water and healthcare providers.
• Digital service providers and digital infrastructure. Cloud computing service providers, data centre operators, managed service providers and managed security service providers, categories that capture many IT suppliers bidding for public contracts.
• Public administration entities. Certain public-sector bodies are brought within scope, meaning contracting authorities themselves may carry obligations as regulated entities, not merely as buyers imposing requirements on others.
• Important entities in other sectors. Postal and courier services, waste management, manufacturing of certain products, and providers of digital services such as online marketplaces and search engines.

In the procurement context, this matters in two directions. A contracting authority may be a regulated entity in its own right, and the IT supplier it is contracting with may also be a regulated entity. Where both are in scope, the contract becomes a mechanism for cascading and coordinating obligations between two regulated parties. Where the supplier is not independently in scope but supplies services to a regulated buyer, the contract must still impose the security measures the buyer needs to discharge its own duties.

Thresholds and public-sector inclusion

Scope under NIS-2 generally turns on a combination of sector and entity size, with size thresholds typically distinguishing medium and large enterprises from smaller ones, subject to important exceptions where an entity is critical regardless of size. The authoritative determination of which Austrian organisations are captured, and which thresholds apply, is set out in the official Austrian NIS-2 transposing legislation published through the Rechtsinformationssystem des Bundes (RIS). Procurement teams should verify the precise sectoral and size thresholds against the current RIS text rather than relying on general descriptions, because the inclusion of public hospitals, municipalities and critical infrastructure operators will depend on the specific transposing provisions.

Where there is any doubt about whether a buyer or a bidder is in scope, a documented scoping assessment should be carried out and retained.

Key new obligations that affect public procurement and suppliers

The Austrian NIS-2 regime introduces a cluster of obligations that reshape both how authorities buy IT and how suppliers must present themselves. For the purposes of procurement and contract drafting, the most consequential obligations fall into five groups, each of which has a direct bearing on tender documents and contract terms.

• Minimum technical and organisational measures (TOMs). Regulated entities must implement appropriate and proportionate measures to manage the risks to their network and information systems. The NIS-2 Directive sets out a baseline that includes risk analysis and information system security policies, incident handling, business continuity, supply-chain security, security in acquisition and development, and the use of cryptography and access control. ENISA provides technical guidance on how these measures should be implemented in practice.
• Supply-chain security. Entities must address security risks arising from their suppliers and service providers, taking into account vulnerabilities specific to each supplier and the overall quality of the supplier’s products and cybersecurity practices. This obligation flows directly into procurement: buyers must assess supplier security, and suppliers must be able to demonstrate it.
• Vulnerability handling and disclosure. Entities are expected to maintain processes for handling and disclosing vulnerabilities, which contracts should reflect through cooperation and notification duties.
• Incident reporting. Significant incidents must be reported to the designated national authority within defined timelines, with escalating detail. This creates a contractual need for suppliers to notify buyers rapidly so that the buyer can meet its own reporting deadlines.
• Documentation and evidence. Entities must be able to demonstrate compliance, which requires documented policies, measures and records, the same documentation suppliers will need to evidence in tenders.

For contracting authorities, the key takeaway is that these obligations cannot be met by the authority alone where IT services are outsourced. Compliance depends on suppliers performing to a defined standard. For suppliers, the takeaway is that cybersecurity has become a qualification and award issue: the ability to demonstrate TOMs, supply-chain controls and incident-response capability will increasingly determine who can win and keep public contracts.

Updating procurement documents and tender requirements for NISG compliance Austria

Achieving NISG compliance Austria in procurement means rewriting tender documents so that cybersecurity requirements are embedded from the earliest stage rather than bolted on at contract signature. The following step-by-step approach aligns tender preparation with the obligations above.

Pre-tender risk assessment

Before issuing a tender, the contracting authority should carry out a documented risk assessment of the service being procured. This assessment should identify what data and systems the supplier will access, the criticality of the service to the authority’s operations, the potential impact of a security incident, and whether the authority’s own NIS-2 obligations are engaged by the procurement. The output of this assessment drives the proportionality of the security requirements that follow: a low-risk commodity purchase should not attract the same controls as the outsourcing of a critical clinical IT system. Retaining this assessment also provides an audit trail demonstrating that requirements were set on a reasoned basis.

Technical specifications and mandatory TOMs in specifications

The technical specifications should translate the risk assessment into concrete, verifiable security requirements. Rather than requiring generic “good security practice,” specifications should list the minimum technical and organisational measures the supplier must implement. Drafting prompts for the specification include:

• Information security management system requirements, for example alignment with recognised standards such as ISO/IEC 27001, where proportionate.
• Access control, authentication and the use of encryption for data in transit and at rest.
• Vulnerability management, patching timelines and secure development practices for any bespoke software.
• Business continuity and backup arrangements with defined recovery objectives.
• Supply-chain security measures, including the supplier’s own controls over its subcontractors.
• Incident detection, response and notification capability.

Each requirement should be drafted so that compliance is capable of being evidenced and, where appropriate, verified through certification, attestation or audit.

Award criteria and proof requirements

Security requirements should be reflected in the evaluation methodology. Authorities can treat baseline security measures as mandatory minimum (pass/fail) requirements and reserve scored award criteria for security capabilities that exceed the baseline. Where security is scored, the award criteria must be transparent, linked to the subject matter of the contract and applied consistently, in line with the principles of the Austrian Bundesvergabegesetz (Federal Public Procurement Act). Proof requirements should be specified alongside the criteria so bidders know exactly what evidence to submit, for example current certifications, a TOMs matrix, or a description of the incident-response process, rather than unsupported assertions of compliance.

Contractual pass/fail requirements

Certain requirements are appropriate to treat as absolute conditions of participation or performance. These may include holding a specified certification at contract commencement, maintaining it throughout the term, and committing to the incident-notification timelines the authority needs to meet its own obligations. Pass/fail requirements must be proportionate and non-discriminatory, but they allow an authority to exclude bidders who cannot demonstrate the security baseline required for NIS-2 compliance. The procurement documents should make clear that these requirements carry through into the contract itself, linking to the model clauses described below.

Model contract clauses and allocation of responsibilities

The contract is where procurement intent becomes enforceable obligation. The following clause headings form a practical clause library for NISG compliance Austria in public IT contracts. The sample language is offered as a drafting example for guidance only and must be reviewed by local counsel and adapted to the specific procurement and the applicable Austrian NIS-2 provisions.

Security obligations

The security clause should require the supplier to implement and maintain, throughout the term, technical and organisational measures appropriate to the risks identified, consistent with the requirements set out in the specification. A drafting example: “The Supplier shall implement and maintain technical and organisational measures appropriate to the risks presented by the Services, including those set out in Schedule [X] (Security Requirements), and shall keep such measures under review and update them to address evolving threats and vulnerabilities.” The clause should cross-refer to a security schedule containing the detailed TOMs, so that the schedule can be updated by agreed change control without reopening the whole contract.

Audit and inspection rights

The buyer should reserve the right to verify the supplier’s compliance. A balanced audit clause permits the authority (or an independent auditor acting on its behalf) to inspect the supplier’s relevant records, systems and premises on reasonable notice, and to require the supplier to provide evidence such as certification reports and the results of security testing. A drafting example: “The Supplier shall, on [X] days’ notice, provide the Contracting Authority or its appointed auditor with such access and information as is reasonably required to verify compliance with the Security Requirements, including certification evidence and redacted results of penetration testing.” The clause should address confidentiality, frequency, and cost allocation, and allow for shorter-notice audits following a security incident.

Subcontractors and supply-chain cascade

Because NIS-2 requires entities to manage supply-chain risk, the contract must ensure that security obligations flow down to subcontractors. The clause should require the supplier to vet subcontractors, to impose equivalent security obligations on them, and to remain fully liable to the buyer for subcontractor performance. A drafting example: “The Supplier shall not engage any subcontractor in connection with the Services without first assessing that subcontractor’s cybersecurity practices, and shall procure that each subcontractor is bound by security obligations no less onerous than those in this Agreement. The Supplier remains liable for all acts and omissions of its subcontractors.” The buyer may also reserve a right to object to specific subcontractors on security grounds.

Liability, caps and indemnities

Allocation of liability for cybersecurity failures is one of the most negotiated areas. The contract should address the supplier’s liability for breaches of its security obligations and for incidents attributable to its failures, including any resulting regulatory penalties or remediation costs. Public contracts frequently treat certain categories of loss as uncapped or subject to a higher cap. A drafting example: “The Supplier shall indemnify the Contracting Authority against losses arising from the Supplier’s breach of the Security Requirements, including costs of incident response, notification and remediation.

” Suppliers will seek to cap exposure; the realistic negotiating space for public contracts, and any public-interest constraints on limiting liability, should be assessed against applicable Austrian procurement and contract law (including the general principles of the Allgemeines bürgerliches Gesetzbuch, ABGB).

Data breach cooperation and evidence

Where the buyer has incident-reporting obligations, it needs the supplier to notify it rapidly and to cooperate in investigation and reporting. The clause should set a short internal notification deadline running from the supplier’s awareness of an incident, require the supplier to preserve evidence, and oblige it to assist the buyer in preparing regulatory notifications. A drafting example: “The Supplier shall notify the Contracting Authority without undue delay and in any event within [X] hours of becoming aware of any security incident affecting the Services, shall preserve all relevant evidence, and shall provide all reasonable assistance to enable the Contracting Authority to meet its reporting obligations.”

Several of these clauses should be treated as red lines for public contracts, non-negotiable in substance even if the drafting is adjusted. These typically include the minimum security measures, the supplier’s duty to notify incidents in time for the buyer to meet its own deadlines, flow-down to subcontractors, and audit access. The following table maps obligations across the two parties and references the clause headings above.

Who does what: sample allocation of NIS-2 obligations in a public IT contract

Incident reporting obligations and operational workflow in Austria

Incident reporting is one of the most time-sensitive elements of NISG compliance Austria, because the reporting clock runs in hours, not days. The contract and the internal procedures must be designed so that an incident at a supplier reaches the responsible people, and then the national authority, within the statutory window.

What to report

Under the NIS-2 framework, entities must report significant incidents, broadly, incidents that cause or are capable of causing serious operational disruption or financial loss, or that affect other persons through considerable material or non-material damage. The precise definition of a significant incident and the thresholds that trigger reporting are set out in the Austrian transposing legislation and should be verified against the current RIS text. Internally, organisations should have a triage process that assesses whether an incident meets the reporting threshold as early as possible, because the reporting deadline begins to run once the entity becomes aware of a significant incident.

Notification timelines and content

The NIS-2 Directive establishes a staged reporting approach: an early warning submitted without undue delay and in any event within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report no later than one month after the incident notification. The exact deadlines and procedures applicable in Austria are fixed by the transposing legislation and the national authority’s operational guidance; organisations should confirm the current timelines directly against the RIS text and the designated authority’s published guidance rather than relying on summaries.

The content of a notification typically develops across the stages, from an initial indication of the nature and suspected cause, through an assessment of severity and impact, to a detailed account of the incident, the measures taken and lessons learned.

Where to report in Austria

Operational incident handling and reporting in Austria involves CERT.at, the national Computer Emergency Response Team, which publishes contact points and guidance on what to report and how. Competent authority and CSIRT functions under the NIS-2 regime are coordinated with the Federal Ministry of the Interior and GovCERT Austria. Organisations should identify in advance the correct reporting channel for their sector and entity type, confirm the contact details against the current official guidance, and record these in their incident-response plan so that the information is available under pressure during a live incident.

Example notification checklist and post-notification duties

A practical notification checklist should capture, at minimum: the time of detection and awareness; a description of the incident and affected systems; an initial severity and impact assessment; whether cross-border effects are suspected; the containment and remediation steps taken; and the contact point for follow-up. After notification, cooperative duties continue: the entity should support the authority’s investigation, provide updates as the picture develops, and submit the final report. Where a supplier is involved, the contract must oblige it to provide the information the buyer needs for each stage. Mapping this workflow, internal detection, triage, supplier notification, authority notification, and follow-up reporting, into a single documented flow ensures that no deadline is missed because responsibility was unclear.

Supplier readiness checklist, evidence and documentation to prepare

Suppliers that want to compete successfully for Austrian public contracts under the new regime should assemble an evidence pack in advance rather than scrambling at tender time. A ready pack signals maturity and shortens the response cycle. Key documents to prepare include:

• Certifications. Current ISO/IEC 27001 certification where applicable, SOC 2 reports for relevant services, and any sector-specific attestations, with validity dates clearly shown.
• TOMs matrix. A structured mapping of the technical and organisational measures in place against the categories required by the specification, enabling quick verification.
• Supply-chain risk assessments. Documentation of how the supplier assesses and manages the security of its own subcontractors and vendors.
• Incident-response plan. A documented plan showing detection, escalation, notification timelines and roles, demonstrating the capability to meet contractual and statutory reporting obligations.
• Penetration test and security testing summaries. Recent, suitably redacted summaries evidencing independent testing and remediation of findings.
• Subcontractor declarations. Confirmations that subcontractors are bound by equivalent security obligations.

These documents should be maintained in current versions, stored so they can be retrieved and submitted quickly, and retained for the periods required to demonstrate ongoing compliance throughout a contract’s life.

Sector special note, healthcare and medical device software (SaMD)

Healthcare procurement deserves particular attention because the consequences of a security incident can affect patient safety and clinical availability, not merely data. Hospitals and other healthcare providers frequently fall within the sectors covered by NIS-2, and their IT suppliers must meet correspondingly rigorous requirements. Where the procurement involves software that qualifies as a medical device (SaMD), the cybersecurity obligations of the NIS-2 regime sit alongside a separate regulatory layer governing medical devices under the EU Medical Devices Regulation (Regulation (EU) 2017/745), and the two frameworks must be reconciled in the specification and contract.

Data-protection interfaces require careful handling given the sensitivity of health data under the GDPR and the Austrian Datenschutzgesetz, and clinical availability requirements, ensuring systems supporting patient care remain operational, should be reflected in business-continuity and incident-response obligations with demanding recovery objectives. Healthcare buyers should treat security as a patient-safety issue and draft accordingly.

Practical next steps for contracting authorities and suppliers

• Confirm scope: carry out and document a scoping assessment to determine whether the buyer and each prospective supplier fall within the Austrian NIS-2 regime.
• Update tender templates: embed a pre-tender risk assessment step and standard security specification into procurement documents.
• Build a security schedule: create a reusable TOMs schedule that can be attached to contracts and updated under change control.
• Adopt the clause library: integrate security, audit, subcontractor, liability and breach-cooperation clauses, treating the red-line items as non-negotiable.
• Define evaluation criteria: decide which security requirements are pass/fail and which are scored, and specify the proof required for each.
• Map incident reporting: produce an incident-reporting workflow aligned to the current statutory timelines and CERT.at channels, with roles assigned.
• Brief suppliers early: communicate the new requirements and evidence expectations to incumbents and the market ahead of tendering.
• Schedule review: verify all timelines, thresholds and provisions against the current RIS text before each procurement, and arrange legal review of clauses.

Conclusion and further resources

NISG compliance Austria is a present concern that shapes how public IT is bought and supplied. Contracting authorities must update tender documents, embed mandatory security measures, and build incident-reporting workflows mapped to Austrian channels; suppliers must assemble the evidence and contractual commitments that public buyers now require. The clause library, comparison table and checklists above provide a practical starting point, but every timeline, threshold and provision, as well as the exact title and status of the governing statute, should be verified against the current Austrian NIS-2 transposing text on RIS and the national authority’s guidance before use, and model clauses should be reviewed by local counsel. Acting now, rather than at the next tender deadline, is the surest route to robust NIS-2 compliance in Austria and to protecting both public services and commercial relationships from avoidable cybersecurity risk.

Sources

1. EUR-Lex, NIS2 Directive (Directive (EU) 2022/2555)
2. Rechtsinformationssystem des Bundes (RIS)
3. ENISA, European Union Agency for Cybersecurity
4. CERT.at, Computer Emergency Response Team Austria
5. European Commission, NIS2 Directive policy page
6. Bundesministerium für Inneres (Federal Ministry of the Interior)