Ein Notfallplan auf einer Seite für Solo-Gründer

Ein Notfallplan für Solo-Gründer sollte Ihnen sagen, was bei einer Sicherheitsmeldung zu tun ist: Fakten festhalten, Hilfe auswählen, die nächste Maßnahme bestimmen und einen Zeitpunkt für die erneute Prüfung festlegen. Halten Sie diese erste Seite offline bereit und verweisen Sie darin auf die ausführlichen Verfahren. Üben Sie den Ablauf anschließend mit einer fiktiven Meldung.

Am 2. November 2026 veröffentlichte NIST Small Business Cybersecurity: Non-Employer Firms, einen Leitfaden für Unternehmen, deren Inhaber die einzigen bezahlten Beschäftigten sind. Die Diskussion auf Hacker News bietet einen aktuellen Anlass für eine praktische Frage: Könnten Sie heute Abend auf eine Meldung reagieren, ohne den Ablauf erst erfinden zu müssen?

Dafür brauchen Sie kein großes Sicherheitsteam. Sie sollten aber wissen, wo Ihre eigenen Fähigkeiten enden und wessen Hilfe Sie tatsächlich erreichen können.

Planen Sie für den Fall, dass Ihre üblichen Werkzeuge ausfallen

Die erste Seite ist eine Entscheidungshilfe, kein vollständiges Sicherheitshandbuch. Sie sollte zu Ihren Ansprechpartnern und Verfahren führen, selbst wenn Ihre geschäftliche E-Mail oder Ihr gewohntes Dokumentenkonto nicht verfügbar ist.

Der neue NIST-Leitfaden erklärt Cybersicherheit verständlich. Zu jeder Maßnahme beschreibt er Einstiegsmöglichkeiten und die Weiterentwicklung bei wachsendem Geschäft. Unser einseitiges Format ist eine redaktionelle Anpassung für Gründer eines kleinen Softwareunternehmens. NIST schreibt weder dieses Format noch eine bestimmte Reaktionszeit oder eine Plattform zur Meldung von Schwachstellen vor.

Füllen Sie den Plan zunächst für einen Dienst aus. Wählen Sie das Produkt, auf das Ihre Kunden angewiesen sind, statt jedes eigene Gerät dokumentieren zu wollen. Bewahren Sie eine Offline-Kopie sicher auf. Notieren Sie Zugangshinweise, keine Passwörter oder Wiederherstellungscodes.

Mit einem Namen allein ist es nicht getan. Ist Ihr technischer Kontakt freiberuflich tätig, klären Sie vorher, ob die Person Unterstützung zugesagt hat, wann sie erreichbar ist und welchen Zugang sie benötigt. Stellen Sie nicht erst während eines Vorfalls fest, dass „jemanden mit technischem Wissen anrufen“ die Suche nach einer fremden Person bedeutet.

Trennen Sie die eingehende Meldung von der Bewertung als Vorfall

Eine Sicherheitsmeldung liefert Informationen, die Sie prüfen müssen. Dahinter können eine echte Schwachstelle, ein Missverständnis oder Hinweise auf einen laufenden Angriff stecken. Bestätigen Sie zunächst den Eingang, ohne eine dieser Möglichkeiten als geklärt darzustellen.

Nutzen Sie diese Entscheidungstabelle als Ausgangspunkt für Ihre eigenen Verfahren. Sie ist unser Praxisbeispiel, keine NIST-Schweregradskala.

Bitten Sie Forscher nicht, weitere Kundendatensätze als Beweis zu sammeln. Verwenden Sie eigene autorisierte Testkonten. Ziehen Sie eine qualifizierte Fachkraft hinzu, wenn die Untersuchung weitere Daten offenlegen oder den Dienst unterbrechen könnte.

Eine erste Antwort kann kurz sein: „Wir haben Ihre Meldung erhalten und prüfen die betroffene Funktion. Bitte greifen Sie nicht auf weitere Kundendaten zu und senden Sie uns keine zusätzlichen Kundendaten. Wir melden uns bis [Uhrzeit und Zeitzone].“ Wählen Sie einen Termin, den Sie einhalten können, auch wenn Sie dann lediglich über die laufende Untersuchung berichten.

Wie Sie einen öffentlichen Meldekanal samt Geltungsbereich definieren, erläutert unser Leitfaden für ein Vulnerability Disclosure Program. Der Notfallplan beschreibt, was Sie tun, nachdem dort eine Meldung eingegangen ist.

Üben Sie mit einer fiktiven Meldung, bevor eine echte eintrifft

Eine Übung sollte fehlende Kontakte und Entscheidungen aufzeigen, ohne Produktivsysteme zu verändern. Gehen Sie ein fiktives Szenario durch, notieren Sie Hindernisse und verbessern Sie den Plan.

Der Leitfaden für kleine Unternehmen des Australian Signals Directorate empfiehlt einfache Übungen, die Prüfung von Reaktionszeiten und Entscheidungen sowie die anschließende Überarbeitung der Pläne. Die folgende SaaS-Übung ist unser Vorschlag, dieses Prinzip anzuwenden.

Stellen Sie sich vor, ein Forscher schreibt: „Über diese URL kann ich auf die exportierte Datei eines anderen Kunden zugreifen.“ Sie brauchen weder eine echte Datei noch Kundendaten. Kennzeichnen Sie die Übung eindeutig und verwenden Sie dafür keine öffentlichen Meldekanäle.

