NIS2 Austria vs Germany 2026: DACH SaaS Compliance Comparison — NISG vs BSIG Side-by-Side

Post #2 in the sota.io EU NIS2 SaaS Compliance Series

If you operate a SaaS product in the DACH region, you face a compliance puzzle that no single NIS2 document fully solves: Austria and Germany each implemented NIS2 as national law with distinct registration portals, supervisory authorities, and procedural requirements. Pass German BSIG 3.0 compliance and you still have an Austrian NISG 2024 gap. This guide closes it.

The EU's NIS2 Directive (Directive 2022/2555/EU) mandated all 27 Member States to transpose national legislation by 17 October 2024. Germany met this deadline with BSIG 3.0 (in force October 2024). Austria met it with the Netz- und Informationssystemsicherheitsgesetz 2024 (NISG 2024), which entered into force on 18 October 2024. Both laws implement the same EU framework — but with meaningful procedural differences that every DACH-operating SaaS team must understand.

Part 1: Austria NISG 2024 — The Law Explained

1.1 Legislative Background

Austria's NIS2 transposition was enacted as BGBl. I Nr. 118/2024 — the Bundesgesetz über Maßnahmen zur Sicherheit von Netz- und Informationssystemen (NISG 2024). The law replaced the earlier NIS Act (BGBl. I Nr. 111/2018) from first-generation NIS1.

Key legislative milestones:

• Parliament approval: July 2024
• Official gazette publication: BGBl. I Nr. 118/2024
• In force: 18 October 2024
• First enforcement actions expected: Q3 2026 (supervisory authority ramp-up complete)

1.2 Competent Authorities in Austria

Unlike Germany's single BSI authority, Austria splits supervisory responsibility across multiple bodies:

For SaaS developers: The vast majority of software platforms in scope fall under RTR-GmbH as the primary competent authority. RTR is Austria's combined telecoms/media/digital services regulator — the equivalent of Germany's BSI for digital service providers.

1.3 Applicability Thresholds

NISG 2024 follows NIS2's size thresholds exactly:

Essential Entities (Wesentliche Einrichtungen — §3 Abs. 1 NISG):

• Active in Annex I sector AND
• ≥250 employees OR ≥€50M annual turnover AND ≥€43M balance sheet

Important Entities (Wichtige Einrichtungen — §3 Abs. 2 NISG):

• Active in Annex I or II sector AND
• ≥50 employees OR ≥€10M annual turnover (mid-market / "medium enterprise")

NISG-specific additions: Austria's NISG 2024 §3 Abs. 3 includes a "regardless of size" clause for entities whose disruption would have a significant cross-border impact — particularly critical national infrastructure operators. SaaS platforms for public authorities, utilities, or financial sector in Austria may trigger this clause even below the 50-employee threshold.

Annex II sectors most relevant to SaaS:

• Cloud computing service providers
• Online marketplaces, search engines, social networks
• Managed IT services (MSP/MSSP)
• Postal and courier services (digital)
• Waste management (digital control systems)
• Food production/distribution (ERP/supply chain SaaS)
• Chemical industry (process control SaaS)
• Research (university platforms, research data SaaS)

Part 2: Germany BSIG 3.0 vs Austria NISG 2024 — Side-by-Side Comparison

2.1 Registration

The most operationally significant difference between Germany and Austria is the registration system:

Practical difference: Austria's 6-month explicit deadline in NISG §16 gives SaaS companies a concrete window to complete registration after launching in Austria or crossing the size threshold. Germany's BSIG has no such defined window — the BSI has indicated "without undue delay" means within 3 months in practice, but this is guidance, not statute.

2.2 Incident Reporting Timelines

Both laws implement the three-phase NIS2 reporting cascade — but with different notification recipient details:

Austria-specific: Under NISG §34, the 24-hour early warning goes to CERT.at (Austria's national CSIRT), while the 72-hour formal notification goes to RTR-GmbH as the competent authority. This dual-track reporting is different from Germany where all reports go to BSI directly.

Cross-border incidents: If your SaaS incident affects users in both Germany and Austria simultaneously, NIS2 Article 23(8) requires notification to the competent authority in the Member State where you are "established" (your primary EU entity) — with that authority coordinating with others. For a German GmbH with Austrian customers, the primary report goes to BSI, which then coordinates with RTR.

2.3 Security Requirements

Both laws require a risk-appropriate security baseline, referencing the same NIS2 Article 21 measures. The technical implementation details differ:

Convergence note: The security measures are substantively identical because both laws implement NIS2 Article 21 verbatim. The practical difference is in implementation guidance: Germany's BSI publishes detailed technical baselines (BSI-Grundschutz, IT-Grundschutz-Kompendium, orientierungshilfen), while Austria relies primarily on RTR guidance and ENISA recommendations.

2.4 Management Accountability

Both laws include personal liability provisions for management:

AT-specific: NISG §30 explicitly references the "adequate information and knowledge" standard — Austrian courts may apply a stricter "should have known" test for management liability compared to Germany's implementation.

2.5 Penalties Framework

Key AT vs DE distinction: Austria's NISG calibrates fines at the lower end of the NIS2 permitted range for administrative violations (registration, cooperation) while matching Germany for substantive security and reporting failures. Austrian enforcement practice has historically favored compliance notices before fines for first-time offenders.

Part 3: Switzerland Context (DACH Non-EU Partner)

Switzerland is not an EU Member State and not bound by NIS2. However, for DACH-focused SaaS companies operating in Switzerland:

3.1 Relevant Swiss Legislation

Informationssicherheitsgesetz (ISG, SR 128.0): Switzerland's Information Security Act, in force since 1 January 2023. Applies to federal authorities and critical infrastructure operators serving the Swiss Confederation. Does not directly apply to private SaaS vendors — but your Swiss public-sector customers are bound by it.

Meldepflicht für Cyberangriffe (BPJPD 2025): Switzerland introduced mandatory cyber incident reporting for critical infrastructure operators effective 1 April 2025. Operators of critical infrastructure (including key SaaS platforms) must report significant cyber attacks to the Bundesamt für Cybersicherheit (BACS) within 24 hours.

3.2 Swiss vs EU NIS2 Comparison

DACH SaaS implication: Swiss compliance is typically simpler if you are not directly operating critical infrastructure. Focus your NIS2 compliance efforts on DE (BSI/BSIG) and AT (RTR-GmbH/NISG) — then layer Swiss requirements on top for any CH public-sector customer contracts.

Part 4: DACH Registration Workflow

4.1 Two Registrations, One Compliance Program

If your SaaS serves Essential or Important entities across Germany and Austria, you need two separate registrations:

Step 1 — German BSI Registration (meldeplattform.bsi.de)

1. Create account at meldeplattform.bsi.de
2. Complete Einrichtungsmeldung (entity registration)
3. Designate NIS Kontaktperson + Stellvertretung
4. Classify entity type (Essential/Important)
5. Submit — BSI acknowledges within 14 business days
6. Update registration within 3 months of any material change

Step 2 — Austrian RTR-GmbH Registration (nis.rtr.at)

1. Create account at nis.rtr.at (RTR NIS Portal)
2. Complete Registrierungsformular NISG §16
3. Designate Sicherheitsansprechpartner + Stellvertretung
4. Self-classify under NISG §3 (Wesentlich vs. Wichtig)
5. Submit — RTR acknowledges within 21 business days
6. Registration must be renewed/confirmed annually
7. Deadline: Within 6 months of becoming in-scope

4.2 Contact Points — Different Requirements

Both laws require a designated contact person who can be reached 24/7 for incident communications:

Practical advice: Designate the same person (or role) as NIS contact for both Germany and Austria — your CISO or Head of Security. Ensure they have 24/7 reachability documented in both registrations and that they know to notify CERT.at (24h early warning) before RTR-GmbH (72h notification) in Austria.

Part 5: DACH Security Implementation

5.1 Shared Technical Baseline

Because both BSIG §30 and NISG §27 implement the same NIS2 Article 21 measures, your security program can be unified across DACH. Build once, document twice (referencing both law sections).

Core technical controls required in both jurisdictions:

Access Control & Identity

• Multi-factor authentication on all administrative interfaces (§30 Nr. 10 BSIG / §27 Z 10 NISG)
• Privileged access management with session logging
• Just-in-time access for production systems
• Identity lifecycle management with automated de-provisioning

Network Security

• Network segmentation — production / staging / corporate networks isolated
• Encrypted communications (TLS 1.2+ enforced, TLS 1.3 preferred)
• Firewall rules reviewed quarterly
• VPN or zero-trust for remote administrative access

Asset and Vulnerability Management

• Asset inventory covering all systems processing in-scope data
• Vulnerability scanning ≥monthly; critical CVEs patched within 72 hours
• Software composition analysis (SCA) for open-source dependencies
• SBOM (Software Bill of Materials) for supply chain visibility

Incident Detection and Response

• SIEM or log aggregation with 12-month retention minimum
• Defined runbooks for critical incident types
• Tested incident response plan (tabletop exercise ≥annually)
• Contact tree that routes to both BSI and RTR-GmbH contacts

Business Continuity

• RTO ≤4 hours, RPO ≤24 hours (typical for Important Entities)
• Annual DR test with documented results
• Backup integrity verification ≥quarterly

Supply Chain

• NIS2 security questionnaire for all critical third-party vendors
• Contractual security clauses in SaaS procurement agreements
• Annual vendor risk review

5.2 DACH-Specific Documentation Requirements

Both authorities require you to maintain and produce documentation on request:

German specifics: BSI may request IT-Grundschutz Selbstbewertung (self-assessment) documentation during audits. Maintaining IT-Grundschutz tool outputs or equivalent ISO 27001 gap assessments makes German audit preparation significantly faster.

Austrian specifics: RTR-GmbH tends to conduct initial audits via questionnaire (Fragebogen) rather than on-site inspection. Keeping a pre-populated answers document aligned to NISG §27 in German, ready to submit within 10 business days of a request, is practical risk reduction.

Part 6: Incident Response — DACH Dual-Track Procedure

When a significant incident occurs in your DACH-serving SaaS, the notification sequence becomes critical:

6.1 Is the Incident "Significant"?

Both laws define significant incidents identically (NIS2 Article 23 criteria):

• Causes or is likely to cause severe operational disruption OR financial losses to your entity
• Has or is likely to have a significant impact on other natural or legal persons (customers, users)

Practical threshold for SaaS: Anything affecting availability/integrity/confidentiality for >1% of your customer base, or any security breach with customer data exposure, should be treated as potentially significant from minute one.

6.2 DACH Notification Cascade

Hour 0 — Detection:

• Initiate internal incident response procedure
• Activate DACH contact persons (German NIS contact + Austrian Sicherheitsansprechpartner)
• Start incident log with timestamps

Hour 1-4 — Initial Assessment:

• Determine scope: Germany only / Austria only / both
• Check if incident is "significant" per Article 23 criteria
• If significant: notify BOTH German and Austrian contacts simultaneously

Hour 0-24 — Early Warning:

• Germany: Submit Frühwarnung to BSI via meldeplattform.bsi.de (basic info: time, type, estimated scale)
• Austria: Submit early warning to cert.at via their notification form or email (cert@cert.at)

Hour 24-72 — Incident Notification:

• Germany: Submit Meldung to BSI (updated assessment, affected systems, initial measures taken)
• Austria: Submit formal notification to RTR-GmbH via nis.rtr.at portal (AND updated notification to cert.at)

Day 30 — Final Report:

• Germany: Submit Abschlussbericht to BSI (root cause, measures taken, residual risk)
• Austria: Submit Abschlussbericht to RTR-GmbH

6.3 Cross-Border Incident Protocol

If the incident originates from your primary German entity but affects Austrian customers:

1. Primary reporting goes to BSI (Germany, your establishment authority)
2. BSI coordinates with RTR-GmbH under NIS2 Article 23(8) cross-border cooperation
3. You should still send a courtesy early warning to cert.at proactively (Austrian customers present)
4. Document bilateral coordination in your incident log

Part 7: DACH vs EU Hosting — Sovereign Cloud Angle

7.1 Infrastructure Location Matters for Both

Germany and Austria have strong national data protection traditions. While NIS2 does not mandate EU hosting, both BSI and RTR-GmbH will assess your security measures differently based on infrastructure location:

sota.io recommendation: For DACH-compliant SaaS, deploy your European infrastructure on Hetzner (Germany) or IONOS (Germany/Austria) as primary — this eliminates the CLOUD Act access risk that US hyperscalers cannot contractually exclude despite standard clauses.

7.2 Austrian-Specific: Exoscale

Exoscale (Zone: AT-VIE-1, Vienna, Austria) is a Swiss-managed European cloud IaaS provider with Austrian Points of Presence. For SaaS serving heavily Austrian public-sector customers, Exoscale's Austrian datacenter location + Swiss governance can be a meaningful differentiator when pitching NISG compliance.

Part 8: 35-Point DACH NIS2 Compliance Checklist

Registration & Governance (9 Points)

• 1. Self-assessed scope under §3 BSIG (DE) + §3 NISG (AT) — documented decision with rationale
• 2. German registration submitted to meldeplattform.bsi.de
• 3. Austrian registration submitted to nis.rtr.at (within 6 months of scope trigger)
• 4. German NIS contact person + deputy designated with 24/7 contact info
• 5. Austrian Sicherheitsansprechpartner + deputy designated with 24/7 contact info
• 6. Management board formally approved cybersecurity measures (board resolution or equivalent)
• 7. Management received cybersecurity training (documented, ≥annually)
• 8. DACH-specific contact tree for incident notification created and tested
• 9. Registration renewal process scheduled (AT: annual confirmation; DE: material changes within 3 months)

Security Program (10 Points)

• 10. Risk assessment documented and updated ≥annually
• 11. Security policy approved by board, published internally
• 12. Asset inventory covering all in-scope systems maintained
• 13. Vulnerability management program (scan cycle + SLA for critical patches)
• 14. MFA deployed on all administrative interfaces (§30 Nr. 10 BSIG / §27 Z 10 NISG)
• 15. Cryptography policy documented (TLS version requirements, cipher suites, key management)
• 16. Network segmentation architecture documented
• 17. Third-party (supply chain) security policy in place with vendor questionnaire
• 18. HR security procedures (background checks, offboarding, access revocation SLA)
• 19. Security training records maintained per employee, ≥annual frequency

Incident Response (8 Points)

• 20. Incident response plan (IRP) covers NIS2 Article 23 criteria for "significant" classification
• 21. Runbook includes DACH dual-track notification (BSI + CERT.at/RTR simultaneous)
• 22. BSI notification form pre-filled template available in IRP
• 23. CERT.at notification form/email template available in IRP
• 24. Incident log template with mandatory timestamp fields
• 25. Annual tabletop exercise with DACH scenario tested
• 26. SIEM or log aggregation with ≥12-month retention active
• 27. Post-incident 30-day final report process defined for both DE and AT

Business Continuity (4 Points)

• 28. BCP documented with defined RTO/RPO
• 29. Annual DR test executed and results documented
• 30. Backup integrity verification cycle active (≥quarterly)
• 31. Critical supplier BCP reviewed (at least Tier 1 cloud/hosting provider)

Documentation & Audit Readiness (4 Points)

• 32. NISG §27 compliance mapping document (answers pre-populated for RTR questionnaire)
• 33. BSI IT-Grundschutz self-assessment or ISO 27001 gap assessment available
• 34. Supplier security contracts include NIS2-compliant clauses
• 35. Evidence library (screenshots, configs, policies) accessible for on-demand authority requests

Part 9: Cross-Border Compliance — Practical Architecture

9.1 Unified DACH Security Program Structure

DACH NIS2 Compliance Program
│
├── Governance Layer (shared DE+AT)
│   ├── Security Policy (reference both BSIG §30 + NISG §27)
│   ├── Risk Assessment Framework (ENISA methodology)
│   └── Management Accountability (documented per §38 BSIG / §30 NISG)
│
├── Technical Controls Layer (shared implementation)
│   ├── Identity & Access Management
│   ├── Vulnerability Management
│   ├── SIEM / Log Management
│   └── Cryptography & Key Management
│
├── Incident Response Layer (DACH-specific routing)
│   ├── German track: BSI (meldeplattform.bsi.de)
│   └── Austrian track: CERT.at (24h) → RTR-GmbH (72h+)
│
├── Registration Layer (country-specific)
│   ├── Germany: meldeplattform.bsi.de
│   └── Austria: nis.rtr.at
│
└── Documentation Layer (country-specific evidence)
    ├── German: IT-Grundschutz alignment documentation
    └── Austrian: RTR questionnaire pre-fill document

9.2 When to Involve an Austrian Legal Counsel

For SaaS companies headquartered in Germany but serving Austrian enterprise customers, Austrian legal advice adds value in these specific scenarios:

• Jurisdictional classification: Is your Austrian entity a branch, subsidiary, or "presence" under NISG §2?
• Sector-specific authority: If you serve Austrian utilities or healthcare, E-Control or BMSGPK may be your competent authority rather than RTR-GmbH
• NISG §3 Abs. 3 "regardless of size" clause: If your platform is critical to Austrian national infrastructure functions
• Cross-border incident coordination: If an incident has bilateral BSI/RTR implications and you need counsel on disclosure sequencing

What's Next in the Series

This is Post #2 of 5 in the sota.io EU NIS2 SaaS Compliance Series:

1. ✅ NIS2 Germany BSIG 3.0: SaaS Developer Compliance Guide 2026
2. ✅ NIS2 Austria NISG 2024 vs Germany BSIG 3.0 — DACH Comparison (this post)
3. 🔜 NIS2 France ANSSI + Netherlands NCSC: Western Europe SaaS Compliance Guide 2026
4. 🔜 NIS2 Southern Europe: Spain INCIBE + Italy ACN Technical Requirements 2026
5. 🔜 NIS2 21-Country DACH→EU Compliance Stack: Complete SaaS Playbook 2026

DACH SaaS Compliance on EU-Native Infrastructure

Both BSI and RTR-GmbH assess your security posture as a whole — and infrastructure jurisdiction is part of that holistic picture. Moving from US hyperscalers to EU-native cloud removes the CLOUD Act ambiguity that neither German nor Austrian SaaS customers want to explain to their own compliance teams.

sota.io is built on EU-native infrastructure from day one. Deploy your SaaS workloads on Hetzner (Germany), Exoscale (Austria), IONOS, or Scaleway — all of which we support natively — and tick the NISG §27 Z 4 supply chain security box without the CLOUD Act footnote.

Ready to run DACH-compliant workloads on EU sovereign infrastructure? Explore sota.io →