Shop-Sicherheit: Grundschutz-Checkliste für Betreiber

Wer einen Shop betreibt, kann Angriffsflächen nicht abschaffen, aber nummerieren und abarbeiten. Diese Anleitung ordnet acht Schichten, nennt je Schicht die Anforderung aus dem IT-Grundschutz, den Nachweis, den Sie bei der Prüfung sehen wollen, und legt die Prüfungen auf einen Quartalsrhythmus. Die Schichteneinteilung ist unsere Arbeitsgliederung; die Bausteine des IT-Grundschutz-Kompendiums in der Edition 2023, verfügbar seit 1. Februar 2023, fassen dieselben Punkte in zehn Schichten zusammen.

Was Sie vorab brauchen

• eine Liste Ihrer Systeme mit ihrer Schicht: Shopsystem samt Erweiterungen, Server oder Plattform, Datenbank, Zahlungsweg, Warenwirtschaft, Versand-, E-Mail- und Analysedienste
• eine Liste aller Zugänge: Personen mit Administrationsrechten, Mitarbeitende, ausgeschiedene Personen, Dienstkonten und externe Dienstleister
• die Antwort auf die Frage, wo Karten- und Zahlungsdaten anfallen: eigenes Formular, Seite des Zahlungsdienstleisters, eingebetteter Rahmen oder reine Weiterleitung
• Ihre Vertragsunterlagen: Hosting mit Zusagen zu Sicherung und Aktualisierungen, Auftragsverarbeitung, Nachweise des Zahlungsdienstleisters
• ein Ort für Status, Zieldatum und Verantwortliche; die Checklisten des BSI zur Edition 2023 (Stand 11. März 2025) haben genau diese Felder und je Anforderung ein freies Feld für Begründungen

Die acht Schichten und ihre Prüfpunkte

Die Tabelle nennt je Schicht die Angriffsfläche, die Anforderung mit ihrer Fundstelle im IT-Grundschutz und den Nachweis, der bei der Prüfung vorliegt. Die Anforderungstexte stammen aus den Bausteinen der Edition 2023; die Zuordnung zu acht Schichten und die Nachweise sind unsere Arbeitsgliederung, und die Angriffsflächen sind die Kategorien der OWASP Top 10:2025, eines Bewusstseinsdokuments der OWASP Foundation zu Risiken für Webanwendungen.

