Warum ist Ihre IT-Lieferkette im Gaming-Bereich nun Teil Ihrer Angriffsfläche?
Ihre IT-Lieferkette im Gaming-Bereich stellt einen Teil Ihrer Angriffsfläche dar, da Spieler Ausfälle, Fehler und Sicherheitslücken Ihrer Zulieferer als Ihre eigenen Fehler wahrnehmen. Jede Engine, jedes SDK, jeder Cloud-Dienst und jeder Zahlungsanbieter, der Spielerdaten, Spiellogik oder Einnahmen verarbeitet, fungiert im Grunde als Teil Ihrer eigenen Plattform. Schwachstellen in diesen Verbindungen führen daher schnell zu Schwachstellen in Ihrem gesamten Service.
Ihre Spiele sind heute von einem komplexen Netzwerk aus Engines, Cloud-Diensten, SDKs und Zahlungssystemen abhängig, das weit über Ihren eigenen Code und Ihre Server hinausgeht. Ein moderner Stack kann auf einer kommerziellen Engine, mehreren Analyse- und Werbe-SDKs, Anbietern für Social Login, verschiedenen Zahlungsgateways, einem Content Delivery Network, Anti-Cheat-Systemen, Moderationstools und Build- oder Patching-Pipelines basieren, die Sie nicht selbst betreiben. Jede dieser Komponenten verarbeitet Spielerdaten, Spiellogik, kryptografische Geheimnisse oder Einnahmen und vergrößert somit Ihre Angriffsfläche.
Wird der Update-Prozess eines Partners manipuliert, ein SDK eine Sicherheitslücke einführt oder eine Konfigurationsänderung ohne Vorwarnung eingeführt, spüren Sie die Auswirkungen, als wäre der Vorfall in Ihrer eigenen Umgebung passiert. Dies kann zu Ausfallzeiten während einer Live-Veranstaltung, beschädigten Fortschrittsdaten, unfairem Wettbewerbsvorteil oder direkten finanziellen Verlusten führen. Aus Sicht von Auditoren oder Aufsichtsbehörden sind Sie für die Verwaltung dieser Abhängigkeiten im Rahmen Ihres Informationssicherheitsmanagementsystems (ISMS) verantwortlich und dürfen sie nicht als Problem anderer abtun.
Diese Informationen sind allgemeiner Natur und stellen keine Rechts- oder Regulierungsberatung dar; Sie sollten Ihre genauen Verpflichtungen stets mit qualifizierten Fachleuten in den jeweiligen Rechtsordnungen, in denen Sie tätig sind, abklären.
Wie schaden Ausfälle von Drittanbietern konkret Spieleplattformen?
Ausfälle von Drittanbietern schaden Spieleplattformen, indem sie die Spielerlebnisse und Garantien beeinträchtigen, die Spielern, Partnern und Aufsichtsbehörden besonders wichtig sind. Ausfälle, Datenlecks oder unfaire Spielpraktiken, die von Zulieferern verursacht werden, schädigen Ihren Ruf, selbst wenn Ihr interner Code und Ihre Infrastruktur sicher sind. Solche Fehler werden schnell zu Ihrem Problem in den Augen Ihrer Community und Ihrer Geschäftspartner.
Ein großflächiger Cloud-Ausfall kann die Spielersuche oder die Anmeldung während eines wichtigen Events stundenlang lahmlegen. Ein kompromittiertes Analytics-SDK kann Zugangsdaten abgreifen und so Kontoübernahmen, Betrug und Rückbuchungsstreitigkeiten verursachen. Ein Fehler in einem externen Anti-Cheat-System kann legitime Spieler fälschlicherweise als solche identifizieren und das Vertrauen in kompetitive Ranglisten zerstören. In all diesen Fällen entscheiden Ihre Verträge, Ihre Architektur und Ihr Monitoring darüber, ob das Problem eingedämmt und erklärbar ist oder ob es sich zu einer ausgewachsenen Krise ausweitet, die die Zertifizierung und anstehende Audits gefährdet.
Warum ist das bei ISO 27001 speziell im Gaming-Bereich relevant?
ISO 27001 befasst sich mit den Risiken der IKT-Lieferkette im Gaming-Bereich, da moderne Spiele permanent verfügbare digitale Dienste sind, deren Zuverlässigkeit und Fairness von einem Ökosystem und nicht von einer einzelnen Anwendung abhängen. Gaming-Plattformen verarbeiten große Mengen an personenbezogenen Daten, Zahlungen und in einigen Fällen regulierte Glücksspielaktivitäten, weshalb Regulierungsbehörden und große Plattformen sie zunehmend als kritische Infrastrukturen einstufen.
Die Leitlinien zum Informationssicherheitsmanagement betonen, dass Organisationen externe Technologieanbieter als Teil ihrer eigenen Risikolandschaft betrachten müssen. Für die Spielebranche bedeutet dies, dass Anhang A.5.21 Cloud-Infrastruktur, Engines, SDKs, Anti-Cheat-Systeme, Identitäts- und Zahlungssysteme sowie die Infrastrukturen zur Erstellung und Verteilung von Clients und Inhalten umfassend abdeckt. Wenn Sie nur über Ihre eigenen Server sprechen und nicht über die damit verbundenen Dienste, wirken Ihre Sicherheitsstory, Ihr Risikoregister und Ihre Anwendbarkeitserklärung (SoA) auf Prüfer unvollständig.
KontaktWas genau verlangt Anhang A.5.21 der ISO 27001:2022 von Spieleanbietern?
ISO 27001:2022 Anhang A.5.21 verpflichtet Sie zur Definition und Durchführung wiederholbarer Prozesse zur Identifizierung und zum Management von Informationssicherheitsrisiken, die von den von Ihnen genutzten IKT-Produkten und -Dienstleistungen ausgehen. Konkret bedeutet dies, die relevanten Lieferanten zu kennen, deren Auswirkungen auf Ihre Spiele und Spieler zu verstehen und konsistente Bewertungs- und Behandlungsentscheidungen über deren gesamten Lebenszyklus hinweg nachweisen zu können.
Da der vollständige Text von Anhang A urheberrechtlich geschützt ist, beschreiben öffentliche Zusammenfassungen A.5.21 folgendermaßen: Sie sollten Prozesse und Verfahren zur Steuerung der Informationssicherheitsrisiken in der Lieferkette von IKT-Produkten und -Dienstleistungen definieren und implementieren. Der Standard schreibt keine spezifischen Tools vor und gibt keine Empfehlungen für bestimmte Lieferanten; er erwartet vielmehr, dass Sie über einen strukturierten Ansatz verfügen, um die von diesen Lieferanten ausgehenden Risiken zu verstehen und zu kontrollieren und diese Struktur in Ihr ISMS und Ihre SoA zu integrieren.
Für Anbieter von Spieltechnologie ergeben sich daraus Fragen wie: Welche Drittanbieter können Spielerdaten oder die Spielintegrität beeinflussen? Welche Mindestsicherheitsanforderungen erwarten Sie von ihnen? Wie überprüfen Sie dies vor und nach Vertragsunterzeichnung? Und wie reagieren Sie im Fehlerfall? Anhang A.5.21 ergänzt andere anbieterbezogene Kontrollen zur Definition von Anforderungen und zur Überwachung von Anbieterleistungen und bildet einen kleinen Bereich innerhalb der anbieterbezogenen Kontrollen von Anhang A. Dieser Bereich regelt die Zusammenarbeit mit externer Technologie im Rahmen Ihres umfassenderen Kontrollsystems gemäß Anhang A.
Wie fügt sich A.5.21 in den Rest Ihres ISMS ein?
Innerhalb Ihres ISMS ist A.5.21 die Kontrollmaßnahme, die das Lieferantenrisiko mit Ihren zentralen Risikomanagement- und Governance-Strukturen verbindet. Sie verknüpft Ihre Lieferantenliste, vertragliche Kontrollen, technische Architektur und Notfallpläne mit dem zentralen System, das die Zertifizierung und die Managementbewertung unterstützt.
Bei einer typischen Implementierung werden Sie:
- Verweisen Sie in Ihrer Leistungsbeschreibung auf A.5.21 und erläutern Sie dessen Anwendung und Begründung.
- Erfassen Sie die Risiken der IKT-Lieferkette in Ihrem zentralen Risikoregister und nicht in separaten Tabellenkalkulationen.
- Zeigen Sie auf, wie Lieferantenbewertungen, Vertragsklauseln und Überwachungsberichte in Managementbewertungen und interne Audits einfließen.
Weitere Kontrollen gemäß Anhang A regeln detaillierte Maßnahmen: Kontrollen für Lieferantenbeziehungen steuern Erwartungen und Überprüfungen; Kontrollen für sichere Entwicklung und Änderungsmanagement regeln die Integration von Engines und SDKs; Kontrollen für Protokollierung, Überwachung und Vorfallmanagement decken Erkennung und Reaktion ab. Sobald Ihr A.5.21-Prozess definiert ist, dient er als zentrale Schnittstelle, durch die Risiken der IKT-Lieferkette in dieses umfassendere Kontrollsystem einfließen.
Was umfasst der Begriff „IKT-Lieferkette“ im Gaming-Kontext?
Im Gaming-Kontext umfasst der Begriff „IKT-Lieferkette“ alle externen Produkte und Dienstleistungen, die die Vertraulichkeit, Integrität, Verfügbarkeit oder Compliance Ihrer Spiele und Plattform wesentlich beeinträchtigen können. Er ist umfassender als klassisches Outsourcing und schließt explizit Software-, Cloud- und Build-Pipeline-Abhängigkeiten ein, die Ihre Release-Zyklen und den laufenden Betrieb beeinflussen.
Dies umfasst üblicherweise Cloud-Infrastruktur und verwaltete Datenbanken; Game-Engines und Kernbibliotheken; Identitäts- und Zugriffsdienste; Anti-Cheat-, Betrugserkennungs- und Risikomanagement-Tools; Analyse-, Werbe- und Attributions-SDKs; Content Delivery Networks und Patch-Systeme; Backoffice-Dienste, die Berechtigungen oder Zahlungen beeinflussen; sowie unterstützende Dienste wie Kundensupport-Plattformen, die Konten zurücksetzen können. Open-Source-Komponenten und Build-Pipelines gehören ebenfalls dazu, selbst wenn Sie nicht direkt an einen Anbieter zahlen, da sie die Sicherheit und Vorhersagbarkeit Ihrer Veröffentlichungen und E-Sport-Saisons maßgeblich beeinflussen.
ISO 27001 leicht gemacht
Ein Vorsprung von 81 % vom ersten Tag an
Wir haben die harte Arbeit für Sie erledigt und Ihnen vom Moment Ihrer Anmeldung an einen Vorsprung von 81 % verschafft. Sie müssen nur noch die Lücken ausfüllen.
Wie können Sie Ihre Lieferkette für Gaming-IT im Hinblick auf A.5.21 analysieren, ohne den Überblick zu verlieren?
Sie analysieren Ihre Lieferkette für die IT-Infrastruktur im Gaming-Bereich gemäß A.5.21, indem Sie entscheiden, welche Lieferanten und Komponenten ein strukturiertes Risikomanagement erfordern und welche mit weniger strengen Prüfungen auskommen. Ein praktischer Weg, die Kontrolle zu behalten, ist die Erstellung eines gestaffelten Inventars, das den potenziellen Schaden jedes Anbieters im Falle eines Ausfalls oder einer Kompromittierung widerspiegelt. Anschließend richten Sie Ihre ISO-27001-Prozesse an diesen Stufen aus.
Anstatt jedes Cloud-Konto oder kleinere Tool gleichermaßen zu behandeln, identifizieren Sie zunächst die Anbieter, die für den reibungslosen Spielbetrieb, den Schutz der Spielergelder und die Einhaltung regulatorischer Vorgaben unerlässlich sind. Diese Anbieter bilden Ihre oberste Priorität für A.5.21 und sollten in Ihrem Risikoregister und Ihrer SoA-Begründung prominent vertreten sein. Alle anderen Anbieter können anhand klarer Schwellenwerte bewertet werden, sodass die Zeit Ihres Teams optimal genutzt wird und Sie die Festlegung des Untersuchungsbereichs gegenüber Wirtschaftsprüfern und wichtigen Partnern weiterhin nachvollziehbar erläutern können.
Wie lässt sich ein Lieferantenbestand sinnvoll aufbauen?
Ein sinnvoller Ansatz zum Aufbau Ihres Bestandsverzeichnisses besteht darin, mit den Systemen und Erfahrungen zu beginnen, die für Spieler und Kunden relevant sind, und sich dann zu den zugrunde liegenden Lieferanten vorzuarbeiten. Dies ist oft effektiver als die alleinige Auswertung von Rechnungen oder Beschaffungslisten, da es die tatsächlichen Auswirkungen von Ausfällen und Störungen im laufenden Betrieb widerspiegelt.
Sie können beispielsweise Kernspieldienste wie Login, Matchmaking, Spielfortschritt, Inventar, Zahlungen, Chat, Bestenlisten und Support auflisten. Ermitteln Sie für jeden Dienst, welche externen Parteien Technologie oder operative Kontrolle beisteuern, und gruppieren Sie die Anbieter anschließend in Kategorien wie Cloud-Hosting, Engines, SDKs, Zahlungen, Identitätsmanagement, Anti-Cheat-Systeme, Content-Delivery und Backoffice. Sobald Sie die Anbieter identifiziert haben, die zwischen Spielern, Daten und Geld liegen, können Sie jedem Anbieter Kritikalitäts- und Sensitivitätswerte zuweisen und überprüfen, ob die wichtigsten Anbieter eindeutig unter A.5.21 fallen.
Wie entscheidet man, was wirklich in den Geltungsbereich von A.5.21 gehört?
Sie legen den Anwendungsbereich fest, indem Sie technische, geschäftliche und regulatorische Auswirkungen in einfache, einheitlich anwendbare Kriterien zusammenfassen. Einige gezielte Fragen helfen Ihnen zu beurteilen, ob ein Lieferant eine vollständige Behandlung gemäß A.5.21 oder einen weniger strengen Ansatz erfordert.
Nützliche Tests sind beispielsweise:
- Verarbeitet oder beeinflusst dieser Anbieter personenbezogene, finanzielle oder anderweitig regulierte Spielerdaten?
- Könnte ein Fehler oder eine Kompromisslösung dazu führen, dass sich Spieler nicht mehr einloggen, bezahlen, Fortschritte erzielen oder fair miteinander konkurrieren?
- Erwarten Regulierungsbehörden, Plattformbetreiber oder wichtige Unternehmenskunden ausdrücklich, dass Sie diese Beziehung regeln?
- Wäre ein schneller Lieferantenwechsel ohne betriebliche oder kommerzielle Störungen schwierig?
Lautet die Antwort auf eine dieser Fragen „Ja“, ist der Lieferant ein aussichtsreicher Kandidat für die Aufnahme in Ihre A.5.21-Prozesse und Ihr Risikoregister. Gleichzeitig sollten Sie berücksichtigen, dass einige interne Tools mit geringem Risiko möglicherweise nicht den vollen Umfang Ihrer Lieferkettenverfahren rechtfertigen. Die Anwendung von Wesentlichkeitsschwellen und die Dokumentation von Scoping-Entscheidungen helfen Ihnen, verhältnismäßig zu bleiben, die Spielentwicklung nicht zu behindern und für Zertifizierungen oder Plattformbewertungen jederzeit erklärungsfähig zu sein.
Klare Abgrenzungen und einfache Hierarchieebenen machen die Lieferkettensicherheit zu einem Prozess, den Teams tatsächlich durchführen können.
Welche Governance- und Lebenszyklusprozesse benötigen Sie im Umfeld von ICT-Lieferanten?
Sie benötigen Governance- und Lebenszyklusprozesse, die das Lieferantenrisiko von einer punktuellen Absprache in einen wiederholbaren, nachvollziehbaren Bestandteil Ihrer Auswahl, Ihres Betriebs und Ihrer Beendigung von ITK-Dienstleistungen verwandeln. Das bedeutet, festzulegen, wer welche Lieferantentypen auf Basis welcher Nachweise genehmigen darf und wie Entscheidungen und Ausnahmen dokumentiert werden, damit Sie bei Audits und Plattformüberprüfungen die Kontrolle nachweisen können.
Die Governance für A.5.21 erfordert nicht für jeden Lieferanten ein neues Komitee, aber sie erfordert Klarheit. Ohne diese Klarheit fügen Entwickler SDKs unter Zeitdruck hinzu, der Einkauf verhandelt Verträge ausschließlich nach dem Preis, und die Sicherheitsabteilung kontaktiert Lieferanten erst, wenn bereits ein Fehler aufgetreten ist. Für ein Spieleunternehmen mit häufigen Releases und Live-Events tritt dies oft im ungünstigsten Moment auf. A.5.21 fördert ein koordiniertes Lebenszyklusmanagement, das sich in bestehende Lieferzyklen einfügt. Ein Weg dorthin ist die Definition eines einfachen, gemeinsamen Lebenszyklus, den jeder wichtige Lieferant durchläuft.
Wie sieht ein an A.5.21 ausgerichteter Lieferantenlebenszyklus aus?
Ein gemäß A.5.21 ausgerichteter Lebenszyklus umfasst üblicherweise fünf Phasen, die Sie beschreiben, zuordnen und nachweisen können. Jede Phase sollte klare Aktivitäten, Verantwortliche und Ergebnisse beinhalten, die mit Ihrem ISMS verknüpft sind.
Schritt 1 - Auswahl
Definieren Sie kategoriespezifische Sicherheits- und Resilienzanforderungen und prüfen Sie potenzielle Lieferanten anhand dieser Anforderungen, bevor die technische Integration beginnt.
Schritt 2 – Onboarding
Führen Sie eine strukturierte Risikobewertung durch, vereinbaren Sie vertragliche Kontrollen, weisen Sie interne Verantwortlichkeiten zu und dokumentieren Sie die Ergebnisse in Ihrem ISMS und Ihrer SoA.
Schritt 3 – Betrieb
Überwachen Sie die Leistung, Vorfälle und die Einhaltung vereinbarter Verpflichtungen und halten Sie die Lieferantenaufzeichnungen auf dem neuesten Stand, wenn sich Funktionen und Jahreszeiten ändern.
Schritt 4 – Änderung
Bewerten Sie das Risiko neu, wenn sich der Lieferant oder Ihre Nutzung des Lieferanten wesentlich ändert, z. B. bei der Verarbeitung neuer Daten oder bei höheren Transaktionsvolumina.
Schritt 5 – Beenden
Planen Sie die Rückgabe oder Löschung von Daten, die Schlüsselübergabe und den operativen Übergang, um unkontrollierte Offenlegung oder Ausfallzeiten bei Vertragsende zu vermeiden.
Indem Sie Ihren Lebenszyklus auf diese Weise darstellen, können Sie Prüfern, Plattformen und Unternehmenskunden zeigen, dass das Lieferantenrisiko als kontinuierlicher Prozess gemanagt wird und nicht als einmalige Maßnahme bei Vertragsunterzeichnung.
Wie lassen sich diese Prozesse integrieren, ohne die Spielentwicklung zu lähmen?
Sie werden integriert, indem Prüfungen an bereits bestehenden Entscheidungspunkten ausgerichtet werden: Genehmigungen für Fördermittel, Freigabe von Funktionen, größere Inhaltsaktualisierungen, E-Sport-Saisons und Vertragsverlängerungen. Ziel ist es, die Fragen aus A.5.21 in Momente zu integrieren, in denen Teams ohnehin schon Zeit für Entscheidungen einplanen, anstatt überall neue Prüfpunkte einzuführen und Release-Zyklen zu verzögern.
Wenn beispielsweise eine neue Anti-Cheat- oder Zahlungsintegration für eine Funktion unerlässlich ist, sollte die Entscheidung zur Implementierung die Bestätigung beinhalten, dass die grundlegenden Lieferantenprüfungen durchgeführt und die wichtigsten Klauseln vereinbart wurden. Wird ein bestehender Lieferant aktualisiert, um neue Arten von Spielerdaten oder höhere Transaktionsvolumina zu verarbeiten, sollte diese Änderung eine kurze Risikobewertung und gegebenenfalls Anpassungen der Überwachung oder der Verträge nach sich ziehen. Governance bildet so eine schlanke, aber konsistente Schicht über bestehenden Arbeitsabläufen und stellt kein Hindernis dar.
Eine Plattform wie ISMS.online kann helfen, indem sie eine zentrale Umgebung bietet, in der Lieferantendatensätze, A.5.21-konforme Risikobewertungen, Genehmigungen und Überwachungsprotokolle neben Ihren ISO 27001-Kontrollen verwaltet werden. Dadurch wird die Versuchung reduziert, für jede neue Geschäftsbeziehung separate, kurzlebige Tabellen zu erstellen, und die Einhaltung des gesamten Lebenszyklus lässt sich bei Audits leichter nachweisen.
Sobald die Grundlagen für Governance und Lebenszyklus geschaffen sind, können Sie sich konkreter mit den spezifischen Bedrohungen der IKT-Lieferkette auseinandersetzen, die für Ihre Spiele am wichtigsten sind.
Befreien Sie sich von einem Berg an Tabellenkalkulationen
Integrieren, erweitern und skalieren Sie Ihre Compliance, ohne dass es zu Problemen kommt. IO gibt Ihnen die Widerstandsfähigkeit und das Vertrauen, um sicher zu wachsen.
Welche Bedrohungen der IKT-Lieferkette treffen die Gaming-Branche am härtesten, und wie kann A.5.21 Abhilfe schaffen?
Die größten Bedrohungen für die Glücksspielbranche in der IT-Lieferkette sind diejenigen, die Verfügbarkeit, Fairness, Zahlungsintegrität oder das Vertrauen der Spieler durch Schwächen beeinträchtigen, die Sie nicht vollständig kontrollieren können. Mit einem definierten Prozess gemäß A.5.21 können Sie Ihre Governance auf die Lieferanten und Szenarien konzentrieren, die die größten Risiken für Ihre Spieler und Umsätze darstellen.
Gängige Beispiele sind die Übernahme von Konten durch kompromittierte Partner, in SDKs eingebettete Schadsoftware, die Manipulation von Ranglisten oder des Matchmakings durch Anbieterzugriffe sowie gefälschte oder manipulierte Zahlungsintegrationen. All dies nutzt die Diskrepanz zwischen dem Vertrauen, das Sie einem Anbieter entgegenbringen, und Ihrer Gewissheit über dessen Verhalten und Sicherheit aus. Für einen Spieleanbieter äußert sich dies oft in Störungen, negativen Reaktionen in der Community und unangenehmen Gesprächen darüber, ob die Sicherheitsvorkehrungen tatsächlich wirksam sind.
Wie lassen sich diese Bedrohungen praktischen Kontrollmaßnahmen zuordnen?
Sie können Bedrohungen praktischen Kontrollmaßnahmen zuordnen, indem Sie jedes Szenario mit spezifischen präventiven, detektiven und vertraglichen Maßnahmen verknüpfen und diese Zuordnung anschließend in Ihrem ISMS dokumentieren. Die folgende Tabelle veranschaulicht einen einfachen Ansatz für vier wichtige Bedrohungsarten.
Vor der Tabelle ist anzumerken, dass A.5.21 keine exakten Kontrollmaßnahmen für jedes Szenario vorschreibt. Vielmehr wird erwartet, dass Sie darlegen, wie Sie mögliche Missbrauchsrisiken bei Lieferanten durchdacht und angemessene Kontrollmaßnahmen gewählt haben, um diese Risiken in Ihrem Umfeld auf ein akzeptables Niveau zu reduzieren.
| Bedrohungsszenario | Beispiel für die Auswirkung im Gaming | Schlüssel A.5.21-ausgerichtete Bedienelemente |
|---|---|---|
| Kontoübernahme durch Partner | Spieler verlieren Zugang und Wert; Betrug und Support nehmen sprunghaft zu. | Strenge Anforderungen an Identitätsanbieter, Überwachung gemeinsam genutzter Sitzungen, klare Aufgaben im Vorfallsfall |
| Schadsoftware in SDKs oder Engines | Clients exfiltrieren Daten oder führen versteckten Code aus | Lieferantenprüfung, Integritätsprüfungen des Codes, Sandboxing, schnelle Not-Aus-Schalter |
| Manipulierte Ranglisten oder Spielersuche | Wettbewerbsszenen und In-Game-Ökonomien verlieren an Glaubwürdigkeit. | Aufgabentrennung für Datenverarbeitungspartner, Maßnahmen zur Betrugsbekämpfung, Prüfprotokolle |
| Gefälschte oder kompromittierte Zahlungsströme | Gestohlene Kartendaten, fehlgeleitete Einnahmen, Rückbuchungen | Zertifizierte Zahlungsanbieter, sicheres Integrationsmuster, Betrugsüberwachung, vertragliche Schutzmaßnahmen |
Diese Kontrollsätze stützen sich häufig auf andere Kontrollen gemäß Anhang A für Zugriffskontrolle, Überwachung, sichere Entwicklung und Vorfallmanagement. Ihr Prozess A.5.21 bietet jedoch den Governance-Rahmen, der besagt: „Wir haben diese Abhängigkeit berücksichtigt; deshalb vertrauen wir ihr und so überwachen wir sie.“ Jedes Szenario lässt sich in ein kurzes, wiederverwendbares Kontrollmuster Ihres ISMS umwandeln, das sichtbare Ergebnisse der Beteiligten mit klaren, nachvollziehbaren Maßnahmen verknüpft.
Gibt es andere ISO 27001-Controller, die A.5.21 im Gaming-Bereich unterstützen?
Ja. Während sich A.5.21 auf die Steuerung der IKT-Lieferkette konzentriert, werden mehrere andere Kontrollen aus Anhang A typischerweise denselben Risiken in Gaming-Umgebungen zugeordnet und sollten in Ihrer Handlungsanweisung und Ihren internen Verfahren erwähnt werden.
Die Kontrollen im Lieferantenbeziehungsmanagement erfordern die Definition von Sicherheitserwartungen und die Überprüfung der Lieferantenleistung. Kontrollen für sichere Entwicklung, technische Härtung und Konfigurationsmanagement unterstützen die sichere Integration von Engines, SDKs und Diensten. Protokollierungs- und Überwachungskontrollen helfen bei der Erkennung ungewöhnlichen Verhaltens im Zusammenhang mit Lieferanten. Maßnahmen zum Incident-Management und zur Geschäftskontinuität gewährleisten, dass Sie im Falle eines Ausfalls eines Drittanbieters, insbesondere im Zusammenhang mit wichtigen Ereignissen und saisonalen Spitzenzeiten, reagieren und sich erholen können.
Zusammengenommen bilden diese Kontrollen ein Geflecht: A.5.21 fordert Sie auf, die gesamte IKT-Lieferkette zu berücksichtigen; andere Kontrollen gemäß Anhang A bieten Ihnen die Werkzeuge, um spezifische Schwachstellen zu beheben. Durch die klare Dokumentation dieser Zusammenhänge erleichtern Sie es Auditoren, Plattformpartnern und Unternehmenskunden, nachzuvollziehen, wie sich das Lieferantenrisiko durch Ihr ISMS zieht und warum Ihr Ansatz verhältnismäßig ist.
Wie kann man einen praktischen A.5.21-Risikobewertungsprozess für Spieleanbieter entwerfen?
Sie können einen praktischen Risikobewertungsprozess gemäß A.5.21 gestalten, indem Sie einer kurzen, wiederholbaren Abfolge folgen: Erstellen Sie ein Inventar, klassifizieren Sie Lieferanten nach Kritikalität, identifizieren Sie relevante Bedrohungen, bewerten Sie das Risiko, wählen Sie Maßnahmen und dokumentieren Sie die Ergebnisse in Ihrem ISMS. Wichtig ist, dass die Methode so einfach ist, dass Teams sie anwenden, aber gleichzeitig so strukturiert, dass Auditoren und Partner die Konsistenz erkennen und nachvollziehen können, dass wichtige Lieferanten tatsächlich sorgfältiger behandelt werden als weniger wichtige.
Für Spieleanbieter muss dieser Prozess mit schnellen Veränderungen Schritt halten. Ständig kommen neue Anbieter, SDKs und Services auf den Markt; Ihr Prozess sollte dieses Tempo bewältigen, ohne sich jedes Mal neu erfinden zu müssen. Ein gutes Zeichen ist es, wenn Entwickler oder Produzenten die zentralen Risikofragen mit minimaler Unterstützung von Spezialisten beantworten können, weil die Kriterien und Vorlagen klar sind, und wenn Sie eine kleine Anzahl repräsentativer Bewertungen als Nachweis für ISO-27001-Audits und SoA-Reviews vorlegen können.
Wie sieht eine schrittweise A.5.21-Bewertung aus?
Eine schrittweise A.5.21-Bewertung kann in eine Handvoll klarer Schritte unterteilt werden, die mit Ihrem Lieferantenlebenszyklus und Ihrer Risikobereitschaft übereinstimmen.
Schritt 1 – Umfang und Kritikalität bestätigen
Wenden Sie Ihre Abgrenzungskriterien an, um zu entscheiden, ob der Lieferant in den Anwendungsbereich von A.5.21 fällt, und bewerten Sie dann die Kritikalität anhand der von ihm betroffenen Dienste und Daten.
Schritt 2 – Bedrohungen und Fehlermodi identifizieren
Nennen Sie plausible Wege, wie Vertraulichkeit, Integrität, Verfügbarkeit oder Compliance beeinträchtigt werden könnten, wie z. B. Ausfälle, Datenlecks, Missbrauch von Berechtigungen, Betrug oder Täuschung.
Schritt 3 – Risiko und bestehende Kontrollmaßnahmen bewerten
Bewerten Sie die Eintrittswahrscheinlichkeit und die Auswirkungen anhand der Standard-Skalen Ihrer Organisation und ordnen Sie die aktuellen Kontrollmechanismen wie Zertifizierungen, technische Sicherheitsvorkehrungen und interne Überwachung zu.
Schritt 4 – Behandlungen und Besitzer auswählen
Wenn das Restrisiko zu hoch ist, sollten Behandlungsmaßnahmen wie stärkere Integrationsmuster, strengere Vertragsbedingungen, verbesserte Überwachung oder Lieferantenwechsel definiert und anschließend Verantwortliche und Überprüfungstermine festgelegt werden.
Sobald diese Schritte dokumentiert und mit bestimmten Anbietern verknüpft sind, können Sie nachweisen, dass Entscheidungen über Engines, Cloud-Plattformen oder Zahlungsanbieter auf einer einheitlichen Methode und nicht auf informellen Eindrücken beruhen.
Wie gestaltet man Beurteilungen leicht verständlich, aber dennoch glaubwürdig?
Sie gestalten die Bewertungen schlank und dennoch glaubwürdig, indem Sie Lieferanten in verschiedene Kategorien einteilen und den Umfang der Bewertung entsprechend anpassen. Dabei verwenden Sie Vorlagen und Skalen wieder, um in ähnlichen Situationen vergleichbare Ergebnisse zu erzielen. Lieferanten mit hohem Risiko rechtfertigen möglicherweise detaillierte Fragebögen, die Prüfung unabhängiger Prüfberichte und gemeinsame Testpläne, während für Tools mit niedrigem Risiko unter Umständen eine kurze Checkliste und eine schnelle Bestätigung ausreichen, dass sie keine sensiblen Daten verarbeiten.
Um Ihre Glaubwürdigkeit zu wahren, sollten Sie Folgendes tun:
- Verwenden Sie teamübergreifend standardisierte Bewertungsvorlagen und Bewertungsmodelle.
- Stellen Sie sicher, dass die Ergebnisse direkt in Verträge, Einarbeitungsaufgaben, Überwachungspläne und Notfallpläne einfließen.
- Hochrisikobewertungen sollten regelmäßig überprüft werden, nicht nur bei Vertragsverlängerungen.
Eine Plattform wie ISMS.online kann diese Bewertungen zentralisieren, sie mit Kontrollen und Lieferanten verknüpfen und aufzeigen, wo Überprüfungen überfällig sind. Dadurch wird es einfacher, den Prozess langfristig aufrechtzuerhalten, selbst wenn Teams durch Release-Zyklen, Live-Events oder neue Plattformanforderungen unter Druck stehen.
Verwalten Sie Ihre gesamte Compliance an einem Ort
ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.
Wie setzt man A.5.21 in konkrete Verträge, SLAs und operative Kontrollen um?
Sie setzen A.5.21 in konkrete Verträge, Service-Levels und operative Kontrollen um, indem Sie Ihre risikobasierten Erwartungen in die rechtliche und technische Struktur jeder Geschäftsbeziehung einbetten. Die Norm erwartet von Ihnen nicht nur, dass Sie die Risiken verstehen, sondern auch, dass Sie entsprechend handeln – und zwar so, dass Lieferanten dies nachvollziehen, akzeptieren und daran gemessen werden können. So können Sie im Rahmen von ISO-27001-Audits und Kundenprüfungen klare Nachweise über diese Erwartungen erbringen.
Dies umfasst typischerweise die Entwicklung standardisierter Sicherheitspläne für verschiedene Lieferantenkategorien, die Festlegung von Fristen für die Meldung von Vorfällen, die Spezifizierung von Prüf- und Melderechten sowie die Beschreibung minimaler technischer Sicherheitsvorkehrungen. Darüber hinaus beinhaltet es die Vereinbarung, wie Daten verarbeitet werden, wo sie gespeichert werden, wie lange sie aufbewahrt werden und wie sie nach Beendigung der Geschäftsbeziehung zurückgegeben oder gelöscht werden. Die Beispiele in diesem Abschnitt dienen der Veranschaulichung; Sie sollten sich bei der Ausarbeitung oder Verhandlung konkreter Vertragsklauseln stets rechtlich beraten lassen.
Worauf sollten Sie bei Verträgen mit Spieleanbietern achten?
In Verträgen mit Spieleanbietern sollten Sie auf klare Formulierungen zu Sicherheitsverantwortlichkeiten, Servicekontinuität, Vorfallsmanagement und Datenverwaltung achten, die auf die Risikostufe des Anbieters abgestimmt sind. Je mehr ein Anbieter auf Spielerdaten, Spielguthaben oder Einnahmen zugreift, desto expliziter und anspruchsvoller sollten die Klauseln sein.
Bei kritischen Anbietern wie Engines, Anti-Cheat-Systemen, Cloud-Plattformen und Zahlungsportalen erwarten Sie möglicherweise die Einhaltung anerkannter Sicherheitszertifizierungen, die Benachrichtigung über relevante Vorfälle innerhalb bestimmter Fristen, die Beteiligung an gemeinsamen Untersuchungen und die Unterstützung angemessener Sicherheitsmaßnahmen. Sie fordern möglicherweise auch Beschränkungen für den Einsatz von Subunternehmern, klare Regeln für Telemetrie- und Spielerverhaltensdaten sowie robuste Regelungen für die Datenrückgabe oder -löschung nach Vertragsende.
Bei Lieferanten mit geringerem Risiko können Sie sich stärker auf Standardbedingungen und branchenübliche Sicherheitsvorkehrungen stützen, sofern diese Ihren Richtlinien und Ihrer Risikobereitschaft entsprechen. Wichtig ist, dass Ihre Verträge die Ergebnisse Ihrer Risikobewertungen gemäß A.5.21 widerspiegeln, sodass Sie einen klaren Zusammenhang von der Risikoidentifizierung bis zur vertraglichen Kontrolle nachweisen können.
Wie hängen diese Verpflichtungen mit den Nachweisen gemäß ISO 27001 zusammen?
Diese Verpflichtungen knüpfen an die Nachweise nach ISO 27001 an, indem sie Ihnen konkrete Belege liefern, die Sie Auditoren, Plattformen und Unternehmenskunden vorlegen können. Ihr A.5.21-Prozess lässt sich leichter nachweisen, wenn Sie auf spezifische Klauseln, vereinbarte Service-Levels und Aufzeichnungen von Vorfallsberichten oder Sicherheitsüberprüfungen verweisen können, die Hochrisikolieferanten in Ihrem Portfolio betreffen.
Zu den für die Prüfung geeigneten Nachweisen gehören häufig:
- Standardisierte Vertragsvorlagen und Sicherheitspläne für wichtige Lieferantenkategorien.
- Auszüge aus unterzeichneten Verträgen mit kritischen Lieferanten, die Sicherheits- und Vorfallsmeldeklauseln enthalten.
- Änderungsprotokolle, die anzeigen, wann sicherheitsrelevante Begriffe aktualisiert oder überprüft wurden.
- Aufzeichnungen von regelmäßigen Überprüfungen, Serviceberichten oder gemeinsamen Übungen zu Vorfällen.
Wenn diese Dokumente mit Ihren Risikobewertungen und Ihrem Lieferantenverzeichnis verknüpft werden, ergibt sich ein klares Bild: Sie haben ein Risiko erkannt, Erwartungen formuliert, Zusicherungen erhalten und gegebenenfalls Anpassungen vorgenommen. Eine ISMS-zentrierte Plattform wie ISMS.online unterstützt Sie dabei, indem sie diese Dokumente zusammen mit den relevanten Kontrollen und Risiken speichert und übersichtliche Dashboards bereitstellt, um Fragen wie „Welche Hochrisikolieferanten haben keine vereinbarte Klausel zur Meldung von Vorfällen?“ oder „Welche Überprüfungen sind überfällig?“ zu beantworten, ohne dass Sie in verstreuten Ordnern suchen müssen.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online unterstützt Sie dabei, ISO 27001 A.5.21 von einer lästigen Anforderung in eine praktische, alltägliche Methode zur Steuerung der Risiken in Ihrer IT-Lieferkette für Ihre Gaming-Infrastruktur zu verwandeln. Durch die zentrale Verwaltung von Lieferantenbeständen, Risikobewertungen, Verträgen, Kontrollen und Überwachung erhalten Sie eine klare, faktenbasierte Darstellung der Engines, SDKs, Cloud-Plattformen und Zahlungsdienste, die Ihre Angriffsfläche bestimmen.
Wenn Sie sich auf die ISO 27001:2022-Zertifizierung vorbereiten, Ihr bestehendes ISMS auf ein wachsendes Lieferantennetzwerk ausweiten oder komplexere Fragen von Plattformen und Unternehmenskunden beantworten müssen, kann eine kurze Demonstration den Weg deutlich ebnen. Sie sehen, wie Lieferantenklassifizierung, -bewertungen, -genehmigungen und Klauselbibliotheken in der Praxis funktionieren und wie sie mit Ihrer Systemarchitektur und Ihrem zentralen Risikoregister verknüpft sind, ohne Release-Pläne oder den laufenden Betrieb zu beeinträchtigen.
Was erwartet Sie in einer Demo?
In einer Demo sehen Sie, wie Lieferanten-Governance, Risikobewertung und die Kontrollen gemäß Anhang A in einem einzigen, spielbasierten ISMS zusammenwirken. Der Fokus liegt auf praktischen Arbeitsabläufen statt abstrakter Funktionen, damit Sie sich vorstellen können, wie Ihre Teams diese in realen Projekten und Veranstaltungen einsetzen würden.
In einer typischen Schulungssitzung werden die Einrichtung eines Lieferantenverzeichnisses, die Kategorisierung von Lieferanten nach ihrer Auswirkung, die Durchführung einer A.5.21-konformen Bewertung und die Verknüpfung der Ergebnisse mit Verträgen, Kontrollen und Audits erläutert. Sie erfahren außerdem, wie Bewertungen, Vorfallberichte und Managementberichte erfasst werden, sodass Sie Fragen von Auditoren, Plattformen und Unternehmenskunden beantworten können, ohne in verschiedenen Tools oder Tabellenkalkulationen suchen zu müssen.
Wie sollten sich verschiedene Teams auf eine Pilotphase vorbereiten?
Den größten Nutzen aus einem Pilotprojekt zieht man, wenn jede Schlüsselperson ein konkretes Problem mitbringt, das sie lösen möchte, anstatt nur eine theoretische Wunschliste. Das könnte beispielsweise ein blockiertes ISO-27001-Projekt, eine fehlerhafte Lieferanten-Tabelle oder eine Vielzahl neuer Plattformfragebögen sein, die Sie souverän beantworten müssen.
Unternehmen, die ISO 27001 erstmals schnellstmöglich einführen möchten, können sich vorbereiten, indem sie einige wenige kritische Lieferanten und die entsprechenden Verträge oder Plattformbeziehungen, die von der Zertifizierung abhängen, auflisten. Teams, die ein bestehendes ISMS stärken, können aktuelle Risikoregister, SoA-Einträge und Vertragsvorlagen einbringen und anschließend prüfen, wie gut diese in ein einheitliches, die Lieferkette berücksichtigendes Modell integriert werden können. In beiden Fällen hilft es, mit einer kleinen, repräsentativen Auswahl an Cloud-, Zahlungs- und Anti-Cheat-Anbietern zu beginnen, den Ansatz schnell zu validieren und Dokumente zu generieren, die in zukünftigen Audits, Sicherheitsfragebögen und Plattformüberprüfungen wiederverwendet werden können.
Anschließend können Sie Ihre Gaming-Infrastruktur auf weitere Bereiche ausweiten und sich darauf verlassen, dass Ihr Ansatz zur Sicherheit Ihrer IT-Lieferkette angemessen, nachvollziehbar und mit ISO 27001 A.5.21 sowie den zugehörigen Kontrollen in Anhang A konform ist. Wenn Sie bereit sind, sich von fehleranfälligen Tabellenkalkulationen und Ad-hoc-Prozessen zu verabschieden, ist die Buchung einer Demo bei ISMS.online der nächste logische Schritt hin zu einem Lieferkettensicherheitsmodell, mit dem Ihre Entwicklungsteams, Ihre Führungsebene und Ihre Auditoren gleichermaßen zufrieden sein werden.
KontaktHäufig gestellte Fragen (FAQ)
Wie verändert ISO 27001 A.5.21 konkret die alltäglichen Entscheidungen eines Spieleanbieters?
ISO 27001 A.5.21 verändert Ihre täglichen Entscheidungen, indem sie Sie dazu zwingt, kritische IT-Lieferanten als Teil Ihrer Live-Spielumgebung und nicht als externe Blackboxes zu behandeln. Engines, SDKs, Cloud-Lösungen, Zahlungsabwicklung, Anti-Cheat-Systeme, CDNs, Identitätsmanagement, Analysetools und Build-Pipelines werden von „Beschaffungsoptionen“ zu „sicherheitsrelevanten Assets“ innerhalb Ihres ISMS.
In der Praxis bedeutet das, dass Sie aufhören, Lieferanten ausschließlich nach Funktionen und Preis auszuwählen, und stattdessen jedes Mal drei gezielte Fragen stellen:
Welchen tatsächlichen Einfluss hat dieser ICT-Anbieter auf die Spieler und den Umsatz?
Sie beurteilen, ob der Dienst Folgendes leisten kann:
- Verhindern, dass Spieler sich verbinden oder in Verbindung bleiben.
- Spielfortschritt oder Gegenstände beschädigen oder verlieren.
- Die Integrität des Wettbewerbs oder den Betrugsschutz beeinträchtigen.
- Verletzung von Plattform-, Glücksspiel- oder Datenschutzverpflichtungen.
- Zahlungen und Rückerstattungen blockieren, verzögern oder falsch weiterleiten.
Wenn einer dieser Punkte zutrifft, fällt der Lieferant unter A.5.21 und muss in Ihrem ISMS, Risikoregister und der Anwendbarkeitserklärung sichtbar sein.
Wie lässt sich nachweisen, dass IKT-Risiken aktiv gemanagt werden?
Sie gehen von spontanen Fragebögen und E-Mail-Korrespondenzen zu einem wiederholbaren Muster über:
- Eine übersichtliche Lieferantenhistorie mit Kategorisierung und Eigentumsverhältnissen.
- Eine kurze, strukturierte Risikobewertung, die mit Ihrem zentralen Risikoregister verknüpft ist.
- Kartierte Kontrollen gemäß Anhang A (einschließlich A.5.21, aber auch A.5.19, A.5.23, A.8.8 und A.8.20–A.8.22, soweit relevant).
- Behandlungsentscheidungen, Maßnahmen und Überprüfungstermine, die tatsächlich stattfinden.
Wenn eine Cloud-Region ausfällt oder ein SDK-Update nicht ordnungsgemäß funktioniert, können Sie genau zeigen, was Sie angenommen haben, wie Sie das Problem behoben haben und wie Sie Verbesserungen vornehmen, anstatt Entscheidungen aus Chatprotokollen zu rekonstruieren.
Wie wirkt sich das auf ein ISMS oder ein in Annex L integriertes System aus?
In einem gemäß Annex L ausgerichteten integrierten Managementsystem bildet A.5.21 die Grundlage für einen gemeinsamen Lieferanten-Governance-Prozess in den Bereichen Sicherheit, Datenschutz, Kontinuität und – in Kürze – KI-Governance. Anstelle von vier separaten Lieferantenlisten und Risikoworkflows wird ein einziger, auf A.5.21 basierender Workflow verwendet, der die Verpflichtungen gemäß ISO 27001, ISO 27701, ISO 22301 und NIS 2/DORA erfüllt.
ISMS.online macht dies konkret, indem es Lieferanteneinträge, Risikobewertungen, Kontrollzuordnungen und Vorfallverknüpfungen an einem zentralen Ort zusammenführt. So erkennen Auditoren, Lizenzgeber und Plattformpartner, dass das Risiko in der ITK-Lieferkette integraler Bestandteil des täglichen Geschäftsbetriebs ist und nicht erst bei der Zertifikatserneuerung Beachtung findet.
Wenn Sie Ihre eigene Position auf Plausibilität prüfen möchten, wählen Sie eine Engine oder einen Anti-Cheat-Anbieter aus und prüfen Sie, ob Sie eine direkte Linie von Geschäftsauswirkungen → Risikobewertung → Kontrollen → Vertrag → Überprüfungsnotizen nachzeichnen können; wenn nicht, haben Sie einen klaren Ausgangspunkt für die Verschärfung von A.5.21.
Wie sollte ein Spielestudio entscheiden, welche ICT-Anbieter tatsächlich in den Anwendungsbereich von A.5.21 fallen?
Den Umfang von A.5.21 legen Sie fest, indem Sie mit den für die Spieler relevanten Spielabläufen beginnen und sich dann zu den Anbietern vorarbeiten, die diese Momente maßgeblich beeinflussen können. Die Frage lautet nicht: „Wer stellt uns eine Rechnung?“, sondern: „Wer kann das Vertrauen erheblich schädigen, wenn er versagt oder sich falsch verhält?“
Wie lassen sich Lieferanten anhand der Spielerreise abbilden?
Gehen Sie einige Betonabflüsse durch:
- Kontoerstellung, Anmeldung und Berechtigungen.
- Matchmaking und Sitzungsmanagement.
- Fortschritt und Inventar.
- Wettkampf- und Ranglistenspiele.
- Zahlungen, Rückerstattungen und Rückbuchungen.
- Live-Events und In-Game-Ökonomien.
- Kundendienst und Sicherheitsberichterstattung.
Listen Sie für jeden Datenfluss alle externen Produkte oder Dienstleistungen auf, die:
- Steuert oder speichert den Spielzustand oder den Spielfortschritt.
- Verarbeitet oder leitet Geld oder wertvolle virtuelle Gegenstände weiter.
- Trifft Durchsetzungsentscheidungen (Betrugsbekämpfung, Betrugsprävention, Moderation).
- Verarbeitet regulierte Daten (Zahlungskarten, personenbezogene Daten, Minderjährige).
- Zugangskontrolle (Identität, Lizenzierung, Plattformkonformität).
Das sind Ihre Kandidat A.5.21 LieferantenTools, die sich vollständig außerhalb der kritischen Pfade befinden (z. B. ein risikoarmes Marketing-Plugin), können oft mit weniger strengen Prüfungen gehandhabt werden.
Wie kann ein einfaches dreistufiges Modell den Umfang unter Kontrolle halten?
Die meisten Studios erzielen gute Ergebnisse mit einem schlanken dreistufigen Modell:
Wie können Lieferanten der Stufen 1–3 in einem ISMS für die Gaming-Branche funktionieren?
Ein übersichtliches dreistufiges Modell hilft Ihnen, die Verhältnismäßigkeit aufzuzeigen, ohne für jedes SaaS-Abonnement den gleichen Aufwand betreiben zu müssen.
- Tier 1 – Spieler- und umsatzkritische IKT-Anbieter:
Alles, was den Betrieb lahmlegen, den Staat korrumpieren, die Fairness verzerren, regulierte Daten durchsickern lassen oder Plattform-/Glücksspiel-/Datenschutzverpflichtungen verletzen kann, gehört hierher.
- Tier 2 – Wichtige, aber nicht kritische Lieferanten:
Dienstleistungen, die den Betrieb, die Analyse oder die Kommunikation unterstützen, aber nicht direkt den Spielstatus oder regulierte Daten kontrollieren.
- Stufe 3 – Versorgungsunternehmen mit geringen Umweltauswirkungen:
Tools, die ohne spürbare Auswirkungen auf die Spieler und mit minimalem vertraglichem oder regulatorischem Risiko versagen können.
Anschließend wenden Sie die vollständige Disziplin gemäß A.5.21 auf Stufe 1 an (formale Risikobewertungen, strengere Verträge, engmaschigere Überwachung), weniger strenge, aber dennoch strukturierte Prüfungen auf Stufe 2 und grundlegende Onboarding-Kontrollen auf Stufe 3. In ISMS.online können Sie dies mit Feldern für Stufe, Verantwortlicher, verknüpfte Risiken und Datum der letzten Überprüfung abbilden. So können Sie auf die Frage „Warum wird dieser Anbieter anders behandelt?“ nachweisen, dass es sich um eine bewusste, dokumentierte Entscheidung handelte und nicht um eine unter Zeitdruck getroffene Vermutung.
Wie können wir Cloud-, Zahlungs- und SDK-Anbieter bewerten, ohne einen administrativen Aufwand zu verursachen?
Die Bewertung der IKT-Lieferkette bleibt überschaubar, indem ein Workflow standardisiert und für Cloud-Lösungen, Zahlungen und SDKs wiederverwendet wird, anstatt jedes Mal eine neue Tabelle zu erstellen. Das Ziel ist gleichbleibende Tiefe, minimale Reibung.
Wie sieht ein einzelnes Beurteilungsmuster aus?
Ein praktisches Vorgehen für jeden IKT-Anbieter ist:
- Prüfen Sie, ob sie im Geltungsbereich von A.5.21 liegen und weisen Sie ihnen eine Stufe zu.
- Nennen Sie 3–7 realistische Fehlermodi, die für Spieler, Regulierungsbehörden oder den Umsatz relevant sind.
- Halten Sie fest, was Sie und der Lieferant bereits in Bezug auf solche Szenarien tun.
- Zusätzliche Maßnahmen (technische, vertragliche, Überwachungsmaßnahmen) mit den Eigentümern und den jeweiligen Terminen abstimmen.
- Verknüpfen Sie alles mit Ihrem ISMS-Risikoregister und den entsprechenden Kontrollen gemäß Anhang A.
Anschließend passen Sie die Fragen und Beispiele nach Kategorien an:
- Cloud: Regionen und Verfügbarkeitszonen, Skalierung und Kapazität, Datensicherung und -wiederherstellung, Datenresidenz, Mandantenisolierung, Vorfallsmeldung.
- Zahlungen: Betrug und Rückbuchungen, PCI-DSS-Konformität, Abwicklungszeitpunkte, Streitbeilegung, plattformspezifische Regeln (z. B. App-Stores, Glücksspiel).
- SDKs: Codeintegrität, Datenerfassung, Berechtigungen, Aktualisierungsmechanismen, Rollback-Optionen, Not-Aus-Schalter, Auswirkungen von Fehlkonfigurationen.
Die Methode bleibt gleich; nur die Details ändern sich.
Was gilt als „ausreichende“ Dokumentation für Lieferanten mit hohem Einfluss?
Für Tier-1-Lieferanten bedeutet „ausreichende“ Dokumentation: kurz, aber nachvollziehbar.
- Eine veraltete Risikobewertung, die zusammenfasst, warum der Lieferant kritisch ist und welche Szenarien relevant sind.
- Links zu den entsprechenden ISMS-Risikoeinträgen und den Kontrollen in Anhang A (A.5.21 plus weitere zutreffende Einträge).
- Eine Dokumentation der Qualitätssicherungsmaßnahmen: Zertifikate, Prüfberichte, strukturierte Fragebögen, falls verwendet.
- Eine Behandlungsentscheidung und klare Maßnahmen, mit Verantwortlichen und Überprüfungsterminen.
Mit ISMS.online können Sie diese Elemente in einer einzigen Ansicht pro Lieferant zusammenfassen. So aktualisieren Sie bei Vorfällen, externen Audits oder Plattformbefragungen einen bestehenden Datensatz, anstatt Ihre Logik von Grund auf neu zu erstellen. Wenn Ihr aktueller Ansatz nicht in der Lage ist, auf Anfrage eine einseitige Zusammenfassung pro Tier-1-Lieferant zu erstellen, ist dies ein deutliches Anzeichen dafür, dass die Arbeit an A.5.21 fragmentiert und nicht als strukturierter Prozess erfolgt.
Welche Fehler in Engines, SDKs und Anti-Cheat-Systemen sollten unsere Kontrollmechanismen zuerst antizipieren?
Entscheidend sind die Fehler, die Spieler spüren und die Regulierungsbehörden interessieren: unspielbare Spielsitzungen, unfaire Ergebnisse, entgangener Spielwert oder fehlerhaft verarbeitete Daten. Die technischen Ursachen sind intern wichtig, doch die Kontrollmechanismen für A.5.21 lassen sich leichter entwickeln, wenn man von diesen sichtbaren Auswirkungen ausgeht.
Welche realistischen Ausfallszenarien gibt es für Anbieter von IT-Lösungen für die Gaming-Branche?
Denken Sie in Kategorien, die Spieler und Partner wiedererkennen würden:
- Engines und SDKs:
- Ein Update, das eine Sicherheitslücke oder eine stille Absturzschleife verursacht.
- Eine Änderung des Datenerfassungsverhaltens, die über Ihre veröffentlichte Datenschutzerklärung hinausgeht.
- Ein fehlerhafter Aktualisierungspfad, der Rollbacks oder Hotfixes langsam oder unsicher macht.
- Betrugsbekämpfung:
- Regeln, die plötzlich eine Welle legitimer Spieler ausschließen.
- Erkennungslücken, die es ermöglichen, dass koordiniertes Betrugsverhalten unbemerkt gedeihen kann.
- Telemetrielücken, die Untersuchungen verlangsamen oder zu ergebnislosen Ergebnissen führen.
- Pipelines und Tools erstellen:
- Kompromittierte Build-Infrastruktur, die es ermöglicht, manipulierte Assets oder Code in Live-Builds einzuschleusen.
- Fehlerhafte Signaturen oder Bereitstellungsfehler, die Updates auf einer Plattform oder in einer Region beeinträchtigen.
- Lizenzierung, Identität und Berechtigung:
- Authentifizierungs- oder Berechtigungsprobleme, die Spieler daran hindern, Sitzungen zu starten oder beizutreten.
- Falsch angewendete Widerrufs- oder Regionseinstellungen, die wie gezielte Sperrungen aussehen.
Jedes Szenario bietet Ihnen einen Ansatzpunkt für die Entwicklung von Kontrollmechanismen, die Governance und Engineering miteinander verbinden.
Wie lassen sich diese Szenarien in Kontrollmechanismen umwandeln, die Prüfer und Plattformpartner überzeugen?
Für jede Szenariofamilie, Paar:
- Governance: Auswahlkriterien für Lieferanten, Mindestanforderungen an sichere Entwicklung und Tests, Informationsfreiheitsklauseln, Anforderungen an die Meldung von Vorfällen, Überprüfungsfrequenz.
- Technik: Abgeschottete Integrationen und Zugriff nach dem Prinzip der minimalen Berechtigungen, Codesignierung und Integritätsprüfungen, kontrollierte Rollout- und Rollback-Mechanismen, auf die spezifischen Risiken abgestimmte Telemetrie, Sicherheitsgates in Ihrer CI/CD-Pipeline.
Anschließend ordnen Sie diese Kontrollen Ihrem ISMS zu und verknüpfen sie mit A.5.21 und anderen relevanten Kontrollen gemäß Anhang A. In ISMS.online können Sie jeden wichtigen Lieferanten mit konkreten Fehlermodi, Gegenmaßnahmen und Vorfällen verknüpfen. So können Sie einem Auditor, Lizenzgeber oder Plattformpartner deutlich einfacher erläutern, wie wir die jeweilige Engine oder den Anti-Cheat-Anbieter bewertet haben und wie wir bei Fehlfunktionen vorgehen. Diese Vorbereitung zahlt sich im Fehlerfall aus: Ihre Teams folgen einem vorab vereinbarten Handlungsplan, anstatt nachts um 3 Uhr über Grundlagen zu diskutieren.
Wie zeigen Verträge und Service-Level-Agreements (SLAs), dass die Risiken in der IKT-Lieferkette kontrolliert und nicht nur zur Kenntnis genommen werden?
Verträge, Leistungsbeschreibungen und Service-Level-Agreements (SLAs) sind die Bereiche, in denen Ihre Risikobewertung gemäß A.5.21 zu verbindlichen Verpflichtungen wird. Sie wandeln aus „Wir machen uns darüber Sorgen“ die Aussage „Unser Lieferant hat zugesagt, uns bei der Bewältigung dieses Problems zu unterstützen“.
Was sollten Verträge für Tier-1-IKT-Lieferanten üblicherweise umfassen?
Bei Diensten, die auf kritischen Pfaden laufen – Live-Infrastruktur, Zahlungssysteme, Engines, Betrugsschutz, Identitätsmanagement – erwartet man typischerweise Folgendes:
- Klare Sicherheits- und Datenschutzerwartungen, die mit Ihren eigenen Richtlinien und Rahmenbedingungen übereinstimmen.
- Definierte Verfügbarkeits-, RTO/RPO- und Supportziele, die widerspiegeln, wie kritisch der Dienst in Ihrem Risikoregister ist.
- Fristen für die Meldung von Vorfällen, Eskalationswege und Erwartungen an den Informationsaustausch.
- Datenverarbeitungs-, Unterauftragnehmer- und grenzüberschreitende Übermittlungsregeln, die alle relevanten Rechtsordnungen respektieren.
- Proportionale Rechte auf Prüfungsinformationen (Zertifikate, Testzusammenfassungen, unabhängige Prüfberichte).
- Spezielle Klauseln für Dienstleistungen im Zusammenhang mit Fairness (z. B. Anti-Cheat-Telemetrie, Unterstützung bei Ermittlungen, Kündigungsrechte bei Gefährdung der Integrität).
Auch Lieferanten mit geringeren Auswirkungen müssen darauf achten, Ihre Sicherheitslage nicht zu untergraben, aber die Sprache kann weniger formell sein und Ihre Kontrollen sollten sich stärker auf das Onboarding und die grundlegende Überwachung konzentrieren.
Wie können Sie schnell überprüfen, ob Ihre vertragliche Haltung Ihrer Risikohaltung entspricht?
Ein einfaches internes Überprüfungsmuster sieht wie folgt aus:
- Wählen Sie einige Tier-1-Lieferanten aus: von Ihrem ISMS.
- Vergleichen Sie Ihr Risikoregister mit deren Verträgen: Entsprechen die Sicherheits-, Verfügbarkeits- und Reaktionsklauseln Ihrer Einschätzung, wie „kritisch“ sie sind?
- Datenschutz- und Plattformverpflichtungen prüfen: Sind deren Datenschutz- und Unterauftragsverarbeitungsbedingungen mit Ihren Verpflichtungen gegenüber Spielern, Plattformen und Regulierungsbehörden vereinbar?
- Schauen Sie sich Rezensionen und Verlängerungen an: Werden Leistung und Vorfälle explizit besprochen, und sind diese Diskussionen in Ihrem ISMS sichtbar?
Sind die Antworten unklar, besteht eine Diskrepanz zwischen Risiko und Vertrag. ISMS.online hilft Ihnen, diese Lücke zu schließen, indem es Lieferantendatensätze, Risiken, Bewertungen, Überprüfungen und Dokumente verknüpft. So können Sie eine lückenlose Kette von „Wir haben dieses Risiko identifiziert“ über „Wir haben unsere Beschaffungs- und Betriebsweise der Dienstleistung angepasst“ bis hin zu „Wir prüfen, ob dies weiterhin akzeptabel ist“ nachweisen. Externe Prüfer achten auf diese Kette, um zu beurteilen, ob A.5.21 tatsächlich umgesetzt oder nur in den Richtlinien beschrieben ist.
Wie kann eine ISMS-Plattform die Anwendung von A.5.21 für Engineering-, Sicherheits- und Live-Ops-Teams ermöglichen?
Eine ISMS-Plattform macht A.5.21 umsetzbar, indem sie Lieferkettenrisiken in gemeinsame Abläufe überführt, die sich nahtlos in die bestehenden Entwicklungs- und Betriebsprozesse Ihrer Teams integrieren lassen. Anstelle eines separaten Compliance-Prozesses erhalten Sie Leitplanken, die an den Entscheidungspunkten greifen.
Wie sieht das in der Praxis für verschiedene Teams aus?
- Produzenten und Produktmanager: kann prüfen, ob ein Lieferant bereits im Bestand vorhanden ist und welcher Stufe er angehört, bevor eine neue Abhängigkeit eingegangen wird.
- Ingenieure und Live-Ops: kann für A.5.21-Bewertungen eine bekannte Checkliste verwenden, anstatt aus ihnen abzuleiten, welche „Sicherheitsbedürfnisse“ bestehen.
- Sicherheits- und Risikoteams: kann einen einheitlichen Lieferantenrisiko-Workflow für Cloud, Zahlungen, SDKs und Betriebstools aufrechterhalten, mit klaren Auslösern für eine eingehendere Due-Diligence-Prüfung.
- Rechts- und Beschaffungswesen: Sie haben Zugriff auf Klauselmuster und frühere Entscheidungen, sodass sie nicht jedes Mal von Grund auf neu verhandeln müssen.
- Leadership: Sie können erkennen, welche Lieferanten wichtige Dienstleistungen oder Regionen unterstützen, welche laufende Verfahren haben und wie Lieferantenprobleme zu Vorfällen oder Beinaheunfällen beigetragen haben.
Wenn eine externe Prüfung, eine Plattformüberprüfung oder ein schwerwiegender Vorfall eintritt, dienen diese Aufzeichnungen als Grundlage für gezielte Beweismittelsammlungen und Verbesserungen nach dem Vorfall anstatt für zeitaufwändige archäologische Untersuchungen.
Wie hilft Ihnen ISMS.online dabei, A.5.21 in ein integriertes System im Stil von Anhang L einzubetten?
Da ISMS.online auf den Grundsätzen von Anhang L basiert, kann die Lieferantensteuerung wiederverwendet werden für:
- Sicherheit: ISO 27001 und verwandte Rahmenwerke.
- Datenschutz: ISO 27701, DSGVO und andere regionale Gesetze.
- Kontinuität: ISO 22301 und Resilienzverpflichtungen (einschließlich der Konzepte NIS 2 und DORA, sofern relevant).
- Die aufkommende Governance von KI: da KI-gesteuerte Dienste und Modelle reguliert werden.
Lieferanteneinträge, Risikobewertungen, Kontrollen, Vorfälle, Verträge und Prüfvermerke befinden sich an einem zentralen Ort und sind mit Ihrem zentralen Risikoregister und der Anwendbarkeitserklärung verknüpft. Das bedeutet, dass Sie die Überlegungen nur einmal anstellen und sie wiederholt anwenden können, anstatt in jedem Bereich separate, inkonsistente Prozesse durchzuführen.
Für Ihr Unternehmen bedeutet dies, dass das Risiko in der IT-Lieferkette wöchentlich in die Entwicklung, den Vertrieb und den Betrieb Ihrer Spiele einfließt. Um zu überprüfen, ob dies bereits heute der Fall ist, stellen Sie eine einfache Frage: „Kann ein leitender Ingenieur oder Produzent erklären, welche Lieferanten zur ersten Kategorie gehören und wie sie überprüft werden?“ Lautet die Antwort „Nein“, ist die vollständige Integration von A.5.21 in eine ISMS-Plattform wie ISMS.online einer der schnellsten Wege, die Arbeit Ihrer Teams mit den Anforderungen Ihrer Zertifikate in Einklang zu bringen.
