NIS2 Germany 2026: BSIG Compliance Guide for SaaS Developers

Post #1 in the sota.io EU NIS2 Country-by-Country Compliance Series

Germany transposed the EU NIS2 Directive into the IT-Sicherheitsgesetz 3.0 (BSIG-neu), which entered into force in December 2025. If your SaaS operates in Germany — even if headquartered elsewhere in the EU — you may be subject to BSI registration requirements, mandatory incident reporting within 24 hours, and €10 million fines for non-compliance.

This guide covers everything SaaS developers and engineering teams need to know: who is in scope, how to register with the BSI, what §30 security requirements mean in practice, and how to build a compliant incident response pipeline.

1. BSIG 3.0 Overview — Germany's NIS2 Transposition

Germany was one of the first major EU member states to transpose NIS2, beating the October 2024 deadline and publishing the final BSIG on 18 December 2025 (BGBl. I Nr. 417). The law applies from the publication date, making Germany's implementation one of the strictest and most comprehensive in Europe.

Key regulatory authorities:

• BSI (Bundesamt für Sicherheit in der Informationstechnik) — primary NIS2 supervisory body for most sectors
• BNetzA (Bundesnetzagentur) — digital infrastructure and telecoms
• BaFin — financial sector (DORA cross-reference)
• BSI-KRITIS-Team — critical infrastructure (§29 BSIG)

The BSIG distinguishes between two entity types with different compliance burdens:

For SaaS companies, the relevant sectors are:

• Digital Infrastructure (DNS, cloud, data centres, CDNs, TLD operators) → typically Essential
• Digital Providers (managed services, online marketplaces, search engines) → typically Important
• ICT Service Management (B2B managed IT services) → Essential if >€50M

2. Are You In Scope? BSIG Applicability Test for SaaS

NIS2 applies based on a combination of sector classification and size threshold. The common misconception is that the company's headquarters location determines scope — it does not. Germany's BSIG applies if you provide services to essential or important sectors in Germany, regardless of where you are incorporated.

Step 1: Sector Check

Your SaaS is likely in scope if you provide:

Digital Providers (Anhang II, BSIG):
├── Cloud computing services (IaaS, PaaS, SaaS)
├── Online marketplaces
├── Online search engines
└── Social networking platforms (>1M EU users)

Managed Services (Anhang I, BSIG):
├── Managed IT/ICT services to businesses
├── Managed security services (MSS/MSSP)
└── IT system integration with security relevance

Digital Infrastructure (Anhang I, BSIG):
├── DNS resolution services
├── TLD registry/registrar
├── CDN providers
├── Data centre operators
└── Trust service providers (qualified)

Step 2: Size Threshold

Apply the EU standard SME thresholds:

Essential Entity threshold:
  employees ≥ 250 AND (turnover > €50M OR balance sheet > €43M)
  OR specifically designated by BSI regardless of size

Important Entity threshold:
  employees ≥ 50 AND (turnover > €10M OR balance sheet > €10M)
  OR exceeds Essential threshold

Step 3: The "Germany Test"

You are subject to BSIG if you:

1. Are registered in Germany, OR
2. Have a designated representative in Germany (required for non-EU entities), OR
3. Provide services to German entities in covered sectors

For SaaS companies: if your customers in Germany include banks, hospitals, utilities, government, or other NIS2-covered entities, your supply chain relationship triggers obligations under §24 BSIG (supply chain security).

3. BSI Registration — What You Need to Do

Germany introduced mandatory registration for all entities meeting the thresholds. This is not optional — failure to register is itself an infringement even before any incident occurs.

Registration Portal

The BSI registration system (MELDEPLATTFORM NIS-2) is at:

https://meldeplattform.bsi.de/

Registration requires:

• Organisation name and legal form
• NIS2 sector classification (choose from Anhang I or Anhang II)
• Entity size (Essential or Important)
• Primary contact and security officer (CSO/CISO)
• 24/7 incident reporting contact (email + phone)
• List of IP address ranges, AS numbers, domain names
• For non-EU companies: designation of German representative

Registration Deadline

BSIG §33 requires registration within 3 months of becoming subject to the regulation. Since BSIG entered force December 2025, most affected entities had a registration deadline of March 2026.

If you have not yet registered and meet the thresholds, you are already non-compliant. The BSI has indicated it will begin active compliance checks in Q3 2026, so the window to self-register before enforcement is narrowing.