Schicht	Angriffsfläche	Anforderung (Baustein)	Nachweis bei der Prüfung
Zugänge und Rechte	erratene, wiederverwendete oder gestohlene Zugangsdaten (OWASP A07)	eindeutige Kennung je Person, Rechtevergabe über eigene administrative Rollen, Alt- und Standardkonten deaktivieren oder ändern (ORP.4.A1, ORP.4.A2, ORP.4.A9); Mehr-Faktor-Authentisierung für Administration (ORP.4.A21, Typ Hoch)	Kontenliste mit Rolle und letzter Anmeldung; Beleg, dass ausgeschiedene Zugänge entzogen sind
Shop-Anwendung	fremde Bestellungen und Datensätze, Fehlkonfiguration, automatisiertes Ausprobieren (OWASP A01, A02)	Zugriffsprüfung serverseitig, Zugriff auf nicht benötigte Funktionen aus, Grenzwerte für Anmelde- und Zugriffsversuche (APP.3.1.A1, APP.3.1.A12); Schutz vor automatisierter Nutzung (APP.3.1.A7); Upload-Funktionen eingeschränkt (APP.3.1.A4)	Testkonto ruft eine fremde Bestellung auf und wird abgewiesen; Antwortheader und Cookies geprüft (APP.3.1.A21)
Software und Änderungen	bekannte Lücken in Shopsystem, Erweiterungen und Bibliotheken (OWASP A03, A08)	Konzept mit Planung, Freigabe, Dokumentation und Rückfalllösung (OPS.1.1.3.A1); Patches bewerten, entscheiden, einspielen und dokumentieren (OPS.1.1.3.A15)	Versionsliste mit Datum sowie Patch-Entscheidungen mit Begründung
Server und Netz	Webserver, offene Dienste, Überlast (OWASP A02)	sichere Grundkonfiguration mit minimalen Rechten, nicht benötigte Module aus (APP.3.2.A1); Verzeichnislisten aus (APP.3.2.A2); TLS für alle Inhalte, keine gemischten Inhalte (APP.3.2.A11); nicht benötigte Dienste deaktivieren (SYS.1.1.A6)	kurze Prüfung der offenen Dienste von außen; TLS-Einstellung und Header dokumentiert
Daten und Sicherungen	Verlust, Veränderung und unbefugter Zugriff auf Bestelldaten	Sicherungsplan mit Aufbewahrung und Reihenfolge der Wiederherstellung (CON.3.A4); regelmäßiger Test, ob sich Daten einwandfrei und in angemessener Zeit zurückspielen lassen (CON.3.A15)	Protokoll des letzten Wiederherstellungslaufs mit Datum und Dauer
Zahlungsdaten	Kartendaten im Shop und Skripte auf einer eingebetteten Zahlungsseite (OWASP A03, A08)	Karteninhaberdaten gar nicht selbst verarbeiten; Nachweis nach PCI DSS; bei ausgelagerter Zahlung nach SAQ A: externe Schwachstellenscans durch einen zugelassenen Dienstleister mindestens alle drei Monate (Anforderungen 11.3.2 und 11.3.2.1); Script-Schutz nur bei eingebetteter Zahlungsseite oder eingebettetem Formular, nicht bei reiner Weiterleitung (Eignungskriterium, FAQ 1588)	Bestätigung des Zahlungsdienstleisters und Scanbericht des zugelassenen Anbieters
Protokollierung und Erkennung	Angriffe, die niemand bemerkt (OWASP A09)	protokollieren: erfolgreiche und erfolglose Anmeldungen, fehlgeschlagene Berechtigungsprüfungen, Rechteänderungen (SYS.1.1.A10), Zugriffe und Fehler des Webservers (APP.3.2.A4); Meldewege (DER.1.A3); Auswertung durch benannte Zuständige (DER.1.A6); Protokolle gegen Veränderung schützen (OPS.1.1.5.A10)	Stichprobe der Anmeldungen einer Woche und die auswertende Person
Notfall und Wiederanlauf	Erpressung, Ausfall, Datenabfluss	Richtlinie und Meldewege für Sicherheitsvorfälle (DER.2.1.A2, DER.2.1.A9); Wiederherstellung der Betriebsumgebung (DER.2.1.A6); Meldung an die Aufsichtsbehörde bei einer Verletzung des Schutzes personenbezogener Daten in Deutschland und Österreich unverzüglich und möglichst binnen 72 Stunden ab Bekanntwerden, wenn die Verletzung voraussichtlich zu einem Risiko führt (Art. 33 Abs. 1 DSGVO), in der Schweiz so rasch als möglich bei voraussichtlich hohem Risiko (Art. 24 Abs. 1 DSG)	Telefonliste und Protokoll der letzten Übung mit Datum

Die Anforderungstypen des Kompendiums sind Basis, Standard und Hoch; als Reihenfolge schlagen wir vor: zuerst die Basis-Anforderungen, dann die Standard-Anforderungen, zuletzt die Anforderungen mit dem Typ Hoch, zu denen die Mehr-Faktor-Authentisierung für Administration gehört. Der IT-Grundschutz und die technischen Richtlinien des BSI binden von sich aus niemanden; sie wirken, soweit ein Gesetz oder ein Vertrag auf sie verweist. Den rechtlichen Rahmen für personenbezogene Daten bilden in Deutschland und Österreich die DSGVO — dem Risiko angemessenes Schutzniveau durch technische und organisatorische Maßnahmen, einschließlich Verschlüsselung (Art. 32 Abs. 1 DSGVO, angewendet seit 25. Mai 2018) — und in der Schweiz Art. 8 Abs. 1 DSG (dem Risiko angemessene Datensicherheit, in Kraft seit 1. September 2023). Nach Art. 3 Abs. 2 DSGVO gilt die Verordnung auch für einen Verantwortlichen oder Auftragsverarbeiter außerhalb der Union, der Personen in der Union Waren oder Dienstleistungen anbietet oder deren Verhalten in der Union beobachtet; ein Schweizer Shop, der an Personen in der Union verkauft, ist deshalb für diese Verarbeitung an die DSGVO gebunden, ohne dass die Schweiz Mitgliedstaat wäre. Prüfen Sie jede Zeile gegen Ihren eigenen Aufbau: Ein Shop auf einer gemieteten Plattform kann Zeilen der Schichten Server und Netz prüfen, soweit der Anbieter sie offenlegt.