1. Finden Sie die Seite. Nehmen Sie an, Ihre geschäftliche E-Mail ist ausgefallen. Finden Sie den Offline-Plan und Ihre Ansprechpartner?
2. Legen Sie einen Übungsdatensatz an. Notieren Sie Eingang der fiktiven Nachricht, Behauptung, offene Fragen und die Verantwortung für die nächste Entscheidung.
3. Entwerfen Sie die Eingangsbestätigung. Nennen Sie einen Termin für das nächste Update, ohne einen bestätigten Datenabfluss oder eine abgeschlossene Behebung zu behaupten.
4. Bestimmen Sie die Eskalation. Wer kann die relevanten Zugriffsprotokolle prüfen und die betroffene Exportfunktion einschränken? Beschreiben Sie die Maßnahme, führen Sie sie nicht im Produktivsystem aus.
5. Finden Sie das Wiederherstellungsverfahren. Benennen Sie benötigte Zugänge und Prüfungen, mit denen sich die sichere Wiederaufnahme des Dienstes feststellen ließe.
6. Halten Sie Lücken fest. Ersetzen Sie „Protokolle prüfen“ durch den tatsächlichen Speicherort und Zugangsweg. Ersetzen Sie „Hoster kontaktieren“ durch den überprüften Supportweg.

Begrenzen Sie die Übung auf einen Zeitraum, der in Ihren Tag passt. Die Übung soll Ihren Plan verbessern. Eine schnelle Durchführung beweist keine Einsatzfähigkeit. Können Sie niemanden benennen, der die gemeldete Offenlegung beurteilen könnte, ist auch das ein nützliches Ergebnis: Organisieren Sie diese Hilfe, bevor Sie sich auf den Plan verlassen.

Führen Sie während Reaktion und Wiederherstellung ein sachliches Protokoll

Trennen Sie gesicherte Fakten von Vermutungen. Halten Sie für jede folgenreiche Maßnahme Zeitpunkt, Verantwortung und Begründung fest. So lässt sich später nachvollziehen, wie sich Ihr Kenntnisstand verändert hat.

Die Empfehlungen zur Reaktion in CSWP 50 empfehlen, Erkennungszeitpunkt, relevante Protokolle und Screenshots sowie ergriffene Maßnahmen zu dokumentieren. Sie behandeln außerdem Übungen, offline verfügbare wichtige Kontakte und die Integritätsprüfung von Backups vor der Wiederherstellung. Prüfen Sie Ihre erste Seite und die verlinkten Verfahren anhand dieser Punkte.

Für die fiktive Exportmeldung könnte ein Eintrag lauten: „14:10 UTC: Meldung eingegangen. Forscher behauptet kundenübergreifenden Dateizugriff. Noch nicht reproduziert. Verantwortlich: Gründer. Nächste Maßnahme: Technische Fachkraft prüft Exportberechtigungen und verfügbare Zugriffsprotokolle.“ Ein späterer Eintrag kann die Arbeitshypothese korrigieren, ohne den ursprünglichen Eintrag umzuschreiben.

Eine bereitgestellte Korrektur, ein wiederhergestellter Dienst und eine verifizierte Behebung beantworten unterschiedliche Fragen. Legen Sie fest, welche Prüfungen Ihr Dienst braucht und wer sie durchführen kann. Wenn Sie ein Backup verwenden, folgen Sie Ihrem Wiederherstellungsverfahren und prüfen Sie den wiederhergestellten Dienst, bevor Sie die Wiederherstellung als abgeschlossen betrachten.

Klären Sie auch Ihre geltenden Benachrichtigungspflichten im Voraus. Der Leitfaden setzt keine weltweit gültige gesetzliche Frist. Eine Schwachstellenmeldung allein belegt auch keine Pflicht zur Kundenbenachrichtigung. Halten Sie fest, wo Ihre vertraglichen und landesspezifischen Anforderungen dokumentiert sind und wen Sie dazu befragen würden.

Nutzen Sie Kit zur Meldungskoordination neben Ihrem Notfallplan

Ein Meldungsablauf kann Verantwortung, Korrespondenz und Fortschritt zusammenführen. Ihr Offline-Plan muss weiterhin Ansprechpartner, Systemwiederherstellung und Entscheidungen außerhalb dieses Ablaufs abdecken.

Kits Sicherheitsbereich unterstützt zugewiesene Meldungen, die Korrespondenz mit Forschern, interne Notizen und einen Meldungsverlauf. Der Lebenszyklus einer Meldung unterscheidet Untersuchung und Behebung von der Verifizierung der Korrektur. Diese Funktionen helfen Ihnen, eine Schwachstellenmeldung während der Untersuchung weiterzubearbeiten. Sie stellen weder fest, ob ein Vorfall eingetreten ist, noch stellen sie Ihre Infrastruktur wieder her.

Wenn Sie Kit bereits nutzen, üben Sie mit einem eindeutig gekennzeichneten Übungsdatensatz. Prüfen Sie, ob Sie die verantwortliche Person, die Korrespondenz und die nächste Maßnahme finden. Beschränken Sie den Zugriff auf sensible Unterlagen auf die Personen, die sie benötigen. Prüfen Sie den Sicherheitsbereich, um zu entscheiden, ob er zu Ihrer Meldungsbearbeitung passt.

Beginnen Sie mit der Seite, die Sie heute Abend verwenden können: ein erreichbarer Kontakt, eine Ablage für Nachweise, eine entscheidungsverantwortliche Person und ein Termin für das nächste Update. Gehen Sie die fiktive Meldung damit durch, beheben Sie eine Lücke und speichern Sie die überarbeitete Offline-Kopie.