Kriterienkatalog · Endpoint Detection and Response
EDR-Auswahl: die Kriterien, die unter NIS2 und DORA zählen
Die meisten EDR-Bewertungen prüfen Erkennungsrate und Preis. Unter NIS2 und DORA reicht das nicht. Diese Kriterien entscheiden, ob deine Wahl im Audit hält, nicht nur in der Demo.
Unabhängige Kriterienreferenz · 23 Kriterien · Stand August 2026 · Von keinem Anbieter gesponsert
Eine EDR-Entscheidung sieht aus wie eine Security-Entscheidung. Unter NIS2 und DORA ist sie auch eine Dokumentations- und Jurisdiktionsentscheidung. Das Tool mit dem besten Detection-Score kann die falsche Wahl sein, wenn es einen forensischen Report nicht rechtzeitig exportiert, wenn seine Daten die EU verlassen, oder wenn der Vendor die Nachweise nicht liefern kann, die der Auditor verlangt. Die Kriterien unten sind die, die DecisionOS für einen EDR-Fall auf den Bewertungsbogen setzt, in derselben Reihenfolge und Gruppierung, damit du hier prüfst, was du dort bewertest.
Detection & Response
Kriterium 01
Erkennungsgenauigkeit (MITRE-ATT&CK-Abdeckung)
Warum es zählt
Vom Vendor genannte Erkennungsraten sind Marketing. Was zählt, ist die Leistung in unabhängigen Tests wie der MITRE ATT&CK Evaluation, wo jeder Anbieter unter gleichen Bedingungen gegen dieselben Angriffstechniken getestet wird.
Was du fragst
Bitte um die Ergebnisse aus der aktuellsten MITRE ATT&CK Enterprise Evaluation, konkret die Detection Coverage und die Zahl der verpassten Erkennungen. Nicht die Pressemitteilung, die echten Ergebnisse.
Die Falle
Vendoren zitieren die Evaluationsrunde, in der sie am besten abschnitten, und die kann Jahre alt sein. Frag immer nach der neuesten Runde und prüfe, ob der Vendor an der letzten überhaupt teilgenommen hat.
Kriterium 02
Mean Time to Detect (MTTD)
Warum es zählt
Die Zeit zwischen der ersten Aktion eines Angreifers auf einem Endpunkt und dem ersten Alarm entscheidet, wie viel vom Netz er erreicht. Ein Tool, das eine Ransomware-Kette erst bei der Verschlüsselung erkennt, hat sie technisch erkannt und praktisch verloren. Unter NIS2 Artikel 23 beginnt deine eigene 24-Stunden-Uhr mit der Kenntnis, und Kenntnis beginnt mit diesem Alarm.
Was du fragst
Frag nach der gemessenen Median- und Worst-Case-Zeit von der ersten Ausführung bis zum Alarm für die Techniken der letzten MITRE-Evaluation, und ob der Alarm beim Erstzugriff, bei der Rechteausweitung oder erst beim Schaden auslöst. Frag einen Referenzkunden nach derselben Zahl aus einem echten Vorfall.
Die Falle
"Echtzeit-Erkennung" beschreibt die Telemetrie-Pipeline, nicht die Erkennungslogik. Ein Tool kann Ereignisse in Millisekunden streamen und den Alarm trotzdem eine Stunde später auslösen, wenn ein Cloud-Analysejob läuft. Frag, wo die Verzögerung sitzt, und ob sie wächst, wenn die Cloud des Vendors unter Last steht.
Kriterium 03
Mean Time to Respond (MTTR)
Warum es zählt
Erkennung verschafft dir ein Zeitfenster; Reaktion ist, was du damit tust. Time to Respond ist die Zeit, bis ein Host isoliert, ein Prozess beendet oder ein Konto gesperrt ist, und sie hängt davon ab, ob das Tool handeln kann, wer es auslösen darf und wie schnell die Konsole im Vorfall reagiert. An dieser Zahl wird deine Vorfalls-Zeitleiste gemessen.
Was du fragst
Frag nach der Zeit vom Alarm bis zur ausgeführten Eindämmung in den Messungen des Vendors und im Vorfall eines Referenzkunden, und lass in der Demo bei laufender Uhr einen Host isolieren. Frag, ob Reaktionsmaßnahmen auch funktionieren, wenn der Endpunkt nicht im Firmennetz ist.
Die Falle
"Reaktion in Sekunden" meint den API-Aufruf, nicht den Workflow drumherum. Braucht die Eindämmung einen Analysten, eine Freigabe und ein VPN, ist die echte Zahl Stunden. Miss den Weg, den du nachts tatsächlich gehst, nicht den Knopf in der Demo.
Kriterium 04
Automatisierte Reaktion / Behebung
Warum es zählt
Erkennung ohne Handlung ist eine Benachrichtigung. Wenn sich ein Angreifer um zwei Uhr nachts seitwärts bewegt, begrenzt den Schaden, ob das Tool den Host selbstständig vom Netz nimmt, den Prozess beendet, die Datei isoliert und die Änderungen zurückrollt, nach Regeln, die du vorher gesetzt hast. Unter NIS2 wird die Maßnahme Vorfallsbewältigung daran gemessen, was passiert ist, nicht daran, was gesehen wurde.
Was du fragst
Frag, welche Eindämmungsmaßnahmen das Produkt pro Plattform automatisch ausführen kann, unter welchen Bedingungen, und wie eine falsche automatische Isolation eines Produktionsservers zurückgenommen wird. Lass in der Demo eine Isolation auslösen und den Endpunkt danach wieder anbinden.
Die Falle
"Automatisierte Reaktion" heißt häufig, dass ein Alarm automatisch erzeugt wird und ein Mensch trotzdem auf Isolieren klickt. Bitte um die Liste der Aktionen, die ohne Klick laufen, und prüf sie gegen deine Server, wo automatische Isolation genau das ist, was du nicht willst, solange die Regel nicht präzise ist.
Kriterium 05
False-Positive-Rate
Warum es zählt
Ein Tool, das alles meldet, ist so nutzlos wie eines, das nichts meldet. Hohe False-Positive-Raten zermürben das SOC-Team und führen dazu, dass echte Alarme ignoriert werden. Das ist ein Betriebskosten-Faktor, der im Verkaufsgespräch nie auftaucht.
Was du fragst
Bitte um einen Referenzkunden ähnlicher Größe und Branche, und frag diesen Kunden direkt, wie viele False Positives er pro Woche bearbeitet und wie das Tuning in den ersten drei Monaten lief.
Die Falle
Demo-Umgebungen sind sauber getunt. Das False-Positive-Problem zeigt sich erst, wenn das Tool auf die echte, unaufgeräumte Umgebung trifft. Ein Referenzgespräch zeigt, was eine Demo verbirgt.
Abdeckung & Rollout
Kriterium 06
Betriebssystem- & Plattformabdeckung (Windows, Linux, macOS)
Warum es zählt
Ein EDR schützt nur die Endpunkte, auf denen es läuft. Serverlandschaften sind überwiegend Linux, Entwickler und Geschäftsleitung nutzen oft macOS, und der eine Windows-Server am Lebensende oder das Embedded-System trägt noch Produktion. Ein Vendor, der eine dieser Plattformen als zweite Klasse behandelt, lässt genau die Systeme außerhalb deiner Erkennung, die ein Angreifer sucht, und das Audit zählt sie als ungeschützte Assets.
Was du fragst
Gib dem Vendor dein echtes OS-Inventar inklusive Versionen und End-of-Life-Systemen und frag pro Zeile, ob der Agent mit denselben Erkennungs- und Reaktionsfunktionen wie auf aktuellem Windows unterstützt wird, mit reduziertem Umfang, oder gar nicht.
Die Falle
"Unterstützt" in der Plattformmatrix heißt oft: Der Agent lässt sich installieren. Verhaltenserkennung, Isolation und Rollback gibt es womöglich nur auf Windows, und der Linux-Agent ist ein Dateiscanner. Frag nach Funktionsparität pro Plattform, nicht nach dem Häkchen.
Kriterium 07
Rollout-Komplexität & Einführungsaufwand
Warum es zählt
Ein EDR, das neun Monate braucht, um jeden Endpunkt zu erreichen, schützt neun Monate lang nichts, und die schwer erreichbaren Endpunkte, etwa unverwaltete Laptops, Fertigungs-PCs und Server mit Change-Freeze, bleiben am längsten ungeschützt. Der Rollout-Aufwand ist eine Sicherheitszahl, nicht nur eine Projektzahl.
Was du fragst
Bitte um den Rollout-Plan für deinen echten Bestand: Agent-Paketierung für deine Management-Tools, Verhalten auf Rechnern ohne dauerhafte Verbindung, Koexistenz mit dem Antivirus, das du ablöst, und die Personentage, die ein vergleichbarer Kunde bis 95 Prozent Abdeckung brauchte.
Die Falle
"In Minuten ausgerollt" meint einen Agenten auf einem Rechner. Die Monate stecken in den Ausnahmen: Altsysteme, die mit dem Kerneltreiber abstürzen, der Neustart, den niemand einplanen darf, die zehn Prozent Geräte, die das Management-Tool nie gesehen hat. Frag nach der Abdeckungskurve der letzten drei Rollouts.
Kriterium 08
Performance-Einfluss des Agents (CPU/RAM)
Warum es zählt
Der EDR-Agent läuft auf jedem Endpunkt. Wenn er Rechner ausbremst, merken das die Nutzer, beschweren sich und versuchen im schlimmsten Fall, ihn abzuschalten. Ein schwerer Agent ist ein Sicherheitsrisiko, weil er Druck erzeugt, ihn zu entfernen.
Was du fragst
Bitte um gemessene CPU- und Speicherlast unter normaler Nutzung, und fahr vor der Entscheidung einen Pilot auf echten Rechnern echter Nutzer. Nicht auf sauberen Testmaschinen.
Die Falle
Performance-Benchmarks laufen auf untätigen Rechnern. Der Einfluss, der dich interessiert, zeigt sich auf dem Laptop eines Entwicklers während eines Builds oder auf einem Finance-Rechner mit schweren Tabellen. Teste dort, wo der Schmerz tatsächlich auftreten würde.
Kriterium 09
MDR- / Managed-Detection-and-Response-Option
Warum es zählt
Wenn dein Team kein SOC rund um die Uhr besetzen kann, reicht das Tool allein nicht. Ein reifes MDR-Angebot heißt, dass der Vendor deine Umgebung beobachtet, während dein Team schläft. Unter NIS2 ist die Reaktionszeit keine Kür.
Was du fragst
Frag nach der garantierten Reaktionszeit auf einen kritischen Alarm am Sonntag um drei Uhr nachts, und ob diese Zeit vertraglich bindend ist oder ein Best-Effort-Ziel.
Die Falle
"Wir bieten MDR" kann ein reifes 24/7-Team meinen oder einen dünnen Service, der dir eine Mail schickt und wartet. Der Abstand zwischen beidem ist riesig. Der Vertragstext sagt dir, welches von beiden du bekommst.
Kriterium 10
XDR- / Extended-Detection-Fähigkeit
Warum es zählt
Angriffe bleiben selten auf einem Endpunkt. XDR ist das Versprechen, dass das Tool Endpunkt-Telemetrie mit Identitäts-, E-Mail-, Netzwerk- und Cloud-Signalen zu einem Vorfall korreliert statt zu vier Alarmen in vier Konsolen. Ob diese Korrelation für deine Quellen existiert, entscheidet, ob der Analyst einen Angriff sieht oder eine Liste.
Was du fragst
Frag, welche deiner Nicht-Endpunkt-Quellen die Plattform nativ einliest und zu einem einzigen Vorfall korreliert, ob diese Korrelation vom Vendor gepflegte Logik ist oder eine Suche, die du schreibst, und lass dir einen domänenübergreifenden Vorfall aus einem echten Tenant zeigen, nicht aus einem Demo-Datensatz.
Die Falle
"XDR" im Datenblatt ist häufig das EDR mit angehängtem Data Lake. Ein Log einzulesen ist nicht dasselbe wie es zu korrelieren. Korreliert das XDR des Vendors nur seine eigenen Produkte, deckt das X sein Portfolio ab, nicht deinen Bestand.
Integration & Intelligence
Kriterium 11
SIEM-Integration & Log-Weiterleitung
Warum es zählt
Ein EDR-Tool, das sich nicht sauber in dein SIEM, dein Ticketing und deinen Identity Provider einfügt, wird zur Insel. Isolierte Security-Tools erzeugen blinde Flecken genau dort, wo Angreifer arbeiten: in den Lücken zwischen den Systemen. Und unter NIS2 und DORA wird der Nachweis für die Vorfalls-Zeitleiste im SIEM erwartet.
Was du fragst
Bitte um eine Liste der nativen Integrationen für deinen konkreten Stack, ob die volle Telemetrie oder nur Alarme weitergeleitet werden, in welchem Schema und zu welchen Kosten, und ob der Vendor sie pflegt oder du. Lass dir die Integration in der Demo zeigen, nicht nur auf einer Folie auflisten.
Die Falle
"Integriert sich per API mit allem" heißt: Du baust und pflegst die Integration selbst. Und "SIEM-Integration" leitet oft nur Alarme weiter, während die Rohtelemetrie in der Cloud des Vendors bleibt und der Export extra kostet. Native, vom Vendor gepflegte Integrationen mit voller Ereignisweiterleitung sind weit mehr wert als eine generische API.
Kriterium 12
Qualität der Threat-Intelligence-Feeds
Warum es zählt
Threat Intelligence ist das, womit das Tool eine bekannte Kampagne in der ersten Minute erkennt statt nach der Analyse. Ihr Wert hängt von Aktualität ab, von Relevanz für deine Region und Branche, und davon, ob Indikatoren mit Kontext angereichert sind, mit dem der Analyst arbeiten kann. Veraltete oder generische Feeds erzeugen Alarme, die niemand priorisieren kann.
Was du fragst
Frag, woher die Intelligence kommt, wie schnell die Indikatoren einer neuen Kampagne deinen Tenant erreichen, ob branchen- und regionsspezifische Intelligence (etwa zu Gruppen, die europäische kritische Infrastruktur angreifen) enthalten ist, und ob du eigene Feeds und die deines CERT ergänzen kannst.
Die Falle
"Gestützt auf globale Threat Intelligence" beschreibt die Telemetriebasis des Vendors, und die wird von den Märkten dominiert, in denen er am meisten verkauft. Frag nach dem Anteil der Indikatoren, die jünger als eine Woche sind, und nach einem aktuellen Beispiel einer europäischen Kampagne, die der Feed vor der öffentlichen Berichterstattung erfasst hat.
Kriterium 13
Forensik- & Untersuchungsfähigkeit
Warum es zählt
NIS2 Artikel 23 verlangt binnen 24 Stunden nach Kenntnis eines erheblichen Vorfalls eine Frühwarnung und binnen 72 Stunden die vollständige Meldung. Wenn dein EDR-Tool nicht rekonstruieren kann, was auf dem Endpunkt passiert ist, und die forensischen Daten nicht schnell genug und in nutzbarem Format exportiert, kannst du diese Frist nicht halten, egal wie gut die Erkennung ist.
Was du fragst
Frag nicht "sind Sie NIS2-konform", das bejahen alle. Frag konkret: Wie weit reicht die Endpunkt-Telemetrie zurück, wie schnell kann ich einen vollständigen forensischen Report eines Vorfalls mit Prozessbaum, Datei- und Netzwerkaktivität exportieren, und in welchem Format? Kann ich das selbst, oder hänge ich von Ihrem Support ab?
Die Falle
Viele Vendoren werben mit "NIS2-ready", ohne dass das Reporting die 24-Stunden-Frist in der Praxis unterstützt, und die Telemetrie-Aufbewahrung in der Grundstufe ist oft kürzer als die Zeit, die ein Angreifer im Netz sitzt. Das merkst du mitten im ersten echten Vorfall, im denkbar schlechtesten Moment.
Kriterium 14
API- & Automatisierungsunterstützung (SOAR-Integration)
Warum es zählt
Alles, was du rund um das EDR automatisieren willst, von der Ticketerstellung über die Anreicherung bis zum SOAR-Playbook, das einen Host isoliert und das Konto sperrt, läuft über seine API. Eine API, die limitiert, unvollständig oder undokumentiert ist, macht jede Automatisierung zum Support-Ticket, und die Reaktion, die du automatisieren wolltest, bleibt manuell.
Was du fragst
Bitte um die API-Dokumentation und prüfe, ob jede Aktion der Konsole auch über die API verfügbar ist, welche Rate-Limits gelten, ob es vom Vendor gepflegte Integrationen für deine SOAR- oder Ticketing-Plattform gibt, und wie API-Änderungen angekündigt und versioniert werden.
Die Falle
"Vollständige REST-API" deckt oft das Lesen von Alarmen ab und wenig mehr; die Eindämmungsmaßnahmen, um die es dir geht, gibt es womöglich nur in der Konsole oder in einer höheren Stufe. Teste im Pilot die zwei Automatisierungen, die du wirklich bauen willst, nicht die API-Referenz.
Kriterium 15
Abdeckung von Cloud-Workloads & Containern
Warum es zählt
Ein wachsender Teil deiner Workloads läuft als Cloud-Instanz, Container und Serverless-Funktion, die ein klassischer Endpunkt-Agent nie sieht. Hört das EDR bei der virtuellen Maschine auf, liegen die Systeme, die deine Daten in der Cloud halten, außerhalb der Erkennung, und dasselbe gilt für den Kubernetes-Cluster, den deine Entwickler letztes Jahr aufgesetzt haben.
Was du fragst
Frag, welche Cloud-Plattformen, Container-Runtimes und Kubernetes-Distributionen abgedeckt sind, wie (Agent, Sidecar, agentenlos), ob Container-Images und laufende Container beide im Umfang sind, und wie eine Erkennung auf einem kurzlebigen Container aussieht, wenn der Container schon weg ist.
Die Falle
"Cloud Workload Protection" ist häufig ein eigenes Produkt mit eigener Lizenz und eigener Konsole, gebündelt auf der Preisliste und nicht in der Plattform. Frag, ob Cloud- und Endpunkt-Alarme im selben Vorfall landen, und bepreise beides, wenn nicht.
Wirtschaftlichkeit & Compliance
Kriterium 16
Lizenzierung pro Endpoint (3-Jahres-TCO)
Warum es zählt
Der Preis pro Endpunkt ist nur ein Teil der Kosten. Der volle Plattformwert braucht oft höhere Preisstufen, Zusatzmodule und den MDR-Service. Die Zahl im ersten Angebot und die Zahl, die du im zweiten Jahr zahlst, liegen häufig weit auseinander.
Was du fragst
Bitte um die vollen Kosten über drei Jahre inklusive aller Module, die du tatsächlich brauchst, um Preisdeckel bei der Verlängerung, und um eine Liste dessen, was im Grundpreis ausdrücklich nicht enthalten ist.
Die Falle
Der attraktive Einstiegspreis schließt oft genau die Funktionen aus, die dein Interesse überhaupt geweckt haben. Kalkuliere die Konfiguration, die du wirklich betreiben wirst, nicht die Grundstufe, die im Vergleich gut aussieht.
Kriterium 17
SOC-2- / ISO-27001- / DSGVO-Compliance
Warum es zählt
EDR-Tools sammeln enorme Mengen Telemetrie von deinen Endpunkten, darunter Benutzernamen, Dateinamen und Kommandozeilen. Wo diese Daten verarbeitet und gespeichert werden, hat direkte Folgen unter der DSGVO, und für eine regulierte Organisation sind die eigenen Nachweise des Vendors (SOC 2, ISO 27001) das, was in die Lieferantenakte kommt. Ein Vendor mit Sitz in den USA leitet Telemetrie unter Umständen über US-Infrastruktur, und das erzeugt Schrems-II-Risiko.
Was du fragst
Bitte um den aktuellen SOC-2-Typ-II-Bericht und das ISO-27001-Zertifikat mit Scope, und frag dann konkret: Gibt es eine reine EU-Verarbeitungsregion, ist sie Standard oder ein Upgrade, und kann der Vendor vertraglich garantieren, dass keine Telemetrie die EU verlässt, auch nicht für Support und Analyse?
Die Falle
"EU-Region verfügbar" heißt oft: verfügbar in einer höheren Preisstufe, oder verfügbar für die Speicherung, aber nicht für das Support-Team, das weiterhin von überall auf deine Daten zugreifen kann. Residenz der Speicherung ist nicht Residenz des Zugriffs. Und ein Zertifikat deckt die Services und Standorte seiner Scope-Erklärung ab, und die Region, die du kaufst, muss nicht darin stehen.
Kriterium 18
Support-SLA des Anbieters & Incident Response
Warum es zählt
Wenn der Agent ein Produktionssystem lahmlegt oder die Konsole während eines Vorfalls ausfällt, ist der Support des Vendors Teil deiner Incident Response. Das Support-SLA entscheidet, ob du binnen einer Stunde einen Engineer bekommst oder binnen eines Tages eine Ticketnummer, und ob das Incident-Response-Team des Vendors hinzugezogen werden kann, wenn deine Untersuchung deine Kapazität übersteigt.
Was du fragst
Frag nach den vertraglichen Reaktions- und Lösungszeiten pro Schweregrad in der Stufe, die du kaufst, ob 24/7-Support mit benanntem Eskalationsweg enthalten ist, und welche Incident-Response-Leistungen (Retainer, stundenweise, inkludierte Stunden) der Vendor zu welchem Preis anbietet.
Die Falle
"24/7-Support" heißt oft: ein Portal, das rund um die Uhr Tickets annimmt, mit Engineers in einer Zeitzone. Frag einen Referenzkunden, wie lange sein letztes kritisches Ticket bis zu einem Menschen brauchte, und ob der Incident-Response-Retainer nachträglich separat gekauft werden musste.
Kriterium 19
Anbieterabhängigkeit & Datenportabilität
Warum es zählt
Ein EDR-Wechsel heißt, auf jedem Endpunkt einen Agenten neu auszurollen und die Telemetrie-Historie, die getunten Ausnahmen und die eigenen Erkennungsanpassungen zu verlieren. Diese Wechselkosten sind es, die dem Vendor Preiserhöhungen bei der Verlängerung erlauben. Unter DORA wird für kritische IKT-Dienste eine Exit-Strategie erwartet; unter NIS2 ist sie schlicht das, was dich aus einer starken Position verhandeln lässt.
Was du fragst
Frag, wie Telemetrie, Vorfälle, Ausnahmen und eigene Regeln in einem offenen Format exportiert werden können, ob historische Daten nach Vertragsende zugänglich bleiben, was der Vendor zur Unterstützung einer Migration anbietet, und wie die Agent-Entfernung im großen Maßstab aussieht.
Die Falle
"Offene Plattform" für die Datenaufnahme, proprietär für alles, was du darauf gebaut hast. Und die Telemetrie, für deren Sammlung du drei Jahre bezahlt hast, wird mit dem Tenant gelöscht. Bepreise den Exit vor der Unterschrift, und behalte eine Kopie dessen, was du brauchst, um einen alten Vorfall zu belegen.
Kriterium 20
Abstimmung von Roadmap & Bedrohungslage
Warum es zählt
Du kaufst ein EDR für drei Jahre, und die Bedrohungslage ändert sich jedes Quartal. Ob der Vendor in die Techniken investiert, die für dich zählen, von identitätsbasierten Einbrüchen über Living-off-the-Land bis zu Cloud-Pivots, entscheidet, ob das Tool die Angriffe des dritten Jahres noch erkennt. Eine Roadmap ist auch ein Signal dafür, ob es den Vendor bis dahin noch eigenständig gibt.
Was du fragst
Bitte um die Zwölfmonats-Roadmap unter NDA und prüfe sie gegen die Angriffstechniken in deinem eigenen Bedrohungsmodell, frag, welche Roadmap-Punkte des letzten Jahres tatsächlich ausgeliefert wurden, und frag, wie das Research-Team des Vendors veröffentlicht und wie schnell neue Techniken zu Erkennungen werden.
Die Falle
Roadmap-Folien sind Absichten mit Datum. Der brauchbare Nachweis ist die Lieferbilanz: was vor achtzehn Monaten versprochen wurde und was heute im Produkt ist. Und eine Roadmap voller KI-Funktionen sagt wenig darüber, ob der Linux-Agent je Verhaltenserkennung bekommt.
Preis
Kriterium 21
Passung des Preismodells
Warum es zählt
EDR wird pro Endpunkt, pro Nutzer, pro Server oder in Bündeln lizenziert, die alle drei mischen, und derselbe Bestand kostet unter jedem Modell sehr unterschiedlich. Virtuelle Desktops, geteilte Fertigungsrechner, Server, die hoch- und runterskalieren, und Externe mit je zwei Geräten sprengen die Annahmen hinter einem Preis pro Endpunkt oder pro Nutzer.
Was du fragst
Beschreib deinen Bestand ehrlich (Endpunkte, Server, virtuelle Desktops, Cloud-Instanzen, Nutzer mit mehreren Geräten) und lass den Vendor ihn unter jedem angebotenen Modell bepreisen, und frag dann, was als Endpunkt zählt, wenn eine virtuelle Maschine eine Stunde lang existiert.
Die Falle
Das Modell, das die Vergleichstabelle gewinnt, ist das, dessen Zähleinheit in deinem heutigen Bestand am kleinsten ist. Frag, wie gezählt wird, wie oft nachgezählt wird und was passiert, wenn sich deine Serverflotte für ein Migrationswochenende verdoppelt.
Kriterium 22
Preisplanbarkeit & versteckte Kosten
Warum es zählt
Das Angebot deckt Jahr eins beim heutigen Endpunktbestand. Die Kosten, die überraschen, kommen später: Telemetrie-Aufbewahrung über das Grundfenster hinaus, Exportgebühren, das Modul, das für die Integration doch nötig war, die Preiserhöhung bei der Verlängerung, und die Professional Services für den Rollout, die niemand einzeln ausgewiesen hat.
Was du fragst
Bitte um eine schriftliche Liste von allem, was über die Lizenz hinaus Kosten erzeugen kann: Aufbewahrungsstufen, Export- und API-Nutzung, Zusatzmodule, Support-Stufen, Onboarding-Services und die maximale Preiserhöhung bei Verlängerung. Frag einen Referenzkunden, wie seine Rechnung im zweiten Jahr gegen das erste Angebot aussah.
Die Falle
"Alles inklusive" bis die Rechnung für die verlängerte Aufbewahrung kommt, und das ist genau die Aufbewahrung, die du für eine forensische Untersuchung brauchst. Kann der Vendor die möglichen Zusatzkosten nicht auflisten, nimm an, dass es mehr sind, als dir gesagt wurde.
Kriterium 23
Angebotener Lizenzpreis
Warum es zählt
Am Ende braucht die Entscheidung eine Zahl pro Vendor, die sich vergleichen lässt: den angebotenen Lizenzpreis für die Konfiguration, die du wirklich betreiben wirst, über die Laufzeit, die du wirklich unterschreibst. Jedes andere Kriterium in diesem Katalog fließt ein, wie viel diese Zahl wert ist; dieses sorgt dafür, dass sie existiert und vergleichbar ist.
Was du fragst
Bitte jeden Vendor um ein verbindliches schriftliches Angebot für denselben Umfang: Endpunkt- und Serverzahl, die in den Kriterien oben identifizierten Module und Stufen, Aufbewahrung, Support-Stufe, Onboarding und Laufzeit, mit Jahrespreis und Dreijahressumme getrennt ausgewiesen.
Die Falle
Angebote mit unterschiedlichem Umfang lassen sich nicht vergleichen, und Vendoren wissen das. Ein Angebot enthält MDR, das nächste schließt die Aufbewahrung aus, das dritte rechnet pro Nutzer. Gleiche den Umfang ab, bevor du die Zahl vergleichst, sonst ist das günstigste Angebot das, das am meisten weggelassen hat.
Welche Pflicht welches Kriterium abdeckt
Die Regulatorik-Karte dieses Katalogs: die Pflicht, ihre Quelle und die Kriterien, die sie abdecken. Damit zeigst du dem Auditor, dass die Anforderungsliste aus den Regeln kommt, nicht aus einer Anbieterpräsentation.
| Pflicht | Quelle | Abgedeckt durch |
|---|---|---|
| Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats nach einem erheblichen Vorfall | NIS2 Art. 23 | |
| Bewältigung von Sicherheitsvorfällen als Risikomanagementmaßnahme, einschließlich Erkennungs- und Reaktionsfähigkeit | NIS2 Art. 21(2)(b) | |
| Sicherheit der Lieferkette, einschließlich der sicherheitsrelevanten Aspekte der Beziehungen zu Anbietern und Dienstleistern | NIS2 Art. 21(2)(d) | |
| Leitungsorgane billigen und überwachen die Risikomanagementmaßnahmen und haften dafür | NIS2 Art. 20 | |
| Vertragliche Vereinbarungen mit IKT-Drittdienstleistern, einschließlich Leistungsbeschreibung, Datenstandorten und Zugriffsrechten | DORA Art. 30 | |
| Management des IKT-Drittparteienrisikos, Informationsregister und Exit-Strategien | DORA Art. 28 | |
| Meldung schwerwiegender IKT-bezogener Vorfälle an die zuständige Behörde | DORA Art. 19 | |
| Auftragsverarbeitungsvertrag und rechtmäßige Drittlandübermittlung personenbezogener Daten in der Endpunkt-Telemetrie | GDPR Art. 28 and Art. 44 ff. |
Der Fragebogen
Alle Anbieterfragen dieses Katalogs in einer Liste, in der Reihenfolge der Kriterien. Stell jedem Anbieter dieselben Fragen im selben Wortlaut und schreib die Antworten nebeneinander.
- Erkennungsgenauigkeit (MITRE-ATT&CK-Abdeckung)
Bitte um die Ergebnisse aus der aktuellsten MITRE ATT&CK Enterprise Evaluation, konkret die Detection Coverage und die Zahl der verpassten Erkennungen. Nicht die Pressemitteilung, die echten Ergebnisse.
- Mean Time to Detect (MTTD)
Frag nach der gemessenen Median- und Worst-Case-Zeit von der ersten Ausführung bis zum Alarm für die Techniken der letzten MITRE-Evaluation, und ob der Alarm beim Erstzugriff, bei der Rechteausweitung oder erst beim Schaden auslöst. Frag einen Referenzkunden nach derselben Zahl aus einem echten Vorfall.
- Mean Time to Respond (MTTR)
Frag nach der Zeit vom Alarm bis zur ausgeführten Eindämmung in den Messungen des Vendors und im Vorfall eines Referenzkunden, und lass in der Demo bei laufender Uhr einen Host isolieren. Frag, ob Reaktionsmaßnahmen auch funktionieren, wenn der Endpunkt nicht im Firmennetz ist.
- Automatisierte Reaktion / Behebung
Frag, welche Eindämmungsmaßnahmen das Produkt pro Plattform automatisch ausführen kann, unter welchen Bedingungen, und wie eine falsche automatische Isolation eines Produktionsservers zurückgenommen wird. Lass in der Demo eine Isolation auslösen und den Endpunkt danach wieder anbinden.
- False-Positive-Rate
Bitte um einen Referenzkunden ähnlicher Größe und Branche, und frag diesen Kunden direkt, wie viele False Positives er pro Woche bearbeitet und wie das Tuning in den ersten drei Monaten lief.
- Betriebssystem- & Plattformabdeckung (Windows, Linux, macOS)
Gib dem Vendor dein echtes OS-Inventar inklusive Versionen und End-of-Life-Systemen und frag pro Zeile, ob der Agent mit denselben Erkennungs- und Reaktionsfunktionen wie auf aktuellem Windows unterstützt wird, mit reduziertem Umfang, oder gar nicht.
- Rollout-Komplexität & Einführungsaufwand
Bitte um den Rollout-Plan für deinen echten Bestand: Agent-Paketierung für deine Management-Tools, Verhalten auf Rechnern ohne dauerhafte Verbindung, Koexistenz mit dem Antivirus, das du ablöst, und die Personentage, die ein vergleichbarer Kunde bis 95 Prozent Abdeckung brauchte.
- Performance-Einfluss des Agents (CPU/RAM)
Bitte um gemessene CPU- und Speicherlast unter normaler Nutzung, und fahr vor der Entscheidung einen Pilot auf echten Rechnern echter Nutzer. Nicht auf sauberen Testmaschinen.
- MDR- / Managed-Detection-and-Response-Option
Frag nach der garantierten Reaktionszeit auf einen kritischen Alarm am Sonntag um drei Uhr nachts, und ob diese Zeit vertraglich bindend ist oder ein Best-Effort-Ziel.
- XDR- / Extended-Detection-Fähigkeit
Frag, welche deiner Nicht-Endpunkt-Quellen die Plattform nativ einliest und zu einem einzigen Vorfall korreliert, ob diese Korrelation vom Vendor gepflegte Logik ist oder eine Suche, die du schreibst, und lass dir einen domänenübergreifenden Vorfall aus einem echten Tenant zeigen, nicht aus einem Demo-Datensatz.
- SIEM-Integration & Log-Weiterleitung
Bitte um eine Liste der nativen Integrationen für deinen konkreten Stack, ob die volle Telemetrie oder nur Alarme weitergeleitet werden, in welchem Schema und zu welchen Kosten, und ob der Vendor sie pflegt oder du. Lass dir die Integration in der Demo zeigen, nicht nur auf einer Folie auflisten.
- Qualität der Threat-Intelligence-Feeds
Frag, woher die Intelligence kommt, wie schnell die Indikatoren einer neuen Kampagne deinen Tenant erreichen, ob branchen- und regionsspezifische Intelligence (etwa zu Gruppen, die europäische kritische Infrastruktur angreifen) enthalten ist, und ob du eigene Feeds und die deines CERT ergänzen kannst.
- Forensik- & Untersuchungsfähigkeit
Frag nicht "sind Sie NIS2-konform", das bejahen alle. Frag konkret: Wie weit reicht die Endpunkt-Telemetrie zurück, wie schnell kann ich einen vollständigen forensischen Report eines Vorfalls mit Prozessbaum, Datei- und Netzwerkaktivität exportieren, und in welchem Format? Kann ich das selbst, oder hänge ich von Ihrem Support ab?
- API- & Automatisierungsunterstützung (SOAR-Integration)
Bitte um die API-Dokumentation und prüfe, ob jede Aktion der Konsole auch über die API verfügbar ist, welche Rate-Limits gelten, ob es vom Vendor gepflegte Integrationen für deine SOAR- oder Ticketing-Plattform gibt, und wie API-Änderungen angekündigt und versioniert werden.
- Abdeckung von Cloud-Workloads & Containern
Frag, welche Cloud-Plattformen, Container-Runtimes und Kubernetes-Distributionen abgedeckt sind, wie (Agent, Sidecar, agentenlos), ob Container-Images und laufende Container beide im Umfang sind, und wie eine Erkennung auf einem kurzlebigen Container aussieht, wenn der Container schon weg ist.
- Lizenzierung pro Endpoint (3-Jahres-TCO)
Bitte um die vollen Kosten über drei Jahre inklusive aller Module, die du tatsächlich brauchst, um Preisdeckel bei der Verlängerung, und um eine Liste dessen, was im Grundpreis ausdrücklich nicht enthalten ist.
- SOC-2- / ISO-27001- / DSGVO-Compliance
Bitte um den aktuellen SOC-2-Typ-II-Bericht und das ISO-27001-Zertifikat mit Scope, und frag dann konkret: Gibt es eine reine EU-Verarbeitungsregion, ist sie Standard oder ein Upgrade, und kann der Vendor vertraglich garantieren, dass keine Telemetrie die EU verlässt, auch nicht für Support und Analyse?
- Support-SLA des Anbieters & Incident Response
Frag nach den vertraglichen Reaktions- und Lösungszeiten pro Schweregrad in der Stufe, die du kaufst, ob 24/7-Support mit benanntem Eskalationsweg enthalten ist, und welche Incident-Response-Leistungen (Retainer, stundenweise, inkludierte Stunden) der Vendor zu welchem Preis anbietet.
- Anbieterabhängigkeit & Datenportabilität
Frag, wie Telemetrie, Vorfälle, Ausnahmen und eigene Regeln in einem offenen Format exportiert werden können, ob historische Daten nach Vertragsende zugänglich bleiben, was der Vendor zur Unterstützung einer Migration anbietet, und wie die Agent-Entfernung im großen Maßstab aussieht.
- Abstimmung von Roadmap & Bedrohungslage
Bitte um die Zwölfmonats-Roadmap unter NDA und prüfe sie gegen die Angriffstechniken in deinem eigenen Bedrohungsmodell, frag, welche Roadmap-Punkte des letzten Jahres tatsächlich ausgeliefert wurden, und frag, wie das Research-Team des Vendors veröffentlicht und wie schnell neue Techniken zu Erkennungen werden.
- Passung des Preismodells
Beschreib deinen Bestand ehrlich (Endpunkte, Server, virtuelle Desktops, Cloud-Instanzen, Nutzer mit mehreren Geräten) und lass den Vendor ihn unter jedem angebotenen Modell bepreisen, und frag dann, was als Endpunkt zählt, wenn eine virtuelle Maschine eine Stunde lang existiert.
- Preisplanbarkeit & versteckte Kosten
Bitte um eine schriftliche Liste von allem, was über die Lizenz hinaus Kosten erzeugen kann: Aufbewahrungsstufen, Export- und API-Nutzung, Zusatzmodule, Support-Stufen, Onboarding-Services und die maximale Preiserhöhung bei Verlängerung. Frag einen Referenzkunden, wie seine Rechnung im zweiten Jahr gegen das erste Angebot aussah.
- Angebotener Lizenzpreis
Bitte jeden Vendor um ein verbindliches schriftliches Angebot für denselben Umfang: Endpunkt- und Serverzahl, die in den Kriterien oben identifizierten Module und Stufen, Aufbewahrung, Support-Stufe, Onboarding und Laufzeit, mit Jahrespreis und Dreijahressumme getrennt ausgewiesen.
Diese Kriterien sind der Anfang. Nicht die Entscheidung.
Eine Kriterienliste sagt dir, worauf du schauen musst. Sie gewichtet die Kriterien nicht gegen deine Situation, prüft sie nicht gegen deine harten Grenzen und macht kein Memo daraus, das dein Vorstand und dein Auditor lesen können. DecisionOS nimmt diese Kriterien, gewichtet sie für deine Entscheidung und baut daraus eine belastbare Akte. In Tagen, nicht Monaten.
Weiter mit dem Entscheidungs-Guide
Verwandte Kriterienkataloge
- Security Information and Event ManagementSIEM-Auswahl: die Kriterien, die unter NIS2 und DORA zählen23 Kriterien
- Managed Detection and ResponseMDR-Auswahl: die Kriterien, die unter NIS2 und DORA zählen23 Kriterien
- Identity and Access ManagementIAM-Auswahl: die Kriterien, die unter NIS2 und DORA zählen23 Kriterien
Diesen Katalog drucken oder als PDF fürs Meeting sichern