What Happens After Registration

1. BSI assigns your entity an NIS2 registration number
2. You receive access to BSI's CERT-Bund information sharing platform
3. Quarterly sector-specific threat intelligence reports (read-only initially)
4. Your entity appears in the BSI NIS2 entity register (not public)

4. §30 BSIG — Security Requirements in Practice

§30 BSIG implements Article 21 NIS2, requiring a risk-based approach to cybersecurity. The BSIG goes further than the directive by providing specific technical requirements via BSI-Technische Richtlinien (TR).

The 10 mandatory security domains under §30 BSIG:

1. Risk Analysis and Information Security Policies

Required: Documented information security policy approved by management, annual risk assessment, risk register with mitigations.

For SaaS teams: This means a written ISMS policy (ISO 27001, SOC 2, or BSI IT-Grundschutz), annual risk review, and board-level sign-off. The BSI recommends IT-Grundschutz as the reference framework, though ISO 27001 is accepted.

2. Incident Handling (Störfallmanagement)

Required: Incident response plan, defined roles (IR team, comms, executive), regular drills.

Critical for SaaS: Your IR plan must explicitly address reporting to BSI within 24 hours — this cannot be a post-incident decision. Many SaaS teams fail here because the IR plan says "assess, then decide" when German law says "report first, assess second."

3. Business Continuity Management

Required: BCM policy, RTO/RPO definitions per service tier, annual BCP test, disaster recovery runbooks.

For SaaS: Define which customer segments require which SLAs, document failover procedures, test at least annually (tabletop or live failover). Essential entities must test more frequently.

4. Supply Chain Security

Required: Security requirements for ICT suppliers, due diligence process for new vendors, regular supplier audits.

This is where NIS2 Germany becomes costly for SaaS: you must assess not just your direct cloud provider but also sub-processors. If you use AWS in Frankfurt, you need a risk assessment of Amazon's NIS2 compliance posture as your ICT supplier.

Supplier security assessment minimum requirements:
- GDPR data processing agreement ✓
- NIS2 compliance statement or ISO 27001 cert ✓
- Incident notification SLA (typically 24h to notify you) ✓
- Right-to-audit clause ✓
- Geographic data storage confirmation ✓

5. Security in Network and Information Systems Acquisition

Required: Security requirements integrated into procurement, dev, and build processes (Secure SDLC).

For SaaS development teams: This means SAST/DAST in CI/CD pipeline, dependency vulnerability scanning (SBOM), security code review gates, and documented threat model for each product release.

6. Effectiveness Assessment of Cybersecurity Measures

Required: Internal audit or external penetration test at least annually for Essential entities (biannual for Important).

BSI guidance: Full-scope penetration test covering external attack surface, API security, and authentication systems. Results must be documented and remediation tracked.

7. Cybersecurity Hygiene and Training

Required: All staff basic security training annually, developers security-specific training, privileged users advanced training.

For SaaS: Phishing simulations count. Security awareness LMS platforms (KnowBe4, SoSafe, Hoxhunt) satisfy this requirement if completion rates are tracked and documented.

8. Cryptography and Encryption Policy

Required: Documented cryptography policy, approved algorithm list, key management procedures.

For SaaS APIs and databases: Document which cipher suites are permitted (TLS 1.3 mandatory, TLS 1.2 with approved ciphers), key rotation schedule, secrets management approach (HashiCorp Vault, AWS KMS, or equivalent).

BSI-approved cryptography (TR-02102):
- TLS: TLS 1.3 preferred, TLS 1.2 acceptable
- AES-256-GCM for data at rest
- RSA 3072+ or ECDSA P-384+ for signing
- Argon2id for password hashing
- Do NOT use: MD5, SHA-1, RC4, DES, 3DES

9. Human Resources Security and Access Controls

Required: Vetting for privileged roles, separation of duties, MFA for admin access, access reviews quarterly.

For SaaS engineering: This means privileged access management (PAM) for production systems, Just-In-Time access for databases, mandatory MFA on all cloud console accounts, and documented access review process.

10. Multi-Factor Authentication and Secure Communications

Required: MFA for all remote access, encrypted communications for sensitive data, secure voice/messaging policy.

BSI TR-03166 specifies MFA requirements: at least two factors from different categories (knowledge, possession, inherence). SMS OTP is explicitly listed as lower assurance — BSI recommends TOTP (RFC 6238) or hardware token for admin accounts.

