Checkliste für Tests, Sicherheit, Zertifizierung und SLA von Lotterieplattformen
Eine Checkliste für Sicherheit und Verfügbarkeit einer Lotterieplattform sollte jede Anforderung mit einem Test, einem rechenschaftspflichtigen Verantwortlichen und Nachweisen für die künftig betriebene Version verbinden. Beginnen Sie mit dem vorgesehenen Produkt, geltenden Anforderungen, Zahlungsvereinbarungen und Vertrag. Beauftragen Sie unabhängige Arbeiten früh genug, um Befunde zu beheben und erneut zu testen. Verhandeln Sie anschließend messbare Servicelevels […]
Eine Checkliste für Sicherheit und Verfügbarkeit einer Lotterieplattform sollte jede Anforderung mit einem Test, einem rechenschaftspflichtigen Verantwortlichen und Nachweisen für die künftig betriebene Version verbinden. Beginnen Sie mit dem vorgesehenen Produkt, geltenden Anforderungen, Zahlungsvereinbarungen und Vertrag. Beauftragen Sie unabhängige Arbeiten früh genug, um Befunde zu beheben und erneut zu testen. Verhandeln Sie anschließend messbare Servicelevels für den gesamten Kundenablauf, nicht nur für einen Server, der auf einen Zustandscheck antwortet.
RNG-Berichte, Penetrationstests, Zertifikate und Verfügbarkeitszusagen beantworten unterschiedliche Fragen. Keines ersetzt die anderen. Nutzen Sie die Anbieterbewertungs-Checkliste zum Vergleich von Angeboten und laden Sie das WhiteLotto Operator Decision Pack (XLSX) herunter, um Anforderungen, Nachweislücken und Entscheidungen festzuhalten.
Trennen Sie Tests, Zertifizierung und betriebliche Absicherung
Erstellen Sie eine Anforderungsmatrix: Pflicht und Quelle, Komponente, Version, Umgebung, erforderlicher Standard, zulässiger Prüfer, Voraussetzung, Ergebnis und Abnahmeverantwortlicher. Ermitteln Sie, was Anbieternachweise abdecken und was für Ihre Bereitstellung spezifisch bleibt. Interne Qualitätssicherung unterstützt diese Arbeit, ersetzt jedoch keine erforderliche unabhängige Prüfung.
| Umfang | Zu prüfende Fragen | Anzufordernde Nachweise |
|---|---|---|
| Spiel und RNG | Wo Zufälligkeit eingesetzt wird: Generator, Zuordnung, Spielregeln und Ergebnisverarbeitung. | Bericht mit geprüften Komponenten, Versionen, Methoden und Ausschlüssen. |
| Plattform und Integrationen | Losannahme, Verkaufsschluss, doppelte Anfragen, Abrechnung, Ergebnisübernahme und Abstimmung. | Systemtestergebnisse für die konfigurierten Integrationen und Fehlerfälle. |
| Cybersicherheit | Authentifizierung, privilegierter Zugriff, APIs, Konfiguration, Schwachstellen und Vorfallbearbeitung. | Abgegrenzte Prüfung, Befundregister und Nachweise unabhängiger Wiederholungsprüfungen. |
| Zahlungssicherheit | Kartendatenflüsse, diese Flüsse beeinflussende Systeme und geteilte Zuständigkeiten. | Bestätigter PCI-Umfang und einschlägige Validierungsnachweise. |
| Servicebetrieb | Verfügbarkeit, Wiederherstellung, Supporteskalation und Transaktionsintegrität. | SLA-Definitionen, Überwachungsnachweise und Ergebnisse von Wiederherstellungsübungen. |
Der GLI-Standardkatalog unterscheidet Standards für Spiel- und Sicherheitsprüfungen. Ein Katalogeintrag beweist nicht, dass ein bestimmtes Produkt zertifiziert wurde. Bestätigen Sie den genauen Standard und die für Ihre Anforderung akzeptierten Nachweise; setzen Sie nicht voraus, dass ein Zertifikat jede Konfiguration oder Nutzung abdeckt.
Wählen Sie unabhängige Prüfer vor dem Veröffentlichungsfenster
Prüfen Sie einschlägige Kompetenz, erforderliche Akkreditierung oder Anerkennung, Unabhängigkeit, Konflikte, Unterauftragnehmer und Verfügbarkeit. Die Vermittlung eines Labors begründet weder dessen Zulässigkeit noch die garantierte Annahme seines Berichts. Vereinbaren Sie Umfang, Methoden, Ausschlüsse, Eingabeartefakte, Vertraulichkeit, zulässige Nutzung der Ergebnisse, Wiederholungsprüfungsgebühren und Ergebnisse schriftlich.
Für Zahlungen beschreibt PCI SSC PCI DSS als Schutz von Zahlungskontodaten, einschließlich Organisationen, die die Karteninhaberdatenumgebung beeinflussen könnten. Setzen Sie ausgelagerten Checkout nicht mit fehlenden Verantwortlichkeiten gleich. Erfassen Sie die tatsächlichen Datenflüsse und bestätigen Sie Ihren einschlägigen Umfang und Validierungsweg mit der zuständigen Zahlungsgegenpartei und einem qualifizierten Prüfer.
Verknüpfen Sie Testergebnisse mit der bereitgestellten Version
Die Entwicklung sollte ein Versionsmanifest mit Build-Kennungen oder Hashes, Abhängigkeiten, Konfiguration, Infrastruktur, Spielen und Integrationen führen. Dokumentieren Sie die Testumgebung und erklären Sie Unterschiede zur Produktion. Gewähren Sie Prüfern zeitlich begrenzten, protokollierten Zugriff; minimieren Sie Daten und nutzen Sie genehmigte sichere Übertragungskanäle.
Das Nachweisregister muss jeden Befund mit betroffener Version, Schweregrad, Verantwortlichem, Korrekturmaßnahme, vorübergehender Kontrolle, Wiederholungsprüfung und Abschlussentscheidung verknüpfen. Bewahren Sie Berichte und nachteilige Befunde sicher auf, auch in Managementzusammenfassungen. Sicherheit verantwortet die technische Behebung; Compliance prüft die Anforderungsabdeckung; Versionsmanagement prüft die Übereinstimmung von Bereitstellung und Nachweisen. Benennen Sie, wer Restrisiken akzeptieren darf, ohne externe Anforderungen zu übergehen.
Ein kritischer Befund kurz vor dem Start
Zeigt ein Penetrationstest Zugriff auf privilegierte Konten, isolieren Sie die betroffene Umgebung, bewerten Sie die Exposition und beziehen Sie Sicherheits-, Entwicklungs-, Compliance- und Rechtsverantwortliche ein. Beheben Sie die Ursache und untersuchen Sie verwandte Komponenten. Holen Sie unabhängige Wiederholungsprüfungsnachweise ein; senken Sie den Schweregrad nicht zum Schutz des Termins. Verschieben oder begrenzen Sie den Start, wenn die befugten Abnahmebedingungen nicht erfüllt werden können.
Planen Sie Zeit für Umfangsfragen, Behebung und Wiederholungsprüfungen ein, nicht nur für die erste Prüfung. Ein späterer Wechsel der Authentifizierungsbibliothek kann Sitzungen, Berechtigungen und Zahlungs-Callbacks beeinflussen: Bewerten Sie die Auswirkungen und fragen Sie die zuständigen Spezialisten, ob gezielte oder umfassendere Wiederholungsprüfungen erforderlich sind.
Machen Sie Verfügbarkeitsaussagen zu einem betrieblichen SLA
Ein SLA ist eine Vertragsdefinition, keine Zertifizierung. Legen Sie abgedeckte Abläufe, Messzeiträume, Überwachungsstandorte, Berechnung und Ausschlüsse fest. Verfügbarkeit wird häufig als anrechenbare Zeit abzüglich gezählter Ausfallzeit, geteilt durch anrechenbare Zeit, berechnet. In einem beispielhaften Zeitraum von 30 Tagen erlauben 99,9 % eine gezählte Ausfallzeit von 43,2 Minuten. Dieser Prozentsatz sagt wenig über einen Ausfall unmittelbar vor dem Losverkaufsschluss aus.
| Thema | Fragen an den Anbieter |
|---|---|
| Abgedeckter Service | Umfasst Verfügbarkeit Anmeldung, Losbestätigung, APIs und Verwaltungszugriff? Wie werden Teilausfälle gezählt? |
| Abhängigkeiten und Ausschlüsse | Wie werden Ausfälle bei Zahlungen oder Ziehungsdaten eingeordnet? Welche Ankündigungsfristen und Grenzen gelten für Wartung? |
| Vorfallreaktion | Welcher Schweregrad löst eine Rund-um-die-Uhr-Eskalation aus? Sind Empfangsbestätigung, Aktualisierungen und Wiederherstellung getrennte Ziele? |
| Wiederherstellung | Welche RTO und RPO werden für jeden kritischen Service vorgeschlagen? Welche Übung belegt sie? |
| Nachweise und Abhilfe | Wer erhält Messungen und Vorfallberichte? Wie werden Streitfälle, Gutschriften und wiederholte Verstöße behandelt? |
Recovery Time Objective (RTO) ist die angestrebte Zeit zur Wiederherstellung des Dienstes; Recovery Point Objective (RPO) ist die angestrebte, zeitlich gemessene Grenze für Datenverlust. Ein Sicherungszeitplan allein beweist keines von beiden. Fordern Sie beobachtete Wiederherstellungszeiten, wiederhergestellte Datenstände, Voraussetzungen und Ausnahmen an. Die Zahlen hier sind Beschaffungsbeispiele, keine WhiteLotto-Servicezusagen. Beziehen Sie Test- und Wiederherstellungszuständigkeiten in Ihren Softwarepreisvergleich ein.
Testen Sie Fehler und Wiederherstellung, nicht nur normalen Verkehr
Die Losbestätigung geht verloren
Ein Kunde sendet eine Bestellung, aber die Antwort läuft in eine Zeitüberschreitung. Prüfen Sie, ob ein erneuter Versuch dieselbe Anfragekennung nutzt, den Status prüft und ein doppeltes Los oder eine doppelte Belastung verhindert. Dokumentieren Sie die angenommene Transaktion, die Verkaufsschlussentscheidung und das Abstimmungsergebnis. Eine reagierende Startseite darf einen defekten Kaufablauf nicht verdecken.
Die Datenbankwiederherstellung gelingt, aber Datensätze widersprechen sich
Stellen Sie in einer befugten isolierten Übung Datensätze wieder her und vergleichen Sie Bestellungen, Zahlungsreferenzen, Salden und Loszustände. Prüfen Sie fehlende oder doppelte Ereignisse, erneute Integrationsverarbeitung, Auditkontinuität und wartende Aufgaben. Prüfen Sie die Verfügbarkeit von Schlüsseln und Abhängigkeiten, ohne Geheimnisse offenzulegen. Vereinbaren Sie, wer Abweichungen vor der Wiederaufnahme des Verkaufs abstimmt; erzeugen Sie keine echten Kundentransaktionen für die Übung.
Stellen Sie das Nachweispaket für den Start zusammen
- Anforderungsmatrix und Bestätigung der Prüferzulässigkeit.
- Versionierte Architektur, Datenflüsse, Versionsmanifest und Dokumentation der Produktionsgleichwertigkeit.
- Testberichte, Zertifikate, Umfangsausschlüsse, Gültigkeitsbedingungen und Nutzungsbefugnisse für Ergebnisse.
- Befunde, Behebung, unabhängige Wiederholungsprüfungen und befugte Restrisikoentscheidungen.
- SLA-Definitionen, Eskalationskontakte, Wiederherstellungsergebnisse und Abstimmungsverfahren.
- Versionsabnahmeverantwortliche, laufende Kontrollen und durch Änderungen ausgelöste Neubewertungsregeln.
Verfolgen Sie nach dem Start Ablaufdaten, Patches, Vorfälle und Änderungen an Bibliotheken, RNG, Zahlungen oder Infrastruktur. Bewerten Sie, ob die Nachweise die Version weiterhin abdecken, auch ohne gedrucktes Ablaufdatum. Das NIST Cybersecurity Framework unterstützt laufendes Cybersicherheits-Risikomanagement; ein Zertifikat ist keine kontinuierliche Überwachung. Machen Sie die Zuständigkeitsverteilung beim Vergleich von White-Label- und schlüsselfertiger Lieferung ausdrücklich klar.
Häufige Fragen
Beweist ein RNG-Bericht die Plattformsicherheit?
Nein. Er behandelt den angegebenen Zufälligkeitsumfang, nicht jedes Konto, jede Integration oder betriebliche Kontrolle. Er sagt keine künftigen Ziehungen voraus.
Kann eine Verfügbarkeitszusage Wiederherstellungstests ersetzen?
Nein. Fordern Sie geprüfte Wiederherstellungs- und Abstimmungsnachweise zusammen mit definierten RTO- und RPO-Zielen an.
Bestätigt diese Checkliste WhiteLotto-Zertifizierungen?
Nein. Fordern Sie aktuelle Nachweise für den vorgeschlagenen Umfang an. Dieser Leitfaden behauptet keine WhiteLotto-Zertifizierung und garantiert weder Verfügbarkeit, Wiederherstellungszeit noch Datenverlustgrenze.
Besprechen Sie die technische Eignung
Informieren Sie sich über die WhiteLotto-Plattformlösung und kontaktieren Sie WhiteLotto für ein Gespräch zur technischen Eignung. Bringen Sie Produktumfang, Integrationsinventar, Nachweisanforderungen und vorgeschlagene Servicelevels mit, damit Zuständigkeiten und offene Fragen dokumentiert werden können.
Tests sind begrenzt und können Sicherheit, Genehmigung oder künftige Compliance nicht garantieren. Die Annahme von Nachweisen bleibt der zuständigen Behörde oder Gegenpartei vorbehalten; Lizenzierung und professionelle Beratung sind getrennte Arbeitsbereiche. Dies ist ein technischer Beschaffungsleitfaden, keine Rechtsberatung.