Sicherheit bei der Systemauswahl: Updates, Zertifizierung, Haftung

Sicherheit lässt sich bei der Systemauswahl an Nachweisen beurteilen, nicht an Eigenschaftswörtern: eine schriftliche Frist, ein Prüfbericht mit Datum, ein Zertifikat mit Geltungsbereich. Maßstab sind Dokumente, die nicht an ein Land gebunden sind: ISO/IEC 27001, die Projekte der OWASP Foundation und PCI DSS. Dazu kommt der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik (BSI).

Worum es bei der Auswahl geht

Unterscheiden Sie drei Stufen: Zusage im Angebot, Dokument mit Regel oder Ergebnis, Prüfung durch eine benannte dritte Stelle. Zertifikat und Testat gehören zur dritten Stufe. Ein Prüfbericht dagegen kann aus einer internen Prüfung stammen: APP.3.1.A22 verlangt regelmäßige Prüfungen mit dokumentierten Ergebnissen, aber keine externe Prüfstelle. Wer den Bericht erstellt hat, müssen Sie gesondert erfragen.

Geprüft werden die Webanwendung, ihre Erweiterungen und die Umgebung, in der sie läuft. Produkte und Anbieter nennt dieser Artikel nicht. Hosting und Betrieb behandelt Hosting für den Onlineshop, die Pflichten aus dem Datenschutz und ihre Nachweise Datenschutz bei der Shopsystem-Auswahl.

Diese Kriterien zählen

Die Bausteinnummern stammen aus dem IT-Grundschutz-Kompendium, Edition 2023; die Spalte mit der Frage lässt sich unverändert in einen Fragebogen übernehmen.

Kriterium	Warum es zählt	So prüfen Sie es	Frage an den Anbieter
Patch- und Update-Politik	Fristen und Zuständigkeiten entscheiden, wie lange eine Lücke offen steht	Schriftliche Politik und Sicherheitshinweise der letzten zwölf Monate anfordern (unser Zeitraum)	Innerhalb welcher Frist nach Veröffentlichung spielen Sie ein Sicherheitsupdate für eine kritische Lücke ein, und wer entscheidet?
Unterstützte Versionen	Ohne Sicherheitsupdates gilt nach OPS.1.1.3.A15: nur weiterbetreiben, wenn sicherer Betrieb geprüft und möglich ist	Liste der Versionen mit Datum des Supportendes	Für welche Versionen liefern Sie Sicherheitsupdates bis wann, und was kostet der Wechsel?
Sicherheitskontakt und Schwachstellenmeldung	Ein benannter Meldeweg macht die zuständige Stelle auffindbar; RFC 9116 nennt fehlende Meldewege als Grund für nicht gemeldete Schwachstellen und bezeichnet security.txt als Ergänzung bestehender Kontaktwege	Datei security.txt nach RFC 9116 abrufen und Probeanfrage stellen	An wen melde ich eine Schwachstelle, und welche Reaktionszeit sagen Sie zu?
Prüfbericht zu Webanwendung und Schnittstellen	APP.3.1.A22 verlangt regelmäßige Prüfung mit dokumentierten Ergebnissen, aber keine externe Prüfstelle; der Bericht zeigt geprüfte Pfade	Letzten Bericht mit Datum, Umfang, durchführender Stelle (intern oder extern) und offenen Feststellungen anfordern	Wer hat wann was geprüft, ist die Stelle intern oder extern, und welche Feststellungen sind noch offen?
Anmeldung und Sitzungen	Kunden- und Administrationszugänge sind ein eigener Angriffspfad	Sperre nach Fehlversuchen, Abmeldung und Rollen an einem Testkonto ausprobieren (APP.3.1.A1)	Nach wie vielen Fehlversuchen sperrt das System, und wie werden Zugangsdaten serverseitig gespeichert?
Verschlüsselung der Verbindung	Ohne Transportverschlüsselung stehen Zugangsdaten und Sitzungen offen	TLS-Version und Zertifikat mit einem Prüfwerkzeug messen und mit TR-02102-2 vergleichen; für Hintergrundsysteme gilt zusätzlich APP.3.1.A11	Welche TLS-Versionen und Cipher-Suiten sind aktiv?
Kopfzeilen, Cookies, Fehlermeldungen	Sie schützen vor Clickjacking und Cross-Site-Scripting (APP.3.1.A21 und A12)	Antwortkopfzeilen und Cookies im Browser ansehen, eine Fehlerseite auslösen	Setzen Sie Content-Security-Policy, Strict-Transport-Security sowie Cookies mit SameSite und httponly?
Protokollierung und Auswertung	Die Auswertung der Protokolldaten ist ein Erkennungsweg; DER.1 verlangt zusätzlich Meldungen von Mitarbeitenden und die Nutzung vorhandener Systemfunktionen (DER.1.A4 bis A6 und A11)	Protokollumfang, Aufbewahrungsdauer, Alarmwege und zuständige Rolle abfragen	Welche Ereignisse protokollieren Sie, wie lange, wer wertet aus und wen alarmiert das?
Erweiterungen und Lieferkette	Ein Risiko der OWASP Top 10:2025 betrifft die Lieferkette von Software (A03)	Liste der Fremdbibliotheken und der Bezugswege anfordern	Wie prüfen Sie Erweiterungen und Bibliotheken, und wie wird die Echtheit von Paketen geprüft (OPS.1.1.3.A10)?
Zertifikate und Testate	Sie belegen geprüfte Prozesse für einen festgelegten Bereich, nicht das Produkt	Zertifikat, Geltungsbereich, Aussteller und Laufzeit vorlegen lassen	Welchen Geltungsbereich hat Ihr Zertifikat, wer hat es ausgestellt, und bis wann gilt es?