Schritt für Schritt: Von der Liste zur Quartalsprüfung

Schritt 1: Systeme und Zugänge aufnehmen

Schreiben Sie je System auf, in welcher Schicht es liegt, wer es administriert und welche Verbindungen es nach außen hat. Nehmen Sie auch die Nebenwege auf: Erweiterungen, die niemand mehr nutzt, Testinstallationen, ein Konto für eine Agentur. Ergebnis: eine Liste, die zu Ihrer Tabelle aus dem Abschnitt oben passt und in der kein System fehlt.

Schritt 2: Zahlungsweg klären

Notieren Sie, wo Karten- und Zahlungsdaten anfallen und wer sie berührt. Verarbeiten Zahlungsdienstleister oder Hoster Bestelldaten im Auftrag — also weisungsgebunden für Sie und nicht für eigene Zwecke —, gilt dafür Art. 28 Abs. 3 DSGVO: Der Vertrag bindet sie an dokumentierte Weisungen und regelt Sicherheit sowie Rückgabe oder Löschung der Daten. Entscheidend ist die Rolle: Wer den Zweck und die Mittel der Verarbeitung selbst festlegt, gilt für diese Verarbeitung als Verantwortlicher (Art. 28 Abs. 10 DSGVO), nicht als Auftragsverarbeiter. Nach Art. 3 Abs. 2 DSGVO gilt die Verordnung auch für einen Dienstleister außerhalb der Union, der Personen in der Union Waren oder Dienstleistungen anbietet. Nach FAQ 1604 des PCI Security Standards Council (Juni 2026) enthält SAQ A in der Fassung für PCI DSS v4.x die Anforderungen 11.3.2 und 11.3.2.1 zur externen Schwachstellenprüfung durch einen zugelassenen Dienstleister, auch wenn die Zahlung vollständig ausgelagert ist — bei einer Weiterleitung zur Zahlungsseite und bei einem eingebetteten Rahmen. Nach FAQ 1588 (Februar 2025) gilt für einen eingebetteten Rahmen zusätzlich, dass die Seite nicht für Script-Angriffe anfällig sein darf; für eine reine Weiterleitung gilt das nicht. Lassen Sie sich von Ihrem Acquirer schriftlich bestätigen, welcher Nachweis für Ihren Zahlungsweg gilt. Nach der Ressourcenseite des PCI Security Standards Council verlangt Anforderung 11.3.2 den Nachweis bestandener externer Scans durch einen zugelassenen Dienstleister mindestens alle drei Monate; den Rhythmus der übrigen Nachweise geben Acquirer und Kartenorganisation vor. Den technischen Aufbau beschreibt Kartenzahlung einrichten.

Schritt 3: Basisanforderungen je Schicht abarbeiten

Arbeiten Sie die Basis-Anforderungen der Tabelle ab, bevor Sie über weitergehende Maßnahmen entscheiden. Setzen Sie dabei die Punkte um, die Angriffe am direktesten begrenzen: eigene Kennungen, Rechte nach Rolle, keine Standardkonten, Grenzwerte für Anmeldeversuche, nicht benötigte Funktionen und Dienste aus. Was Sie am Shopsystem nicht ändern können, notieren Sie als offenen Punkt mit Zuständigem beim Anbieter. Ergebnis: je Zeile ein Status — umgesetzt, teilweise oder nicht umgesetzt, mit Begründung.

