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 statutory registration deadline of 6 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.

Update (July 2026): With only around 18,500 of an estimated 29,000–40,000 affected organisations registered by late May 2026, the BSI wrote to industry associations granting a soft extension until 31 July 2026. This is not a new statutory deadline — the legal cutoff remains 6 March 2026 — but a signal of leniency in enforcement. After 31 July 2026, the BSI has indicated companies that still have not registered should expect heightened regulatory attention. Late registration remains possible and advisable even after this date; it demonstrates a good-faith response and can mitigate (though not eliminate) the up to €500,000 fine exposure for the registration failure itself.

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.