5. §31 BSIG — Incident Reporting: The 24-Hour Clock

This is where German NIS2 differs most from previous German cybersecurity law. The BSIG now requires a three-stage reporting regime for "erhebliche Sicherheitsvorfälle" (significant incidents):

What Qualifies as a Significant Incident?

An incident is reportable under §31 BSIG if it:

• Caused or is likely to cause significant disruption to your service, OR
• Caused or is likely to cause significant financial damage to other entities, OR
• Affected or is likely to affect other entities (spillover), OR
• Caused or is likely to cause significant data breach (combined with GDPR Art.33)

For SaaS, practical thresholds (BSI guidance):

• Service unavailability affecting >5% of German customers for >30 minutes
• Data breach affecting personal data of >500 German users
• Security incident affecting critical infrastructure customer
• Ransomware attack (always reportable, regardless of impact)
• Supply chain compromise affecting downstream customers

The Three Stages

Stage 1 — Frühwarnung (Early Warning): Within 24 hours

Report via BSI Meldeplattform or telephone hotline (+49 228 99 9582-4444):

Required information:
- Date/time of incident discovery
- Initial classification (attack type if known)
- Affected systems/services (high level)
- Estimated impact (scope, customers affected)
- Status (ongoing/contained)
- Contact person details

This report does NOT need to be complete. The BSI explicitly says: report what you know. An incomplete 24-hour report is always better than a complete 72-hour report.

Stage 2 — Erstbericht (Initial Report): Within 72 hours

More detailed report covering:

- Technical details of the incident
- Preliminary root cause assessment
- Actual impact (confirmed customer count, data affected)
- Containment measures taken
- Remediation timeline
- Any cross-border impact (other EU member states)

Stage 3 — Abschlussbericht (Final Report): Within 1 month

Complete post-incident analysis:

- Full root cause analysis
- Complete timeline of events
- All affected systems and data
- Remediation measures implemented
- Lessons learned
- Measures to prevent recurrence
- If applicable: GDPR Art.33/34 notification cross-reference

Building a 24-Hour Reporting Pipeline

Most SaaS teams are not ready to file a structured BSI report within 24 hours of an incident. Building this capability requires:

Incident Detection → Triage (30 min) → Decision (significant/non-significant)
                                                    ↓
                                          Reportable → Assign reporter
                                                    ↓
                                       Draft Stage 1 (2 hours max)
                                                    ↓
                                          Legal/CSO sign-off (30 min)
                                                    ↓
                                       Submit via Meldeplattform

Key requirement: the 24-hour clock starts at the moment of discovery, not at the moment of confirmation. Train your on-call engineers to escalate immediately.

6. Supply Chain Obligations — Your Downstream Customers

If your SaaS serves NIS2-covered entities in Germany (banks, hospitals, utilities, defence), you have specific obligations under §24 BSIG:

1. Security requirements in contracts: Include cybersecurity clauses in customer contracts
2. Incident notification: Notify customers within 24 hours if your incident may affect them
3. Audit rights: Provide customers with right-to-audit or equivalent certifications
4. Vulnerability disclosure: Responsible disclosure process for product vulnerabilities

For SaaS B2B: This means your enterprise contract template needs NIS2 addenda. Standard GDPR DPAs are insufficient.

7. Fines and BSI Enforcement

BSI can impose administrative fines for:

Personal liability: §38 BSIG allows BSI to hold individual members of management personally liable for wilful or grossly negligent non-compliance — up to €500,000 personally for Essential entities. This is a significant departure from previous BSIG versions and aligns with DORA.

BSI enforcement escalation:

1. BSI Verfügung (order to remedy within set deadline)
2. Zwangsgeld (coercive fine until compliance)
3. Administrative fine under §40 BSIG
4. For repeated/serious violations: provisional market exclusion

8. NIS2 Germany vs. NIS1 — What Changed for SaaS

If your SaaS was previously compliant with BSI-KRITIS (old §8a BSIG), here is what changed:

9. 40-Point BSIG Compliance Checklist for SaaS Teams

Use this checklist to assess your current compliance gap:

Registration (§33 BSIG)

• Completed NIS2 applicability self-assessment
• Determined Essential vs. Important entity classification
• Registered on BSI Meldeplattform
• Designated 24/7 incident reporting contact
• Assigned management-level NIS2 responsible person

Security Policy (§30 Nr.1)