Schritt 4: Nachweise und Verantwortliche festlegen

Legen Sie je Zeile fest, welcher Nachweis die Umsetzung belegt und wer ihn erbringt. Ein Häkchen genügt nicht: Für die Zugänge ist der Nachweis eine Kontenliste, für die Sicherung ein Protokoll des Zurückspielens, für die Zahlung eine Bestätigung des Dienstleisters. Tragen Sie Zieldatum und Namen in die Checkliste ein; die Felder dafür sind in den BSI-Checklisten vorgesehen. Ergebnis: eine Checkliste, die ein Dritter lesen und prüfen kann.

Schritt 5: Prüftakt und Auslöser festlegen

Setzen Sie zwei Auslöser neben dem Quartalstakt: einen Sicherheitsvorfall und eine Änderung an der Software. Nach OPS.1.1.3.A15 müssen Patches bewertet und priorisiert werden, und wenn ein Patch nicht eingespielt wird, müssen Entscheidung und Gründe dokumentiert werden; nach APP.3.1.A22 sollen Webanwendungen regelmäßig auf Sicherheitsprobleme geprüft werden. Für die Prüfschritte selbst können Sie den Anforderungskatalog ASVS der OWASP Foundation in der Fassung 5.0.0 verwenden, dessen Anforderungen Kennungen wie v5.0.0-1.2.5 tragen. Ergebnis: ein Kalendereintrag je Quartal und ein Auslöser nach jedem Vorfall. Den Änderungsprozess selbst behandelt Prozess für Updates und Wartung.

Schritt 6: Meldepflichten und Notfallweg vorbereiten

Halten Sie fest, wer bei einem Verdacht zuerst informiert wird, wie diese Person außerhalb des Shops erreichbar ist und wer entscheiden darf, den Shop vom Netz zu nehmen. Nach Art. 33 Abs. 1 DSGVO melden Sie eine Verletzung des Schutzes personenbezogener Daten in Deutschland und Österreich unverzüglich und möglichst binnen 72 Stunden ab dem Bekanntwerden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen; in der Schweiz melden Sie dem EDÖB so rasch als möglich, wenn die Verletzung voraussichtlich zu einem hohen Risiko führt (Art. 24 Abs. 1 DSG). Ergebnis: eine Telefonliste und ein Ablauf, den Sie einmal im Jahr durchsprechen. Die Meldung selbst beschreibt Meldepflichten bei einer Datenpanne.

Der Quartalsrhythmus

Ein Jahr hat vier Prüfungen; jede nimmt eine Gruppe von Schichten gründlich durch, damit nicht jedes Quartal alles auf einmal ansteht. Der Schwerpunkt wechselt, die Pflichten aus dem Takt bleiben: Patchfreigaben, Alarmmeldungen und die Nachweise von Hosting und Zahlung laufen das ganze Jahr weiter.

Quartal	Schwerpunkt	Was Sie prüfen	Ergebnis
1. Quartal	Zugänge und Rechte	Kontenliste gegen Personenliste; Kennung je Person; Administrationsrechte; Mehr-Faktor-Authentisierung; gesperrte ausgeschiedene Zugänge	aktualisierte Rechteübersicht mit Datum und Verantwortlichem
2. Quartal	Software und Änderungen	Versionsstand von Shopsystem, Erweiterungen, Server und Bibliotheken; offene Patch-Entscheidungen; Sicherung einmal zurückspielen	Patchliste mit Entscheidungen; Protokoll des Wiederherstellungslaufs mit Dauer
3. Quartal	Anwendung, Server und Netz	Testzugriff auf fremde Bestellung und fremdes Kundenkonto; Grenzwerte für Anmeldeversuche; HTTP-Header und Cookies; Upload-Regeln; offene Dienste von außen	Befundliste mit Zieldatum je Punkt
4. Quartal	Protokollierung, Erkennung und Notfall	Anmeldeprotokolle einer Woche auswerten; Meldewege telefonisch testen; Ablauf für einen Vorfall durchsprechen; Fristen und Zuständigkeiten der Meldung prüfen	Übungsprotokoll und aktualisierte Telefonliste

