Häufige Fehler: Scope-Creep und Evidenz

Problem in der Praxis

Scope-Creep beginnt meist unsichtbar. Eine neue Anwendung wird an die Kartenumgebung angebunden, ein Reporting-Tool greift auf Transaktionsdaten zu, ein Support-Team erhält Zugriff "nur zur Fehlersuche". Jede einzelne Entscheidung wirkt harmlos, in Summe zieht sie immer mehr Systeme in das Cardholder Data Environment (CDE). Da der Geltungsbereich oft nur einmal jährlich betrachtet wird, fällt das Wachstum erst auf, wenn der Prüfumfang sprunghaft gestiegen ist.

Verstärkt wird das durch fehlende oder nur behauptete Segmentierung. Ohne wirksame Trennung gilt im Zweifel das gesamte Netz als CDE. Viele Organisationen verlassen sich auf eine Trennung, die auf dem Papier existiert, im Betrieb aber durchlässig ist, weil Firewall-Regeln aufgeweicht, Ausnahmen nie zurückgebaut und die Trennung nie getestet wurde.

Das zweite Muster ist die Evidenz auf Zuruf. Wochen vor dem Assessment beginnt eine Sammelaktion: Screenshots werden nachgestellt, Konfigurationen rekonstruiert, Protokolle zusammengesucht, Freigaben rückdatiert dokumentiert. Diese Belege beschreiben einen idealisierten Zustand zum Stichtag, nicht den realen Betrieb der vergangenen zwölf Monate. Sie bestehen vielleicht die Prüfung, sagen aber nichts darüber aus, ob die Kontrollen im Alltag tatsächlich gewirkt haben.

CISO-Einordnung

Beide Fehler haben dieselbe Wurzel: PCI DSS wird als punktuelles Ereignis verstanden, nicht als Dauerzustand. Aus Management-Sicht lohnt der Blick auf den Begriff Business as usual (BAU). Gemeint ist, dass die geforderten Kontrollen in die normalen Betriebsprozesse eingebettet sind und dort fortlaufend ausgeführt, überwacht und belegt werden.

Für den Scope heißt BAU: Der Geltungsbereich ist ein lebender Gegenstand. Jede Änderung an Architektur, Datenfluss, Dienstleistern oder Berechtigungen kann den CDE vergrößern oder verkleinern. Wer Scope-Veränderungen nicht an den Change-Prozess koppelt, verliert die Kontrolle über den wichtigsten Kostentreiber des Standards.

Für die Evidenz heißt BAU: Nachweise entstehen als Nebenprodukt laufender Prozesse, nicht als Sonderaufgabe vor dem Audit. Ein Logreview, eine Zugriffsrezertifizierung oder eine Prüfung der Firewall-Regeln hat nur dann Wert, wenn sie regelmäßig stattfindet und dabei automatisch eine nachvollziehbare Spur hinterlässt. PCI DSS v4.x unterstreicht diese Erwartung, etwa durch klarere Rollen- und Verantwortungszuordnung und durch das Instrument der Targeted Risk Analysis, mit dem die Häufigkeit bestimmter wiederkehrender Aktivitäten begründet festgelegt wird. Die verbindlichen Detailbedingungen dazu regelt der Standard selbst.

Umsetzungsperspektive

Sinnvoll ist, Scope und Evidenz als zwei Regelkreise zu betreiben, die in den normalen Betrieb eingebettet sind:

• Scope laufend führen: Datenfluss-Diagramm und CDE-Bestandsliste aktuell halten und an den Change-Prozess koppeln. Neue Anbindungen, Tools oder Berechtigungen lösen eine Scope-Prüfung aus, nicht erst das nächste Audit.
• Segmentierung verteidigen: Trennregeln dokumentieren, Ausnahmen befristen und zurückbauen, Wirksamkeit regelmäßig durch Tests bestätigen statt voraussetzen.
• Evidenz im Prozess erzeugen: Kontrollen so gestalten, dass ihr Vollzug automatisch protokolliert wird. Ziel ist eine durchgängige Nachweisspur, nicht eine Stichtagssammlung.
• Frequenzen begründen: Für wiederkehrende Aktivitäten festlegen, wie oft sie stattfinden, und diese Festlegung nachvollziehbar herleiten.
• Verantwortung zuweisen: Für Scope-Pflege und Nachweisführung benannte Owner bestimmen, nicht ein anonymes "die IT".

Der Aufwand verschiebt sich dadurch: weg vom jährlichen Kraftakt, hin zu kontinuierlicher, kleinteiliger Pflege. Genau diese Verschiebung ist der Sinn des BAU-Gedankens und reduziert den Stress vor dem Assessment erheblich.