• Written information security policy approved by board/management
• Annual risk assessment process documented
• ISMS framework selected (ISO 27001 / IT-Grundschutz / SOC 2)
• Risk register maintained with ownership

Incident Handling (§30 Nr.2)

• Incident response plan covers BSI §31 reporting timeline
• 24-hour reporting workflow documented and tested
• IR team roster with 24/7 escalation contacts
• Annual IR drill or tabletop exercise

BCM (§30 Nr.3)

• RTO/RPO defined per service tier
• DR runbooks for primary failure scenarios
• Annual BCM test (tabletop minimum, live failover preferred)
• Business continuity plan documented

Supply Chain (§30 Nr.4)

• NIS2-relevant suppliers/sub-processors identified
• Security requirements in supplier contracts
• Supplier incident notification SLAs agreed
• Annual supplier security review process

Secure Development (§30 Nr.5)

• SAST/DAST integrated in CI/CD pipeline
• SBOM generation for all releases
• Security code review gates
• Dependency vulnerability scanning automated

Security Assessment (§30 Nr.6)

• Annual penetration test by qualified provider
• Penetration test scope covers external attack surface + APIs
• Remediation tracking for pentest findings
• Vulnerability disclosure (responsible disclosure policy)

Training (§30 Nr.7)

• Annual security awareness training for all staff
• Security-specific training for developers
• Privileged user advanced security training
• Training completion rates tracked and documented

Cryptography (§30 Nr.8)

• Documented cryptography policy
• BSI TR-02102 compliance verified
• TLS 1.3 enforced on all endpoints
• Key rotation schedule implemented

Access Control + MFA (§30 Nr.9+10)

• MFA on all admin/production access
• Privileged access management (PAM) deployed
• Access reviews quarterly
• Separation of duties documented

10. EU Hosting and BSIG Compliance

One practical consideration for German NIS2 compliance that many SaaS teams overlook: cloud provider selection affects your §30 Nr.4 supply chain obligations.

When your cloud provider is a non-EU entity (US-headquartered hyperscaler), your supplier risk assessment must account for:

• CLOUD Act 2018 exposure (US government data access orders)
• Sub-processor chains spanning multiple jurisdictions
• Data residency vs. data processing location distinction

German NIS2-covered entities increasingly require their SaaS suppliers to demonstrate data residency in German/EU data centres with EU-based operational control as a contractual condition. This is not yet a legal requirement under BSIG (unlike some French sectoral rules), but it is an emerging procurement requirement from Essential entities.

EU-sovereign infrastructure options for BSIG-compliant deployment:

• Hetzner (Nuremberg/Falkenstein/Helsinki) — German-headquartered, no CLOUD Act exposure
• IONOS (Kaiserslautern) — Deutsche Telekom subsidiary, EU data residency
• OVHcloud (Roubaix) — French entity, EU-certified, CISPE member
• Scaleway (Paris) — Iliad subsidiary, NIS2 compliant, GDPR-native

Using an EU sovereign cloud provider can reduce your §30 Nr.4 supplier due diligence burden, since EU-based providers are themselves subject to NIS2 obligations.

Series Roadmap: EU NIS2 Country-by-Country Compliance 2026

This is post 1 of 5 in our NIS2 country compliance series. Upcoming posts:

• Post 2: NIS2 Austria (NISG 2024) — DACH Region SaaS Compliance Comparison: Germany vs. Austria
• Post 3: NIS2 France (ANSSI) vs. Netherlands (NCSC-NL) — Western Europe SaaS Requirements
• Post 4: NIS2 Southern Europe — Spain (INCIBE), Italy (ACN), Portugal, Greece Compliance Requirements
• Post 5: NIS2 21-Country Compliance Stack — Complete SaaS Decision Framework for Multi-Country EU Operations

Resources

• BSI NIS2 information page: bsi.de/NIS2
• BSI Meldeplattform (registration): meldeplattform.bsi.de
• BSIG full text: Bundesgesetzblatt 2025 (BGBl. I Nr. 417)
• BSI IT-Grundschutz framework: bsi.de/grundschutz
• BSI TR-02102 (cryptography guidelines): bsi.de/tr02102
• NIS2 Directive (EU) 2022/2555: EUR-Lex

sota.io is an EU-native developer platform built for NIS2-compliant SaaS operations. Our infrastructure runs exclusively in European data centres with no US-parent company exposure — making your §30 Nr.4 supplier risk assessment straightforward.