Zu den Fristen: Art. 32 Abs. 1 Buchst. d DSGVO verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen, nennt aber kein Intervall. Der BSI-Standard 200-2 empfiehlt, für die Aktualisierung einzelner Dokumente Intervalle vorzugeben, und nennt eine jährliche Überprüfung für den überwiegenden Teil der Dokumente als bewährt. Der Quartalstakt und die Aufteilung der Schwerpunkte sind daher unsere Empfehlung, kein gesetzlicher Maßstab; wählen Sie einen Takt, den Ihr Betrieb durchhält, und lösen Sie zusätzlich nach Vorfällen, nach Sicherheitsupdates und beim Ausscheiden von Personen mit Zugriff aus. Unabhängig davon sind die externen Scans nach PCI DSS 11.3.2 mindestens alle drei Monate mit bestandenem Ergebnis nachzuweisen. Personalwechsel und Rechteentzug behandelt Zugriffe und Rechte im Shop.

So prüfen Sie das Ergebnis

• Jede Zeile der Checkliste hat einen Nachweis, ein Zieldatum und einen Namen; keine Zeile trägt nur „erledigt“.
• Ein Testkonto ohne Administrationsrechte kann Preise, Bestellungen und Kundenstammdaten nicht ändern und wird bei jedem Versuch protokolliert.
• Eine Kennung, die zu einer ausgeschiedenen Person gehört, wird abgewiesen.
• Ein Zurückspielen der Sicherung wurde im laufenden Quartal gezeigt, mit Datum und Dauer.
• Ein Scanbericht eines zugelassenen Dienstleisters aus den letzten drei Monaten liegt vor (PCI DSS 11.3.2).
• Prüfung und Vorgabe liegen nicht bei derselben Person, und die Ergebnisse gehen an die Leitung; der BSI-Standard 200-2 empfiehlt das ausdrücklich.

Wenn etwas nicht klappt

Symptom	Ursache	Behebung
Nach einer Prüfung ändert sich nichts	Die Checkliste hat Status, aber kein Zieldatum und keinen Namen	Je offener Zeile Zieldatum und verantwortliche Person eintragen und im nächsten Quartal nachhalten
Der Nachweis fehlt, die Maßnahme läuft aber	Umsetzung und Beleg wurden nicht getrennt erfasst	Nachweis je Zeile benennen, zum Beispiel Kontenliste oder Wiederherstellungsprotokoll, und abheften
Dieselbe Lücke erscheint jedes Quartal	Die Maßnahme liegt außerhalb Ihres Einflussbereichs, etwa beim Anbieter	Punkt mit Zuständigem beim Anbieter und Frist schriftlich festhalten; nötigenfalls den Vertrag prüfen
Niemand merkt einen Angriff	Protokollierung läuft, aber es liest sie niemand	Zuständige Person und Zeitfenster für die Auswertung festlegen (DER.1.A6) und Meldewege bekannt machen (DER.1.A3)
Ein Vorfall dauert länger als gedacht	Rollen und Entscheidungswege fehlen	Richtlinie und Meldewege für Sicherheitsvorfälle schriftlich festhalten (DER.2.1.A2, DER.2.1.A9)

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung, wenn Ihr Shop auf einer Plattform läuft und Sie die Schichten Server, Netz und Protokollierung nicht selbst einsehen können; dann gehört die Prüfung in den Vertrag, den Hosting für den Onlineshop behandelt. Holen Sie sie ebenso, wenn Karteninhaberdaten über Ihre Systeme laufen, wenn Sie einen Schwachstellenscan oder eine Prüfung der Anwendung beauftragen wollen, oder wenn nach einem Vorfall unklar ist, ob gemeldet werden muss. Für die Auswahl der Maßnahmen und die Nachweise, die Sie von einem Anbieter verlangen können, gibt Sicherheit bei der Systemauswahl die Kriterien; die Sicherung im Detail und den Ablauf für einen Ausfall führen Backup und Wiederherstellung und Shop-Ausfall und Notfallplan weiter.