Typische Fehler

1. Den Scope nur einmal jährlich betrachten, sodass schleichendes Wachstum erst beim Audit auffällt.
2. Neue Systeme, Tools und Berechtigungen anbinden, ohne eine Scope-Prüfung auszulösen.
3. Segmentierung annehmen und behaupten, aber nicht testen und nicht pflegen.
4. Firewall-Ausnahmen einrichten, die nie befristet oder zurückgebaut werden.
5. Nachweise erst vor dem Audit sammeln, nachstellen oder rekonstruieren.
6. Kontrollen so betreiben, dass ihr Vollzug keine verwertbare Spur hinterlässt.
7. PCI DSS als Projekt eines Teams behandeln, statt Verantwortung in den Fachprozessen zu verankern.

Risiken und Trade-offs

Ein zu breiter Scope ist dauerhaft teuer: Mehr Systeme bedeuten mehr Kontrollen, mehr Nachweise und höhere laufende Kosten. Ein zu eng gezogener Scope ist gefährlich, weil fälschlich ausgeklammerte Systeme Kartendaten ungeschützt lassen. Die kontinuierliche Scope-Pflege kostet Aufmerksamkeit, verhindert aber beide Extreme.

Bei der Evidenz besteht der Trade-off zwischen Automatisierung und Aufwand. Nachweise im Prozess zu erzeugen erfordert anfangs Investition in Logging, Workflows und klare Zuständigkeiten. Diese Investition zahlt sich aus, weil sie den jährlichen Sammelstress beseitigt und ein belastbares Bild des realen Betriebs liefert. Wer dagegen weiter punktuell sammelt, riskiert nicht nur Audit-Findings, sondern auch echte Sicherheitslücken zwischen den Prüfungen.

Zu beachten ist die Rechtsnatur des Standards. PCI DSS ist kein Gesetz, sondern wird vertraglich über Acquirer und Card Schemes verbindlich. Anhaltender Scope-Creep und schwache Evidenz können zu Vertragsstrafen, höheren Gebühren oder im Extremfall zum Entzug der Kartenakzeptanz führen.

Entscheidungspunkte

• Welcher Trigger im Change-Prozess löst verlässlich eine Scope-Prüfung aus?
• Wer verantwortet die laufende Wirksamkeit und den Nachweis der Segmentierung?
• Welche Kontrollen lassen sich so automatisieren, dass Evidenz als Nebenprodukt entsteht?
• Wie wird die Häufigkeit wiederkehrender Aktivitäten begründet und dokumentiert?
• Welche Rollen tragen Scope- und Nachweisverantwortung dauerhaft, auch zwischen den Audits?
• Wie wird der reale BAU-Zustand gemessen, statt nur den Stichtag vorzubereiten?

Praktische Empfehlungen

1. Koppeln Sie jede wesentliche Änderung an eine Scope-Prüfung, statt den Geltungsbereich nur jährlich zu betrachten.
2. Behandeln Sie Segmentierung als Betriebsaufgabe: dokumentieren, befristen, zurückbauen, testen.
3. Gestalten Sie Kontrollen so, dass ihr Vollzug automatisch eine Nachweisspur erzeugt.
4. Begründen und dokumentieren Sie die Frequenz wiederkehrender Aktivitäten nachvollziehbar.
5. Benennen Sie Owner für Scope-Pflege und Nachweisführung mit klarem Mandat.
6. Prüfen Sie unterjährig stichprobenartig, ob Kontrollen real wirken, statt nur den Audittermin vorzubereiten.
7. Verankern Sie PCI DSS als Business as usual in den Fachprozessen, nicht als jährliches Sonderprojekt.

Relevante Normreferenzen

• PCI DSS (PCI Security Standards Council), aktuelle Version v4.0.1 (veröffentlicht am 11.06.2024, seit 01.01.2025 einzige aktive Version): Referenz für Scope, Segmentierung, kontinuierlichen Sicherheitsbetrieb und Nachweisführung. Verbindliche Anforderungen, Frequenzen und Testverfahren ausschließlich der Originalquelle entnehmen.
• ISO/IEC 27001: Referenz für ein risikobasiertes ISMS mit breiterem Geltungsbereich und etabliertem Regelkreis für Nachweise; hohe Control-Überschneidung, aber kein Ersatz für PCI DSS.
• NIST Cybersecurity Framework und NIST SP 800-53 / 800-63: Referenz als konzeptionelle Mapping-Ebene für fortlaufende Schutz- und Überwachungsfunktionen; kein offizielles 1:1-Mapping durch den PCI SSC.