Ausgangslage
Ein Technologie-Startup in Vilnius, Litauen, mit rund 20 Mitarbeitenden entwickelt ein SaaS-Produkt für Unternehmen aus der Finanz- und Versicherungsbranche. Das Team ist technisch stark, das Produkt läuft in der Cloud, die Kunden sind mittelgroße und große Unternehmen in Litauen und Skandinavien. Der Vertriebszyklus ist lang, und jeder ernsthafte Kunde schickt vor der Unterschrift einen Sicherheitsfragebogen: Dutzende oder mehrere Hundert Fragen zu Richtlinien, Zugriffsverwaltung, Incident Management, Lieferanten und Betriebskontinuität.
Der Wendepunkt kam, als das Startup eine Ausschreibung bei einer skandinavischen Versicherung verlor. Das Produkt hatte dem Auftraggeber gefallen, doch in fast jeder Zeile des Sicherheitsfragebogens stand als Antwort „Ein Dokument haben wir nicht, aber wir machen es so“, während ein Wettbewerber ein ISO-27001-Zertifikat vorweisen konnte. Die Antwort des Auftraggebers war höflich und eindeutig: Melden Sie sich wieder, wenn Sie es haben.
Im Unternehmen gab es keine Sicherheitsfachkraft, und eine Stelle nur für einen Fragebogen zu schaffen, ergab keinen Sinn. Der CTO verstand etwas von Sicherheit, aber Richtlinien zu schreiben, ein Risikoregister zu führen und die Sprache der Audits zu sprechen, war nicht seine Aufgabe – jemand musste schließlich das Produkt bauen. Gesucht war jemand, der Sicherheit als dauerhafte Funktion betreibt und nicht als Projekt, und der nicht wie eine Vollzeitstelle bezahlt werden muss.
Was gebraucht wurde
- Ein Informationssicherheits-Managementsystem nach ISO 27001, zugeschnitten auf ein Unternehmen mit 20 Personen und nicht auf einen Konzern.
- Dokumente, die man Kunden vorlegen kann: Richtlinien, ein Risikoregister, ein Incident-Plan, Lieferantenbewertungen.
- Die Fähigkeit, Sicherheitsfragebögen von Kunden in Tagen statt in Wochen auszufüllen.
- Bereitschaft für ein Zertifizierungsaudit innerhalb eines Jahres, damit bei der nächsten Ausschreibung die Antwort zumindest „Audittermin vereinbart“ lautet.
- Minimaler Aufwand für die Entwicklung, denn die Produktentwicklung darf nicht stillstehen.
Was wir getan haben
Monat 1: Bewertung und Risikoregister
Wir begannen mit einem IT-Sicherheitsaudit anhand der ISO-27001-Maßnahmenliste: Was setzt das Unternehmen in der Praxis bereits um, was geschieht ohne Dokumentation, und was fehlt vollständig? Es zeigte sich, dass die technischen Maßnahmen besser waren als erwartet: Code-Reviews, MFA, Verschlüsselung, Protokolle. Es fehlte die Management-Ebene: Wer ist wofür verantwortlich, wie werden Risiken bewertet, wie werden Vorfälle behandelt und wie werden Lieferanten geprüft?
Gemeinsam mit der Geschäftsleitung erstellten wir ein Risikoregister: rund dreißig Risiken mit Verantwortlichen, Bewertungen und vereinbarten Maßnahmen. Das Register wurde zur Grundlage für alles Weitere, denn ein ISO-27001-Auditor fragt zuerst nicht nach den Richtlinien, sondern danach, woher sie kommen.
Monate 2–3: Richtlinien und Prozesse
Wir verfassten vierzehn Richtlinien und Verfahren: Informationssicherheitsrichtlinie, Zugriffsverwaltung, Kryptografie, sichere Entwicklung, Incident Management, Betriebskontinuität, Lieferantenmanagement, Regeln zur zulässigen Nutzung und weitere. Jedes Dokument umfasst wenige Seiten, mit einer verantwortlichen Person und einem Datum für die Überprüfung. Das Prinzip war einfach: Ein Dokument beschreibt nur, was das Unternehmen tatsächlich tut oder ab nächster Woche verbindlich tun wird. Eine Richtlinie, die nicht gelebt wird, ist für ein Audit schlechter als gar keine.
Am schwierigsten war die Lieferantenbewertung. Das Startup nutzte mehrere Dutzend Cloud-Dienste, einige davon per Kreditkarte gebucht und ganz ohne Vertrag. Wir erfassten sie, ordneten sie nach der Sensibilität der Daten, holten bei den kritischen Lieferanten Sicherheitsnachweise ein und ersetzten zwei Dienste durch solche, die etwas vorweisen konnten.
Monat 4: Incident-Plan und Übungen
Den Incident-Management-Plan testeten wir mit einer Planübung (Tabletop-Übung) mit dem gesamten Team: Das Szenario waren Zugriffsschlüssel, die in einem öffentlichen Code-Repository veröffentlicht wurden. Die Übung zeigte, dass niemand wusste, wer die Kunden informiert und innerhalb welcher Frist. Wir erweiterten den Plan und bereiteten Vorlagen für die Kundenbenachrichtigung vor.
Monat 5: Fragebogen-Bibliothek und internes Audit
Aus den Richtlinien und dem Risikoregister bauten wir eine Bibliothek mit Antworten auf die häufigsten Fragen aus Kundenfragebögen, mit Verweisen auf Dokumente und Nachweise. Wir führten ein internes Audit gegen die Anforderungen von ISO 27001 durch und hielten die Abweichungen sowie einen Plan zu ihrer Behebung fest. Von diesem Punkt an läuft der vCISO-Service als laufende Betreuung weiter: ein monatliches Treffen mit der Geschäftsleitung, die Überprüfung des Risikoregisters, das Ausfüllen neuer Fragebögen und die Vorbereitung auf das Zertifizierungsaudit.
Ergebnis
Sicherheitsfragebögen von Kunden werden inzwischen in 3 Werktagen ausgefüllt, einschließlich der Prüfung durch den CTO. Früher dauerte das Wochen und endete mit leeren Zeilen. In den vergangenen zwei Monaten wurden drei Fragebögen bearbeitet, einer davon aus derselben Branche, in der die Ausschreibung verloren gegangen war.
Es gibt 14 freigegebene Richtlinien und Verfahren, alle mit Verantwortlichen und Prüfterminen, und für die Mitarbeitenden an einem Ort verfügbar. Die Abweichungen aus dem internen Audit sind geschlossen, die Bereitschaft für das Zertifizierungsaudit ist hergestellt, der Termin ist vereinbart.
Die Zahl der Neueinstellungen im Bereich Sicherheit beträgt 0. Die Sicherheitsfunktion übernimmt ein vCISO mit vereinbarten Stunden pro Monat, und die Entwickler sind zum Produkt zurückgekehrt. Der CTO hat nachgerechnet: In fünf Monaten hat er weniger Zeit für Sicherheit aufgewendet als früher für einen einzigen verlorenen Fragebogen.
Wir dachten, ISO 27001 sei ein Papierberg für große Unternehmen. Es stellte sich heraus, dass es nur eine Liste von Fragen ist, die wir ohnehin beantworten mussten.
Was wir in einer ähnlichen Situation raten
- Beginnen Sie nicht mit Richtlinienvorlagen. Beginnen Sie mit dem Risikoregister: Die Richtlinien ergeben sich daraus von selbst, und der Auditor sieht den Zusammenhang.
- Schreiben Sie nur auf, was Sie tun. Ein Auditor findet ein Dokument, das nicht gelebt wird, innerhalb der ersten Stunde.
- Klären Sie die Lieferanten früh: Per Kreditkarte gebuchte Cloud-Dienste sind die häufigste Abweichung bei kleinen Technologieunternehmen.
- Trennen Sie die Sicherheitsfunktion von der Leitung der Entwicklung, auch wenn sie sich damit auskennt. Ihre Zeit kostet Sie das Produkt.
