Seit dem 1. April 2025 sind alle 64 neuen Anforderungen von PCI DSS 4.x in jedem Assessment verbindlich, und der alte Standard v3.2.1 ist seit März 2024 zurückgezogen (PCI SSC). Für jeden deutschen Online-Shop, der Kreditkartenzahlungen entgegennimmt — auch über iframe oder Redirect —, bedeutet das: Skript-Management, MFA und kontinuierliche Audit-Log-Reviews gehören jetzt zum Pflichtprogramm. Gleichzeitig hat sich die Bedrohungslage verschärft. Magecart-Angriffe legten 2024 innerhalb von sechs Monaten um 103 % zu (LevelBlue/SpiderLabs), und im deutschen E-Commerce-Markt mit einem Jahresvolumen von 80,6 Mrd. EUR (BEVH) sind Kartendaten eines der lohnendsten Ziele. Dieser Leitfaden erklärt, was sich ändert, wo die typischen Compliance-Lücken liegen und wie wir bei XICTRON Shops auf PCI DSS 4.0 ausrichten.
Warum PCI DSS 4.0 für jeden Online-Shop relevant ist
PCI DSS gilt für jede Organisation, die Kreditkartendaten verarbeitet, übermittelt oder speichert — unabhängig von Größe oder Transaktionsvolumen. Der Standard wurde von den großen Kartennetzwerken entwickelt und wird über die Acquirer-Verträge durchgesetzt. Auch wer vermeintlich "nur" ein iframe-Checkout-Formular eines Payment Service Providers einbindet, bleibt in der Verantwortung. Die Neuerungen in Version 4.x stellen sicher, dass die Karteninhaberdaten-Umgebung (CDE) nicht nur technisch, sondern auch organisatorisch geschützt ist. Wer Compliance ignoriert, riskiert Strafen und — im Schadenfall — höhere Haftung.
Die Bedrohungslage zwingt ohnehin zum Handeln. Der IBM Cost of a Data Breach Report 2025 beziffert die durchschnittlichen Kosten einer Datenpanne weltweit auf 4,44 Mio. USD (IBM). Im deutschen E-Commerce-Markt mit 80,6 Mrd. EUR Jahresvolumen (BEVH) bleiben Kartendaten das lohnendste Ziel. Der Bitkom Wirtschaftsschutz 2024 beziffert den jährlichen Schaden durch Cyberkriminalität in Deutschland auf 178,6 Mrd. EUR (Bitkom), 81 % der Unternehmen waren in den zurückliegenden 12 Monaten von Datendiebstahl oder Sabotage betroffen, und 65 % sehen sich durch Cyberangriffe existenziell bedroht (Bitkom).
- 311 Mrd. Web-Attacks wurden 2024 weltweit gemessen, ein Plus von 33 % gegenüber dem Vorjahr (Akamai State of the Internet 2025)
- über 230 Mrd. dieser Angriffe trafen Commerce-Organisationen (Akamai)
- 150 Mrd. API-Angriffe zwischen Januar 2023 und Dezember 2024, OWASP-API-Incidents legten um 32 % zu (Akamai)
- PCI-Non-Compliance-Strafen reichen von 5.000 bis 100.000 USD pro Monat je nach Merchant-Größe (NordLayer)
- Zusätzlich fallen 50 bis 90 USD pro kompromittiertem Datensatz an (Secureframe)
- Der BSI Lagebericht 2025 verzeichnet täglich 24 % mehr neue Schwachstellen; KMU sind in 80 % der Ransomware-Fälle betroffen (BSI)
Was sich seit März 2025 grundlegend geändert hat
PCI DSS 4.0 wurde im März 2022 veröffentlicht. Die Vorgängerversion v3.2.1 wurde am 31. März 2024 offiziell zurückgezogen (PCI SSC). Zeitgleich wurden 13 neue Anforderungen sofort verbindlich, während 51 weitere als "future-dated" markiert waren und bis zum 31. März 2025 umgesetzt sein mussten (PCI SSC). Seit dem 1. April 2025 sind alle 64 Neuerungen in jedem Assessment bindend (CompliancePoint). Eine "Limited Revision" zu v4.0.1 folgte am 11. Juni 2024 und schuf unter anderem Klarstellungen zum Skript-Management (PCI SSC).
Die Folge: Viele Shop-Betreiber, die 2023 noch mit einem vereinfachten SAQ A durchkamen, müssen 2026 den kompletten Anforderungskatalog nachweisen. Besonders betroffen sind die Bereiche Skript-Integrität, MFA, Audit-Logging und Pen-Testing — alles Themen, die sich nicht kurzfristig durch eine Checkliste abarbeiten lassen. Wer jetzt erst anfängt, hat Handlungsdruck. Mehr zum Sicherheits-Mindset haben wir im Zero-Trust-Guide für Online-Shops zusammengefasst.
| Bereich | v3.2.1 (bis 03/2024) | v4.x (ab 04/2025) |
|---|---|---|
| Passwortlänge | mindestens 7 Zeichen | mindestens 12 Zeichen, alphanumerisch (Req. 8.3.6) |
| MFA | nur Administratoren | alle Non-Console-Zugriffe in der CDE (Req. 8.4.2) |
| Skript-Inventar | nicht gefordert | vollständiges Inventar mit Autorisierung (Req. 6.4.3) |
| Tamper-Detection | nicht gefordert | mindestens wöchentliche Prüfung der Payment-Page (Req. 11.6.1) |
| Audit-Log-Review | täglich manuell möglich | automatisiert (Req. 10.4.1.1) |
| Pen-Testing | jährlich | jährlich plus Multi-Tenant-Support (Req. 11.4.7) |
Neu in v4.x ist der "Customized Approach": Organisationen dürfen Schutzziele auch mit alternativen Kontrollen erreichen, solange ein dokumentiertes Risk-Assessment vorliegt. Das gibt größeren Shops Spielraum, setzt aber voraus, dass Bedrohungsmodelle sauber formalisiert werden. Für die meisten KMU bleibt der "Defined Approach" mit den Standardkontrollen der pragmatische Weg.
Magecart und Web-Skimming: Die akute Bedrohung
Magecart bezeichnet eine lose Gruppe von Akteuren, die JavaScript in Checkout-Seiten einschleusen und Kartendaten direkt im Browser des Kunden abgreifen — unbemerkt vom Shop-Backend und von klassischen Firewalls. Die Angriffe treffen oft nicht die Shop-Software selbst, sondern Drittanbieter-Skripte, die auf der Payment-Seite geladen werden. 2024 wurden 11.000 einzigartige E-Commerce-Domains von eSkimming-Kampagnen getroffen — ein Plus von 300 % gegenüber 2023 (Source Defense). Im selben Jahr wurden 269 Millionen Karten client-seitig kompromittiert (Source Defense).
Besonders schmerzhaft war 2024 die Schwachstelle CosmicSting (CVE-2024-34102), die rund 75 % aller Adobe-Commerce- und Magento-Installationen betraf (Sucuri/LevelBlue). Der Verizon DBIR 2024 ordnet 18 % aller Retail-Datenpannen Magecart-artigen Angriffen zu (Verizon). Magecart-spezifische Telemetriedaten zeigen zudem, dass sich die Angriffswelle 2024/2025 innerhalb von sechs Monaten mehr als verdoppelt hat — ein Plus von 103 % (LevelBlue/SpiderLabs).
Magecart-Skripte werden oft über legitime Drittanbieter (Analytics, Chat, Werbe-Pixel) nachgeladen. Server-seitige Scanner sehen davon nichts, weil die Manipulation erst im Browser passiert. Genau deshalb verlangen Requirements 6.4.3 und 11.6.1 ein aktives Skript-Management mit Integritätsprüfung. Ergänzend empfiehlt sich ein zweiter Verteidigungsring gegen KI-gestützte Angriffe, denn Angreifer automatisieren ihre Kampagnen zunehmend.
Skript-Management nach 6.4.3 und 11.6.1
Requirements 6.4.3 und 11.6.1 sind das Herzstück der v4.x-Neuerungen für Shop-Betreiber. Sie verlangen drei Dinge: ein vollständiges Inventar aller Skripte, die auf Zahlungsseiten geladen werden, eine dokumentierte Autorisierung jedes Skripts mit Begründung seiner Notwendigkeit und eine Integritätsprüfung per Tamper-Detection mindestens einmal pro Woche (PCI SSC/Akamai). In der Praxis heißt das: Jedes externe oder intern nachgeladene Skript muss bekannt, dokumentiert und überwacht sein.
Die Dimension wird oft unterschätzt. Durchschnittliche Seiten laden inzwischen 18 Skripte, Tendenz innerhalb von zwei Jahren um 50 % gestiegen, und 40 % aller Skripte werden ausgerechnet auf Payment-Seiten ausgeführt (Source Defense). Im E-Commerce stammt rund die Hälfte des JavaScripts von Drittanbietern (Akamai). Trotzdem haben nur 36 % der Unternehmen überhaupt Werkzeuge gegen Data-Skimming im Einsatz (Jscrambler).
Content-Security-Policy:
default-src 'self';
script-src 'self' https://js.psp-example.com 'sha384-4g5z...';
connect-src 'self' https://api.psp-example.com;
frame-src https://checkout.psp-example.com;
report-uri /csp-report-endpoint;
<!-- Subresource Integrity für statisch eingebundene Skripte -->
<script
src="https://js.psp-example.com/v1/widget.js"
integrity="sha384-4g5z.../abc123=="
crossorigin="anonymous"></script>CSP und Subresource Integrity sind jedoch nur Bausteine. Ergänzend braucht es Server-seitiges Rendering, ein Script-Inventar im Change-Management und ein Monitoring, das Hash-Abweichungen protokolliert und alarmiert. Wer eine Plattform wie Shopware betreibt, sollte Theme-Updates und Plugin-Rollouts zwingend mit einem Skript-Audit koppeln.
MFA und Authentifizierung verschärft
Die Passwort-Anforderungen wurden mit v4.x deutlich verschärft. Requirement 8.3.6 verlangt nun mindestens 12 alphanumerische Zeichen (vorher 7). Viel wichtiger ist Requirement 8.4.2: Seit dem 31. März 2025 muss Multi-Faktor-Authentifizierung für jeden Non-Console-Zugriff innerhalb der CDE aktiv sein, nicht mehr nur für administrative Accounts (Schellman). Das betrifft jeden Shop-Mitarbeiter, der remote auf Server, Datenbanken oder Admin-Oberflächen zugreift, über die Kartendaten sichtbar sein könnten.
Warum das so wichtig ist, zeigt der Verizon DBIR 2025: 88 % aller grundlegenden Web-Application-Angriffe laufen über gestohlene Zugangsdaten (Verizon). Ein zweiter Faktor — idealerweise als Hardware-Key oder Phishing-resistenter Authenticator — entwertet den kompromittierten Login. Wer bisher SMS-Codes einsetzt, sollte zeitnah auf TOTP- oder FIDO2-basierte Verfahren migrieren. Für die praktische Umsetzung planen wir in unseren Beratungsprojekten standardmäßig ein Rollen-Audit ein: Wer braucht wirklich CDE-Zugriff, wer kann über ein gescoptes Admin-Panel abgebildet werden?
Vulnerability Scans und Penetration Tests im Quartalstakt
PCI DSS 4.x schreibt quartalsweise externe ASV-Scans durch einen Approved Scanning Vendor vor. Jede Schwachstelle mit CVSS-Score ≥ 4,0 muss innerhalb des Scan-Fensters behoben und in einem Clean-Scan nachgewiesen werden (PCI SSC). Ergänzend sind authentifizierte interne Scans (Req. 11.3.1.2) ebenfalls quartalsweise verpflichtend (CompliancePoint). Penetration-Tests sind jährlich sowie nach wesentlichen Änderungen durchzuführen. Neu: Seit dem 31. März 2025 müssen Multi-Tenant-Service-Provider (also auch Hoster und Cloud-Anbieter) ihre Kunden aktiv bei externem Pen-Testing unterstützen — Requirement 11.4.7 (KirkpatrickPrice). Für Shop-Betreiber bedeutet das konkret: der Hoster muss Testumgebungen, Zugangswege und eine Koordinationsinstanz bereitstellen, damit Pen-Tester legal und produktivsicher arbeiten können. Wer eigenen Code im Checkout pflegt, profitiert zusätzlich von begleitender individueller Programmierung, die Security-Reviews in jede Release-Pipeline einzieht.
Tokenisierung als Scope-Reduzierer
Die wirkungsvollste Strategie, um PCI-Aufwand überhaupt zu reduzieren, bleibt die Tokenisierung: Statt der echten Kartennummer (PAN) verarbeitet und speichert der Shop nur ein Token des Payment Service Providers. Laut Cybersource lässt sich der Compliance-Aufwand dadurch um bis zu 90 % reduzieren (Cybersource). Network Tokens gehen noch einen Schritt weiter: Sie werden direkt vom Kartennetzwerk ausgestellt und automatisch aktualisiert, wenn Karten verloren gehen oder ablaufen. Das erhöht die Autorisierungsraten laut ACI Worldwide um 2 bis 3 Prozentpunkte (ACI Worldwide).
13,7 Mrd. Visa Tokens
Visa hat mittlerweile 13,7 Mrd. Network Tokens ausgegeben; rund 50 % aller Visa-E-Commerce-Transaktionen laufen tokenisiert (Payments Dive).
35 % bei Mastercard
Mastercard tokenisiert 35 % aller Transaktionen und peilt bis 2030 100 % E-Commerce-Tokenisierung an (PYMNTS).
Bis zu 90 % weniger Scope
Shops, die PAN konsequent auslagern, reduzieren ihren PCI-Scope laut Cybersource um bis zu 90 % (Cybersource).
Für die meisten deutschen Mittelständler ist damit der Weg klar: PAN so früh wie möglich durch Tokens ersetzen, den Checkout in einen gehosteten Iframe oder eine Redirect-Seite des PSP auslagern und im Shop-Backend nur noch Tokens vorhalten. Wer Wallet-Zahlungen und neue europäische A2A-Verfahren wie Wero einbindet, entkoppelt sich zusätzlich von klassischen Kartenrisiken. Und Express-Checkout-Varianten profitieren ohnehin von tokenisierten Zahlungsmitteln.
SAQ A vs. A-EP vs. D — welcher Bogen für welchen Shop?
Self-Assessment Questionnaires (SAQs) sind die praktische Umsetzung der Compliance für Merchants der Stufen 2 bis 4. Die Wahl des richtigen SAQ entscheidet über Aufwand und Kosten. SAQ A richtet sich an Shops, die den Zahlungsprozess vollständig an einen PCI-zertifizierten Dienstleister auslagern (iframe oder Redirect). SAQ A-EP gilt für Shops, die zwar keine PAN-Daten berühren, deren Server aber den Zahlungsprozess beeinflussen (z. B. durch eigene Checkout-Logik). SAQ D ist die Vollversion für Merchants, die Kartendaten selbst verarbeiten oder speichern.
| Kriterium | SAQ A | SAQ A-EP | SAQ D (Merchant) |
|---|---|---|---|
| Typischer Shop | iframe / Redirect-Checkout | Eigener Checkout mit JS-Hosted Fields | Server verarbeitet PAN |
| Anforderungen (ca.) | ∼ 24 (Hyperproof) | ∼ 140 (Hyperproof) | ∼ 300+ |
| Skript-Management 6.4.3 / 11.6.1 | Pflicht seit 31.03.2025 oder PSP-Nachweis (FAQ 1588) | Pflicht | Pflicht |
| MFA Req. 8.4.2 | in Admin-Zonen | Pflicht in gesamter CDE | Pflicht in gesamter CDE |
| ASV-Scans quartalsweise | nicht erforderlich | erforderlich | erforderlich |
| Typischer Aufwand | niedrig bis mittel | hoch | sehr hoch |
Mit FAQ 1588 (Stand 31.03.2025) hat das PCI SSC klargestellt: Auch iframe-Merchants müssen die Skript-Anforderungen 6.4.3 und 11.6.1 entweder selbst umsetzen oder eine dokumentierte Bestätigung ihres PSP vorlegen, dass dieser die Skripte auf der Payment-Seite managt (PCI SSC/DWT). Wer bisher gedacht hat, ein iframe schiebe die Verantwortung komplett weiter, liegt falsch. Prüfen Sie die Verträge Ihres Payment-Dienstleisters entsprechend.
Cloud Shared Responsibility verstehen
Wer seinen Shop in der Cloud betreibt, teilt sich PCI-Verantwortung mit dem Cloud-Anbieter. AWS veröffentlicht dafür eine PCI DSS Responsibility Matrix, in der klargestellt wird, welche Kontrollen AWS übernimmt und welche beim Kunden bleiben — Daten, Betriebssystem-Patches und Firewall-Konfiguration gehören in der Regel zur Kundenverantwortung (AWS Whitepaper). Microsoft Azure veröffentlicht eine eigene Matrix, die nach Service-Typ differenziert (Microsoft Learn). Für Betreiber ist entscheidend, den eigenen Anteil aktiv zu erheben und nicht davon auszugehen, dass eine zertifizierte Plattform alle Kontrollen automatisch abdeckt.
Wer einen deutschen Hoster bevorzugt, sollte auf eine ausdrückliche PCI-Verantwortlichkeitsmatrix und auf belegbare Zertifizierungen für das Rechenzentrum achten. Für unsere Shop-Kunden liefern wir eine dokumentierte Trennung der Verantwortlichkeiten sowie Logging- und Patch-Workflows, die sich am PCI-Mindestmass orientieren — ohne dass wir einen eigenen QSA-Status anbieten.
Compliance in 7 Schritten erreichen
Der Weg zu PCI DSS 4.0 lässt sich pragmatisch strukturieren. Die folgende Reihenfolge hat sich in unseren Beratungsprojekten bewährt und vermeidet teure Umwege.
- Scope festlegen: Alle Systeme, Netzwerke, Skripte und Dienstleister identifizieren, die Kartendaten berühren oder beeinflussen können. Diagramm mit Datenflüssen anfertigen.
- Gap-Analyse: Ist-Zustand gegen die 64 Neuerungen von v4.x spiegeln, priorisierte Lücken-Liste mit Verantwortlichen erstellen.
- Scope reduzieren: Kartendaten tokenisieren, Checkout auf gehosteten PSP auslagern, Admin-Zonen aus der CDE entfernen — die wirkungsvollste Maßnahme vor jeder Technik.
- Skript-Inventar aufbauen: Jede Zeile JavaScript auf Zahlungsseiten erfassen, CSP und SRI aktivieren, Tamper-Detection-Monitoring einrichten (Req. 6.4.3/11.6.1).
- Technische Kontrollen härten: MFA 8.4.2 überall, Passwort-Policy 8.3.6 auf 12 Zeichen, automatisierte Log-Reviews 10.4.1.1 aufsetzen.
- Scans und Tests: ASV-Scans quartalsweise, interne authentifizierte Scans, jährliche Pen-Tests — alles mit dokumentierten Reports und Remediation-Nachweisen.
- Kontinuierliches Monitoring: Audit-Logs 12 Monate vorhalten (davon drei Monate sofort abrufbar), Security-Control-Ausfälle gemäß 10.7.2 erkennen und beheben.
Nur 14,3 % der Organisationen haben 2023/24 laut Verizon Payment Security Report die volle PCI DSS Compliance aufrechterhalten; der Control-Gap lag im Schnitt bei 4,5 % gegenüber 3,2 % im Vorjahr (Verizon). Der Grund: Einmal bestanden, verfallen Kontrollen schnell. Wer Compliance als Dauerbetrieb und nicht als jährliches Ritual begreift, vermeidet spätere Nachbesserungen. Auch Marketing-Attribution und Fraud-Prevention profitieren von sauber geführten Audit-Logs.
Wie XICTRON Ihre Shop-Sicherheit härtet
Wir begleiten Shop-Betreiber bei der Umsetzung von PCI DSS 4.0 entlang des gesamten Stacks — vom Hosting über Scope-Reduktion durch Tokenisierung und sauberes Skript-Management für Shopware- und WooCommerce-Checkouts bis zu MFA-Rollouts und automatisierten Log-Reviews im Cloud-Betrieb. Wir liefern keine QSA-Zertifizierung, sondern die technische und organisatorische Grundlage, auf der Ihr QSA anschließend prüfen kann. Starten Sie am besten mit einem strukturierten Gap-Assessment.
Dieser Artikel basiert auf Daten und Anforderungen aus: PCI Security Standards Council (v4.0 / v4.0.1 / FAQ 1588), CompliancePoint (Future-dated Requirements), Schellman (MFA 8.4.2), KirkpatrickPrice (Req. 11.4.7), NXLog (Req. 10.4.1.1, 10.7.2), Source Defense (eSkimming 2024, Script Inventory), Jscrambler (Data Skimming Survey), Akamai (State of the Internet 2025, API Attacks, JavaScript Study), LevelBlue/SpiderLabs (Magecart Uptick 2024/2025), Sucuri (CosmicSting CVE-2024-34102), Verizon (DBIR 2024, DBIR 2025, Payment Security Report 2024), IBM (Cost of a Data Breach 2024/2025), NordLayer (Non-Compliance Fines), Secureframe (Per-Record Penalties), Hyperproof (SAQ Comparison), Davis Wright Tremaine/DWT (FAQ 1588 Analysis), Cybersource (Tokenization Scope Reduction), Payments Dive (Visa Network Tokens), PYMNTS (Mastercard Tokenization Roadmap), ACI Worldwide (Auth-Rate Uplift), BEVH (E-Commerce Deutschland 2024), Bitkom (Wirtschaftsschutz 2024), BSI (Lagebericht 2025), AWS (PCI DSS Responsibility Matrix), Microsoft Learn (Azure PCI Responsibility), SecurityBrief (Card Fraud EMEA). Die genannten Werte können je nach Stichtag, Region und Merchant-Profil variieren.
Ja. Seit FAQ 1588 (Stand 31.03.2025) hat das PCI SSC klargestellt, dass auch iframe-Merchants die Skript-Anforderungen 6.4.3 und 11.6.1 entweder selbst umsetzen müssen oder eine dokumentierte Bestätigung ihres Payment Service Providers vorlegen müssen, dass dieser die Skripte auf der Payment-Seite managt (PCI SSC/DWT). SAQ A reduziert die Anforderungen auf rund 24 Punkte (Hyperproof), entbindet aber nicht von Skript-Integrität und MFA.
PCI-Strafen werden über den Acquirer-Vertrag durchgesetzt und liegen laut NordLayer typischerweise zwischen 5.000 und 100.000 USD pro Monat, abhängig von der Merchant-Größe (NordLayer). Im Schadenfall kommen nach Secureframe-Daten 50 bis 90 USD pro kompromittiertem Datensatz hinzu (Secureframe). In der Regel schützen sich Organisationen durch frühzeitige Gap-Analysen und dokumentierte Maßnahmen.
Externe ASV-Scans sind quartalsweise verpflichtend; jede Schwachstelle ab CVSS 4,0 muss im Scan-Fenster behoben und in einem Clean-Scan nachgewiesen werden (PCI SSC). Authentifizierte interne Scans (Req. 11.3.1.2) sind ebenfalls quartalsweise erforderlich (CompliancePoint). Penetration-Tests sind jährlich sowie nach wesentlichen Änderungen der CDE durchzuführen.
Ja. Cybersource beziffert die mögliche Scope-Reduktion durch Tokenisierung auf bis zu 90 % (Cybersource), weil die echte Kartennummer (PAN) die Shop-Systeme gar nicht erst erreicht. Visa zählt inzwischen 13,7 Mrd. ausgegebene Network Tokens (Payments Dive), Mastercard tokenisiert 35 % aller Transaktionen und plant bis 2030 100 % E-Commerce-Tokenisierung (PYMNTS). In der Praxis ist Tokenisierung der wirkungsvollste Einzelhebel, um Compliance-Kosten zu senken.
Seit dem 31. März 2025 müssen Multi-Tenant-Service-Provider nach Requirement 11.4.7 ihre Kunden bei externem Pen-Testing unterstützen (KirkpatrickPrice). Das betrifft jeden Managed-Hoster, auf dem Shop-Software betrieben wird. Unsere Managed-Umgebungen für Shop-Kunden stellen Testumgebungen, klare Kommunikationswege und dokumentierte Shared-Responsibility-Matrizen bereit. Eine vollständige QSA-Zertifizierung ersetzen wir damit nicht — wir schaffen aber die technische Grundlage.
PCI DSS 4.x verlangt, dass Audit-Logs mindestens zwölf Monate aufbewahrt werden, davon die letzten drei Monate direkt und ohne Wiederherstellung aus Backups zugreifbar (PCI SSC). Requirement 10.4.1.1 fordert seit dem 31.03.2025 zusätzlich automatisierte Log-Reviews (NXLog), und 10.7.2 verlangt das fortlaufende Erkennen und Beheben von Ausfällen der Security-Controls (NXLog). Praktisch heißt das: Log-Pipeline mit zentralem SIEM, Alarm bei Ausfall einer Quelle und dokumentierte Incident-Reaktion.