Nachweise, die Sie anfordern

Legen Sie je Zeile fest, wer den Nachweis liefert, bis wann und in welcher Form.

Nachweis	Was darin stehen muss	So prüfen Sie ihn
Patch- und Änderungskonzept	Fristen für Bewertung und Einspielen, Priorisierung, Zuständigkeiten und eine Rückfalllösung (OPS.1.1.3.A1, A2 und A15)	Sind alle vier Punkte schriftlich, mit Datum und benannter Rolle, vorhanden?
Sicherheitshinweise	Liste der Sicherheitsupdates der letzten zwölf Monate mit Datum und betroffener Version	Wie lange dauerte es von der Ankündigung bis zur Bereitstellung?
Versions- und Supportliste	Für jede Version das Datum des Supportendes und der Weg in die Nachfolgeversion	Steht bei Ihrer Version ein Datum, und ist der Migrationsweg beschrieben?
Prüfbericht	Datum, Umfang, durchführende Stelle (intern oder extern), Feststellungen mit Einstufung und Behebungsstatus (APP.3.1.A22)	Ist die durchführende Stelle benannt, sind offene Feststellungen mit Termin versehen, und liegt der Bericht nach der letzten größeren Änderung?
Zertifikat oder Testat	Aussteller, Geltungsbereich, Laufzeit; beim BSI-Schema zusätzlich die Prüfung durch einen zertifizierten Auditor beziehungsweise das Testat nach der Basis-Absicherung	Deckt der Geltungsbereich die Umgebung ab, in der Ihr Shop läuft?
Zahlungsdaten: PCI-Nachweis	Bericht eines Qualified Security Assessor oder Attestation of Compliance, dazu der Scanbericht eines Approved Scanning Vendor, soweit der Acquirer das verlangt	Habe ich einen Nachweis zu führen? Diese Frage beantwortet Ihr Acquirer (siehe Was ein Zertifikat belegt und was nicht)
Sicherheitskontakt	Datei security.txt nach RFC 9116 mit Kontaktadresse und Angaben zur Offenlegung, dazu ein interner Ablauf für Meldungen (die Datei ergänzt nach RFC 9116 bestehende Kontaktwege, sie ersetzt sie nicht)	Ist die Datei erreichbar, und was passiert nach einer Testmeldung?
Vertragliche Zusagen	Fristen für kritische Sicherheitslücken, Meldung von Vorfällen, Wartungsfenster, Wiederherstellungszeit, Haftungsgrenzen	Stehen die Zahlen im Vertrag und nicht nur im Angebot?

Wie Sie eine Patch-Politik prüfen

Der IT-Grundschutz formuliert für das Patchmanagement prüfbare Anforderungen. Für die Beschaffung einer Webanwendung nennt APP.3.1.A9 ausdrücklich regelmäßige Sicherheitsupdates durch die Entwickelnden und den Zugriff auf den Quelltext. OPS.1.1.3.A1 verlangt ein Konzept, nach dem Änderungen geplant, genehmigt und dokumentiert werden, mit Rückfalllösungen und Beteiligung der Informationssicherheitsbeauftragten bei größeren Änderungen. OPS.1.1.3.A15 ergänzt, dass Patches zeitnah bewertet und priorisiert, nach dem Einspielen kontrolliert und bei einem Verzicht mit Gründen dokumentiert werden.

Für Produkte ohne Herstellersupport gilt eine klare Regel: Der Baustein OPS.1.1.3 verlangt die Prüfung, ob ein sicherer Betrieb trotzdem möglich ist, und untersagt die weitere Verwendung, wenn das nicht der Fall ist. Fragen Sie Ihren Anbieter deshalb:

• Innerhalb welcher Frist bewerten Sie ein Sicherheitsupdate nach seiner Veröffentlichung?
• Wer entscheidet über das Einspielen, und wo wird eine Entscheidung gegen ein Update festgehalten?
• Wie erfahre ich, dass mein System betroffen ist?
• Was passiert, wenn ein Update den Shop stört — welche Rückfalllösung gibt es?
• Wann endet der Support für meine Version, und was kostet der Wechsel?

Verlangt Ihr Acquirer den Standard, gilt für Karteninhaberdaten eine zweite Frist: Nach der Mitteilung des PCI Security Standards Council zur Fassung v4.0.1 gilt die Vorgabe, Patches innerhalb von 30 Tagen einzuspielen, wieder nur für kritische Schwachstellen.

Was ein Zertifikat belegt und was nicht

ISO/IEC 27001 zertifiziert ein Managementsystem für einen festgelegten Geltungsbereich. Nach der Beschreibung des BSI kann im Fokus ein Informationsverbund oder ein einzelner Bestandteil wie ein Rechenzentrum stehen. Ein Zertifikat für die Zentrale eines Anbieters sagt nichts über den Server Ihres Shops.

Das BSI betreibt daneben ein eigenes Schema: Die Zertifizierung nach ISO 27001 auf der Basis von IT-Grundschutz setzt ein Audit durch einen beim BSI zertifizierten Auditor voraus, über die Ausstellung entscheidet das BSI. Das Testat nach der Basis-Absicherung dürfen nur beim BSI zertifizierte Auditoren vergeben.

PCI DSS ist ein Standard des PCI Security Standards Council und keine staatliche Vorschrift. Der Rat setzt die Einhaltung nach seinen eigenen Angaben nicht durch; ob und in welcher Form Sie sie nachweisen, bestimmen Organisationen mit Compliance-Programm, etwa Kartenorganisationen und Acquirer. Geltende Fassung ist v4.0.1 vom 11. Juni 2024, v4.0 wurde am 31. Dezember 2024 zurückgezogen, die neuen Anforderungen gelten seit 31. März 2025. Ohne Karteninhaberdaten im Shop klären Sie diese Frage mit Ihrem Acquirer.

Der Application Security Verification Standard (ASVS) ist dagegen ein Prüfmaßstab mit gekennzeichneten Anforderungen. Aktuelle stabile Fassung ist nach der Projektseite 5.0.0; verlangen Sie im Bericht die Kennung samt Version. Die OWASP Top 10:2025 ist ein Bewusstseinsdokument und eignet sich als Themenliste, nicht als Nachweis.

Warnsignale in Angebot und Vertrag

• Ein Zertifikat ohne Geltungsbereich, Aussteller oder Laufzeit.
• Zusagen zur Sicherheit ohne Dokument, Frist oder benannte Rolle.
• Keine Angabe zur Frist für Sicherheitsupdates sowie kein benannter Sicherheitskontakt und keine Angaben zur Offenlegung von Schwachstellen.
• Ein Prüfbericht ohne Datum, Umfang oder Liste der offenen Feststellungen.
• Eine Version ohne Datum des Supportendes und ohne beschriebenen Migrationsweg.
• Wartungsfenster, Wiederherstellungszeiten oder Haftungshöchstgrenzen nur mündlich zugesagt.

Welche Haftungsgrenzen und Freistellungen zulässig sind, folgt aus dem Recht Ihres Landes; klären Sie das mit Ihrer Rechtsberatung, bevor Sie unterschreiben.

So vergleichen Sie in fünf Schritten

1. Legen Sie den Schutzbedarf fest: Welche Daten verarbeitet der Shop, und welche Ausfallzeit ist tragbar? Der IT-Grundschutz beschreibt mit Basis-, Kern- und Standard-Absicherung drei Vorgehensweisen.
2. Teilen Sie Ihre Sicherheitsanforderungen in Muss, Soll und Kann ein und übernehmen Sie die Musterfragen in ein Lastenheft (Anforderungsliste erstellen).
3. Lassen Sie je Muss-Anforderung den passenden Nachweis liefern und prüfen Sie Datum, Umfang und Aussteller.
4. Messen Sie selbst: TLS-Version und Antwortkopfzeilen im Browser, Fehlermeldungen, Sperre nach Fehlversuchen, Rollen eines Testkontos. Was Sie nicht messen können, bleibt eine Frage an den Anbieter.
5. Halten Sie die Antworten in einem Abnahmeprotokoll fest, mit den Nachweisen als Anlage; Fristen und Meldewege gehören in den Vertrag (Support und Service-Level, Update-Politik und Versionen).