Sicherheit wird gern verschoben, bis sie durch einen Vorfall erzwungen wird — der teuerste mögliche Zeitpunkt. Es gibt eine Baseline, unter die kein produktives SaaS gehen sollte: gehärtete Authentifizierung mit MFA, Verschlüsselung in Ruhe und Transport, Secrets ausserhalb des Codes, aktuelle Dependencies und getestete Backups. Keiner dieser Punkte ist exotisch, und ihr Fehlen ist die Ursache der meisten Vorfälle bei kleinen Anbietern.
Dieser Leitfaden ordnet die Sicherheits-Baseline für SaaS in sieben Abschnitten ein: Kontext, Rahmen, die konkreten Anforderungen, die Umsetzung, typische Fehler, der DACH-Kontext und die nächsten Schritte.
Wir schreiben aus der Praxis: Innopulse Consulting berät DACH-Unternehmen und betreibt ein eigenes SaaS-Portfolio unter denselben Bedingungen, die wir empfehlen.
Worum es geht
Sicherheit wird gern verschoben, bis sie durch einen Vorfall erzwungen wird — der teuerste mögliche Zeitpunkt. Es gibt eine Baseline, unter die kein produktives SaaS gehen sollte: gehärtete Authentifizierung mit MFA, Verschlüsselung in Ruhe und Transport, Secrets ausserhalb des Codes, aktuelle Dependencies und getestete Backups. Keiner dieser Punkte ist exotisch, und ihr Fehlen ist die Ursache der meisten Vorfälle bei kleinen Anbietern. Die praktische Frage lautet: Was bedeutet das konkret für ein Team oder Produkt im DACH-Raum?
- MFA als Default, nicht als Option für Vorsichtige
- Verschlüsselung at-rest und in-transit überall
- Secrets in einem Manager, niemals im Code oder Repo
- Dependencies aktuell halten — die meisten Lücken sind bekannt
Technische Grundlagen und Referenz-Architektur
Für SaaS hat sich im Jahr 2026 ein Stack als Default etabliert: Next.js 15, PostgreSQL mit Row-Level-Security, Stripe, EU-Hosting. Diese Basis deckt einen Grossteil der Anforderungen DSGVO-freundlich ab. Für spezialisierte Domänen kommen Disziplinen dazu, die man nicht improvisieren kann. Wir betreiben mehrere Produkte auf dieser Architektur und die Entscheidungen tragen unsere eigene kommerzielle Realität.
Die konkreten Anforderungen
Im Zentrum von die Sicherheits-Baseline für SaaS stehen die folgenden Punkte:
- MFA als Default, nicht als Option für Vorsichtige
- Verschlüsselung at-rest und in-transit überall
- Secrets in einem Manager, niemals im Code oder Repo
- Dependencies aktuell halten — die meisten Lücken sind bekannt
- Backups testen, nicht nur erstellen
- Principle of Least Privilege für jeden Zugriff
Umsetzung in der Praxis
Für die Sicherheits-Baseline für SaaS bewährt sich ein Vorgehen in drei Phasen:
- Bestandsaufnahme (1-2 Wochen): Ist-Zustand erfassen, Beteiligte identifizieren, Lücken benennen.
- Konzeption (2-4 Wochen): Zielbild definieren, Verantwortlichkeiten zuweisen, Massnahmen festlegen.
- Umsetzung und Betrieb (laufend): Implementieren, messen, nachsteuern. Die meisten Initiativen scheitern an der fehlenden Phase drei.
Typische Fehler
Aus der Praxis wiederholen sich dieselben Fehler:
- die Sicherheits-Baseline für SaaS als einmaliges Projekt behandeln statt als Disziplin
- Werkzeuge wählen, bevor der Prozess verstanden ist
- Den DACH-Kontext ignorieren und US-Vorlagen übernehmen
- Dokumentation aufschieben bis sie unter Druck entsteht
- Erfolg an Aktivität messen statt an Wirkung
DACH-Kontext
Schweiz, Deutschland und Österreich unterscheiden sich in Recht und Marktrealität. Die Schweiz steht oft ausserhalb der EU-Regime, ist aber über Marktzugang faktisch eingebunden; Deutschland setzt am strengsten um; Österreich folgt eng den EU-Standards. Wer in allen drei Märkten arbeitet, baut nach dem strengsten gemeinsamen Nenner.
Nächste Schritte
Der pragmatische Einstieg in die Sicherheits-Baseline für SaaS ist eine ehrliche Standortbestimmung. Innopulse Consulting begleitet DACH-Unternehmen bei genau diesen Fragen — erreichbar unter info@innopulse.io. Die ersten 30 Minuten kosten nichts.