Checkliste: Sicherheit vor dem SaaS-Go-live
Für: SaaS-Gründer und Entwicklungsteams
Aktualisiert: 2026-10
Vor dem Go-live eines SaaS-Produkts müssen acht Punkte stimmen: getestete Mandantentrennung auf Datenebene, sichere Authentifizierung mit Mehrfaktor, Geheimnisse ausserhalb des Codes, aktuelle Abhängigkeiten, Backups mit getesteter Wiederherstellung, Protokollierung sicherheitsrelevanter Ereignisse, Schutz vor Missbrauch und ein vorbereiteter Ablauf für Sicherheitsvorfälle.
Die meisten Sicherheitsprobleme junger SaaS-Produkte sind keine raffinierten Angriffe, sondern Lücken, die beim Bauen unter Zeitdruck entstehen: ein vergessener Berechtigungscheck, ein Schlüssel im Repository, ein Backup, das nie getestet wurde. Vor dem Go-live sind sie günstig zu beheben, danach teuer.
Diese Checkliste ist für Produkte auf einem modernen Stack geschrieben, etwa Next.js mit Postgres oder Supabase, und gilt sinngemäss für andere Architekturen.
Die Checkliste
- 01
Mandantentrennung auf Datenebene testen
Sicherstellen, dass die Trennung zwischen Kunden nicht nur in der Anwendungslogik, sondern auf Datenbankebene durchgesetzt wird, etwa mit Row Level Security. Automatisierte Tests versuchen, mit einem Konto auf Daten eines anderen Mandanten zuzugreifen.
Erledigt, wenn: Jede Tabelle mit Kundendaten hat eine aktive Trennungsregel, und ein automatisierter Test für Fremdzugriff läuft in der Pipeline und schlägt fehl, wenn die Regel fehlt.
- 02
Authentifizierung absichern
Mehrfaktor-Authentifizierung anbieten und für Administratoren erzwingen, sichere Passwort-Rücksetzung, Sitzungen mit Ablauf, Schutz gegen Brute Force. Für Unternehmenskunden SSO einplanen.
Erledigt, wenn: Administratorkonten können sich nur mit zweitem Faktor anmelden, und Passwort-Rücksetzung sowie Sitzungsablauf sind getestet.
- 03
Geheimnisse aus dem Code entfernen
API-Schlüssel, Datenbankzugänge und Signaturschlüssel ausschliesslich über die Umgebungskonfiguration bereitstellen, Schlüssel mit Service-Rechten nie im Frontend verwenden, das Repository auf versehentlich eingecheckte Geheimnisse prüfen.
Erledigt, wenn: Ein Scan des Repositorys inklusive Historie findet keine Geheimnisse, und Schlüssel mit erhöhten Rechten werden nur serverseitig verwendet.
- 04
Abhängigkeiten aktualisieren
Bekannte Schwachstellen in Bibliotheken und Frameworks prüfen und beheben, automatische Hinweise auf Updates aktivieren, Versionen festschreiben.
Erledigt, wenn: Der Schwachstellenbericht zeigt keine offenen kritischen oder hohen Befunde, und automatische Update-Hinweise sind aktiv.
- 05
Backups und Wiederherstellung testen
Ziele für Datenverlust und Wiederherstellungszeit festlegen, Point-in-Time-Recovery oder regelmässige Backups aktivieren und mindestens eine vollständige Wiederherstellung in eine separate Umgebung durchführen.
Erledigt, wenn: Eine Wiederherstellung ist durchgeführt und mit Dauer und Ergebnis protokolliert, und die Ziele sind dokumentiert.
- 06
Sicherheitsrelevante Ereignisse protokollieren
Anmeldungen, fehlgeschlagene Anmeldungen, Rechteänderungen, Exporte und administrative Aktionen mit Zeitpunkt und handelnder Person erfassen, Protokolle vor Veränderung schützen und Aufbewahrung festlegen.
Erledigt, wenn: Die genannten Ereignisse erscheinen im Protokoll, und es ist festgelegt, wer Auffälligkeiten prüft.
- 07
Missbrauch begrenzen
Rate Limits auf Anmeldung, Registrierung, öffentliche APIs und teure Funktionen wie KI-Aufrufe setzen, Uploads auf Typ und Grösse prüfen, Webhooks signieren und verifizieren.
Erledigt, wenn: Rate Limits sind auf den genannten Endpunkten aktiv und getestet, und eingehende Webhooks werden nur mit gültiger Signatur verarbeitet.
- 08
Vorfallablauf vorbereiten
Festlegen, wer bei einem Sicherheitsvorfall entscheidet, wie Kunden informiert werden und wie Datenschutz-Meldepflichten geprüft werden. Kontaktdaten und Vorlagen bereithalten.
Erledigt, wenn: Ein schriftlicher Ablauf mit Rollen, Kontakten und Vorlagen liegt vor und ist dem Team bekannt.
Häufige Fehler
- —Mandantentrennung wird nur in den API-Routen geprüft, und eine neue Route vergisst den Filter.
- —Der Service-Schlüssel der Datenbank landet im Frontend-Bundle.
- —Backups laufen, aber niemand hat je eine Wiederherstellung versucht.
- —KI-Funktionen haben kein Rate Limit und werden zum Kostenrisiko.
- —Der Penetrationstest wird beauftragt, bevor die Grundlagen stimmen, und findet hauptsächlich Offensichtliches.
Was diese Checkliste nicht abdeckt
- —Diese Checkliste ersetzt keinen Penetrationstest und keine umfassende Sicherheitsprüfung durch Fachleute.
- —Sie deckt Grundlagen ab; regulierte Branchen und Kunden mit eigenen Vorgaben stellen zusätzliche Anforderungen, etwa an Zertifizierungen.
- —Organisatorische Informationssicherheit wie Richtlinien, Schulungen und Lieferantenmanagement wird nur am Rand behandelt.
- —Infrastruktur ausserhalb der Anwendung, etwa Netzwerk und Endgeräte des Teams, ist nicht Gegenstand dieser Liste.
Übergeordnete Leistung: SaaS-Produktentwicklung
Passende Angebote
SaaS Security & RLS Audit
Ein SaaS-Security-Audit prüft gezielt die Mandantentrennung: Ist Row-Level-Security wasserdicht, greift die Zugriffskontrolle, sind typische Supabase-Fallen (Service-Role im Client, fehlende RLS) vermieden? Ergebnis ist ein Befund mit konkreten Fixes.
SaaS-Launch-Paket
Das Launch-Paket bringt ein SaaS-Produkt von der Idee zum Markt: tragfähige Architektur, die entscheidenden Kern-Funktionen, Billing, Onboarding und Deployment — geführt und mit klarem Fokus auf den ersten zahlenden Kunden. Ergebnis ist kein Prototyp, sondern ein produktionsreifes Produkt, das Umsatz erzeugen kann.
Häufige Fragen
Braucht ein neues SaaS-Produkt vor dem Go-live einen Pentest?
Bei sensiblen Daten oder Unternehmenskunden ist er sinnvoll, aber erst, wenn die Grundlagen dieser Liste stimmen. Sonst bezahlt man dafür, dass Fachleute Offensichtliches finden.
Reicht Mandantentrennung in der Anwendungslogik?
Sie funktioniert, solange niemand einen Filter vergisst. Eine Trennung auf Datenbankebene, etwa mit Row Level Security, hält auch dann und ist deshalb die robustere Wahl.
Wie oft sollte die Wiederherstellung getestet werden?
Mindestens vor dem Go-live und danach in einem festen Rhythmus sowie nach grösseren Änderungen an Datenbank oder Infrastruktur.
Was gehört zur Sicherheit von KI-Funktionen?
Rate Limits und Kostenbegrenzung, serverseitig geprüfte Berechtigungen für Werkzeuge und eine Architektur, die Prompt Injection begrenzt. Details enthält unsere Checkliste zur Produktionsreife von LLM-Funktionen.
Weitere Checklisten
Checkliste: eine KI-Nutzungsrichtlinie, die tatsächlich befolgt wird
Eine wirksame KI-Nutzungsrichtlinie regelt in kurzer, verständlicher Form: welche Werkzeuge zugelassen sind, welche Daten hineingehören und welche nicht, dass Menschen Ergebnisse prüfen und verantworten, wann KI-Einsatz offengelegt wird, wie neue Werkzeuge freigegeben werden, welche Schulung es gibt, wie Vorfälle gemeldet werden und wann die Richtlinie überprüft wird.
Checkliste: KI-Anbieter und KI-Funktionen prüfen, bevor sie eingesetzt werden
Vor dem Einsatz eines KI-Dienstes sind zehn Fragen zu klären: Wird auf eigenen Daten trainiert, wo werden Daten verarbeitet, wie lange werden Eingaben gespeichert, gibt es einen Auftragsbearbeitungsvertrag, wie ist die Sicherheit belegt, welche Rolle hat man nach AI Act, welche Dokumentation liefert der Anbieter, wie werden Modellwechsel angekündigt, wie werden Kosten begrenzt und wie steigt man wieder aus.
Checkliste: KI in Kanzleien und Treuhandbüros sicher einsetzen
KI kann in Kanzleien und Treuhandbüros viel Zeit sparen, berührt aber Berufsgeheimnis und Datenschutz unmittelbar. Sicher wird der Einsatz mit geklärten Geheimhaltungspflichten, Werkzeugen mit Vertrag und ohne Training auf Mandantendaten, minimierten Daten, der Prüfung jeder Aussage und Fundstelle, Transparenz gegenüber Mandanten sowie Richtlinie und Schulung.