Lieferanten- und Drittanbieter-Risikomanagement für Startups
Lieferantenrisikomanagement heißt: wissen, welche Dritten an deine Daten kommen, entscheiden, wie viel Sicherheitsnachweis jeder von ihnen braucht, und dieses Urteil aktuell halten. ISO 27001 deckt das in A.5.19 bis A.5.23 ab — Lieferantenbeziehungen, Sicherheit in Lieferantenvereinbarungen, IKT-Lieferkette, Überwachung und Änderungsmanagement sowie Cloud-Dienste — SOC 2 behandelt es unter CC9. Für ein Startup ist die machbare Variante: ein einziges Lieferantenregister, drei Stufen nach dem, worauf ein Anbieter wirklich zugreifen kann, Nachweisanforderungen passend zur Stufe und eine jährliche Nachprüfung, die abgelaufene Berichte und still gewechselte Unterauftragsverarbeiter aufdeckt.
Lieferantenrisikomanagement ist die Praxis, zu wissen, welche Dritten an deine Daten kommen, zu entscheiden, wie viel Sicherheitsnachweis jeder von ihnen braucht, und dieses Urteil aktuell zu halten. Du erbst das Sicherheitsniveau deiner Lieferanten, ob du es prüfst oder nicht — die einzige Variable ist, ob du es nach deinem Zeitplan erfährst oder mitten in einem Vorfall.
Für ein Startup mit dreißig SaaS-Tools und einem Cloud-Anbieter klingt das nach einem Programm, für das du die Leute nicht hast. Ist es nicht. Die machbare Variante besteht aus einem einzigen Register, drei Stufen und einem jährlichen Durchgang.
Wo die Frameworks das verorten
ISO 27001 verteilt die Lieferantenanforderungen auf fünf Controls in Anhang A — deshalb wirkt das Thema größer, als es ist:
- A.5.19 — Informationssicherheit in Lieferantenbeziehungen. Definiere und wende Prozesse an, um die Risiken aus der Nutzung von Lieferanten zu steuern.
- A.5.20 — Adressierung von Informationssicherheit in Lieferantenvereinbarungen. Die Sicherheitsanforderungen gehören in den Vertrag, nicht nur in die Bewertung.
- A.5.21 — Umgang mit Informationssicherheit in der IKT-Lieferkette. Deine Lieferanten haben Lieferanten.
- A.5.22 — Überwachung, Überprüfung und Änderungsmanagement von Lieferantendienstleistungen. Sicherheitsnachweise sind kein einmaliges Ereignis.
- A.5.23 — Informationssicherheit bei der Nutzung von Cloud-Diensten. Neu in der Revision 2022 und für ein cloud-natives Startup das relevanteste — siehe das Control-Mapping von 2013 auf 2022 dazu, wie sich die Struktur von Anhang A verändert hat.
SOC 2 deckt dasselbe Feld unter Common Criteria CC9 ab, das die Risikominderung einschließlich Lieferanten- und Geschäftspartnerrisiko behandelt. In der Praxis erfüllt ein Prozess beides. Operativ gehört Lieferantensteuerung zu Kapitel 8 Betrieb — es ist ein Prozess, den du fährst, kein Dokument, das du ablegst.
Schritt 1: Baue das Register aus der Buchhaltung, nicht aus dem Gedächtnis
Das Lieferantenregister ist das Fundament, und der schnellste ehrliche Weg dorthin ist ein Export von zwölf Monaten Kartenzahlungen und Rechnungen aus der Buchhaltung. Das Gedächtnis liefert die Liste der Tools, die du magst; die Buchhaltung liefert die Liste der Tools, die du hast — inklusive derer, die ein einzelnes Team eingeführt hat, ohne jemandem Bescheid zu sagen.
Gleiche das mit der Anwendungsliste deines SSO und den Marketplace-Abos deines Cloud-Anbieters ab. Alles, was in der Buchhaltung auftaucht, aber nicht im Register steht, ist entweder Schatten-IT, die du unter Kontrolle bringen musst, oder ein Abo, das du kündigen kannst — beides ist ein nützliches Ergebnis.
Mindestfelder pro Lieferant: Name, erbrachte Leistung, interner Verantwortlicher, welche Daten berührt werden, ob personenbezogene Daten verarbeitet werden, Stufe, vorliegender Sicherheitsnachweis samt Datum, Vertragsverlängerungsdatum und Datum der letzten Prüfung.
Schritt 2: Stufe danach ein, worauf sie tatsächlich zugreifen können
Nach Ausgaben einzustufen ist der klassische Fehler. Ein Tool für $30 im Monat mit Zugriff auf die Produktionsdatenbank ist ein größeres Risiko als eine Recruiting-Plattform für $50,000. Stufe stattdessen nach Zugriff ein:
| Stufe | Definition | Erwarteter Nachweis |
|---|---|---|
| Stufe 1 — Kritisch | Speichert, verarbeitet oder kann auf Kundendaten oder Produktionssysteme zugreifen. Cloud-Hosting, Datenbankplattformen, Support-Tools, alles mit einem API-Key in die Produktion. | Aktueller SOC 2 Type II Report oder ISO-27001-Zertifikat; Auftragsverarbeitungsvertrag, wenn personenbezogene Daten im Spiel sind; Liste der Unterauftragsverarbeiter; dokumentierte Auswertung des Reports selbst. |
| Stufe 2 — Wichtig | Verarbeitet Unternehmens- oder Mitarbeiterdaten, aber keine Kundendaten — HR, Finanzen, interne Kommunikation. | Attestierung oder Zertifikat, sofern vorhanden; Durchsicht der Security-Seite; Auftragsverarbeitungsvertrag, wo zutreffend; leichtere dokumentierte Prüfung. |
| Stufe 3 — Gering | Kein Zugriff auf sensible Daten. Design-Tools, Einzelplatz-Helfer, Marketing-Seiten. | Eintrag im Register und ein Verantwortlicher. Keine formale Bewertung. |
Drei Stufen reichen. Fünfstufige Modelle sehen gründlich aus und erzeugen in einer Zehn-Personen-Firma vor allem Diskussionen darüber, ob etwas eine 3 oder eine 4 ist.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Schritt 3: Fordere Nachweise an, die etwas bedeuten
Bei Lieferanten der Stufe 1 ist die Anfrage unkompliziert: der aktuellste SOC 2 Type II Report oder das ISO-27001-Zertifikat samt Erklärung zur Anwendbarkeit, dazu ein Auftragsverarbeitungsvertrag und die Liste der Unterauftragsverarbeiter, wenn personenbezogene Daten betroffen sind.
Entscheidend ist, was du danach tust. Einen Report einzusammeln und ungelesen abzulegen ist ein Control, das nur auf dem Papier existiert — und genau da haken Prüfer nach, wenn sie fragen, wie du einen Lieferanten bewertet hast. Wenn ein Report eintrifft, prüfe mindestens: Deckt der Berichtszeitraum die Zeit ab, in der du dich tatsächlich auf den Anbieter verlassen hast? Umfasst der Scope den Dienst, den du nutzt, und nicht eine andere Produktlinie? Ist das Prüfungsurteil uneingeschränkt? Und sind die genannten Abweichungen welche, mit denen du leben kannst? Lies anschließend die Complementary User Entity Controls — die Dinge, die du tun musst, damit die Controls des Anbieters überhaupt funktionieren. Genau diesen Abschnitt überspringen Kunden am häufigsten. Unser Leitfaden zum Lesen des SOC 2 Reports eines Anbieters geht das ganze Dokument durch.
Halte für jeden Stufe-1-Lieferanten ein kurzes schriftliches Fazit fest: was du geprüft hast, was du gefunden hast, was du akzeptiert hast. Zwei Sätze genügen. Ohne das hast du einen Aktenschrank, keine Bewertung.
Schritt 4: Schreibe die Anforderungen in den Vertrag
A.5.20 existiert, weil dir eine Bewertung ohne vertragliche Grundlage nichts gibt, das du durchsetzen kannst. Bei Stufe-1-Lieferanten lohnen sich schriftlich: Meldepflicht bei Sicherheitsvorfällen mit definierter Frist, ein Anspruch auf aktualisierte Prüfberichte, Benachrichtigung bei Wechsel von Unterauftragsverarbeitern, Rückgabe und Löschung der Daten bei Vertragsende sowie Vertraulichkeitspflichten.
Realistisch wird ein Fünf-Personen-Startup mit einem Hyperscaler keine maßgeschneiderten Klauseln verhandeln — du akzeptierst den Standard-Auftragsverarbeitungsvertrag und vermerkst diese Annahme im Register. Das ist ein legitimes Ergebnis, und die Dokumentation der Entscheidung ist genau das, was ein akzeptiertes Risiko von einem übersehenen unterscheidet.
Schritt 5: Behalte die Kette der Unterauftragsverarbeiter im Blick
Deine Lieferanten haben Lieferanten, und deren Änderungen werden zu deinen Änderungen. Genau darum geht es in A.5.21. Praktische Variante für ein kleines Team: Abonniere die Benachrichtigungen über Wechsel von Unterauftragsverarbeitern, die deine Stufe-1-Lieferanten anbieten, und vermerke im Register, wo sich die kritischen Abhängigkeiten eines Anbieters mit deinen überschneiden.
Diese Überschneidung ist einen ausdrücklichen Blick wert. Wenn dein Hosting, dein Monitoring und dein E-Mail-Versand letztlich alle auf demselben Cloud-Anbieter in derselben Region liegen, hast du ein Klumpenrisiko, das keine der einzelnen Bewertungen zutage fördert — und es gehört als Eintrag in dein Risikoregister, nicht nur in deine Lieferantenliste.
Schritt 6: Jährlich nachprüfen — und bei jeder Änderung
A.5.22 verlangt Überwachung und Überprüfung über die Zeit, weil Sicherheitsnachweise verfallen. SOC 2 Reports decken einen festen Zeitraum ab und veralten; Zertifikate laufen aus; Anbieter werden übernommen; Produkte ändern ihre Architektur.
Ein jährlicher Durchgang über die Lieferanten der Stufen 1 und 2 ist eine vernünftige Grundlinie, ergänzt um anlassbezogene Prüfungen, wenn ein Anbieter übernommen wird, eine öffentlich bekannt gewordene Datenpanne erleidet, seine Unterauftragsverarbeiter wesentlich ändert oder wenn deine eigene Nutzung auf sensiblere Daten ausgeweitet wird. Lege den Durchgang in denselben Kalender wie deine anderen wiederkehrenden Prüfungen — siehe die Monitoring-Checkliste für das ganze Jahr.
Das Offboarding verdient dieselbe Disziplin wie das Onboarding: Wenn du einen Anbieter nicht mehr nutzt, lass die Datenlöschung bestätigen, widerrufe API-Keys und Integrationen und schließe den Registereintrag mit einem Datum ab. Schlafende Integrationen mit gültigen Zugangsdaten sind eine wiederkehrende Prüfungsfeststellung und ein echtes Risiko.
Das Fazit
Baue das Register aus der Buchhaltung, damit es ehrlich ist, stufe nach Zugriff statt nach Ausgaben ein, fordere von Stufe-1-Lieferanten echte Nachweise und lies sie auch wirklich, bring die Sicherheitsklauseln in den Vertrag und prüfe einmal im Jahr nach. Das ist ein Lieferantenrisiko-Programm, das ein kleines Team tatsächlich stemmen kann — und es erfüllt sowohl A.5.19–A.5.23 als auch CC9 ohne eine eigene Stelle dafür.
Als Nächstes: wie du den SOC 2 Report eines Anbieters liest, wann sich dein eigener SOC 2 lohnt, jetzt wo du auf der anderen Seite dieser Fragebögen stehst, oder sieh dir an, wie die Lieferantenbewertung in AuditBadger Register, Nachweise und Prüftermine an einem Ort hält.
