nexalign
EnglishDeutsch

Kriterienkatalog · Managed Detection and Response

MDR-Auswahl: die Kriterien, die unter NIS2 und DORA zählen

Die meisten MDR-Bewertungen vergleichen Dashboards und einen Preis pro Endpunkt. Entscheidend ist, wozu der Anbieter in der ersten Stunde eines Vorfalls vertraglich verpflichtet ist, wer dabei auf deine Daten schaut, und ob der Vertrag ein DORA- oder NIS2-Audit übersteht.

Unabhängige Kriterienreferenz · 23 Kriterien · Stand August 2026 · Von keinem Anbieter gesponsert

Ein MDR-Vertrag gibt den zeitkritischsten Teil deiner Sicherheit an einen Dritten. Unter NIS2 bleibst du für die 24-Stunden-Frühwarnung verantwortlich. Unter DORA ist der Anbieter ein IKT-Drittdienstleister, meist für eine kritische oder wichtige Funktion, und damit gelten die Vertragsmindestinhalte der Artikel 28 bis 30. Die Kriterien unten sind die, die DecisionOS für einen Managed-Security-Fall auf den Bewertungsbogen setzt, in derselben Reihenfolge und Gruppierung, damit du hier prüfst, was du dort bewertest.

Service-Fähigkeiten


Kriterium 01

24/7-SOC-Abdeckung & Analysten-Tiefe (dediziert vs. geteilt, Tier-Struktur)

Warum es zählt

Du kaufst MDR, damit am Sonntag um drei Uhr nachts jemand Kompetentes hinschaut. Ob dieser Jemand ein dedizierter Analyst ist, der deine Umgebung kennt, oder eine geteilte Tier-1-Warteschlange nach Runbook, und ob es in der Nachtschicht überhaupt einen Tier-3-Engineer gibt, entscheidet, was in der ersten Stunde eines echten Vorfalls passiert. Die Besetzung des SOC ist das Produkt.

Was du fragst

Frag nach der Zahl der Analysten pro Schicht und pro Tier, dem Verhältnis von Analysten zu Kunden, ob dein Tenant benannte Analysten hat, die deine Umgebung kennen, wo Tier-3- und Incident-Response-Fähigkeit nachts und am Wochenende sitzt, und nach dem Schichtplan einer typischen Woche.

Die Falle

"24/7-SOC" heißt oft: ein Portal, das rund um die Uhr Alarme annimmt, und ein Tier-1-Team, das am Morgen an einen Bereitschafts-Engineer eskaliert. Frag, wer genau letzten Sonntag um drei Uhr nachts gearbeitet hat und wozu er befugt war.

Kriterium 02

Vertragliche MTTD- / MTTR-SLA-Zusage & historische Performance

Warum es zählt

MDR wird über Geschwindigkeit verkauft, aber "Reaktion in Minuten" auf der Website ist keine Zusage. Es geht um drei getrennte Uhren im Vertrag: Zeit bis zur Erkennung, Zeit bis ein Mensch den Alarm triagiert und eingestuft hat, und Zeit bis die Eindämmung begonnen hat. Jede dieser Uhren braucht eine Zahl, eine Schweregradstufe, für die sie gilt, und eine Folge, wenn sie gerissen wird, und die historische Leistung des Anbieters sagt dir, ob die Zahl echt ist.

Was du fragst

Bitte um die Vertragsklausel, die Time to Detect, Time to Triage und Time to Contain für einen kritischen Vorfall definiert, mit Messbeginn, garantiertem Wert und Service Credit oder Kündigungsrecht bei Verfehlung. Dann bitte um die tatsächlich gemessenen Werte der letzten zwölf Monate bei bestehenden Kunden.

Die Falle

"Mean Time to Respond unter 15 Minuten" ist ein Durchschnitt über alle Alarme, größtenteils niedrige Schweregrade, die automatisch geschlossen werden. Die Zahl, die dich interessiert, ist der schlechteste Fall bei einem kritischen Alarm in der Nacht, und darüber sagt ein Mittelwert nichts. Enthält der Vertrag nur Durchschnitte oder Zielwerte, enthält er nichts.

Kriterium 03

Frequenz & Methodik des proaktiven Threat Huntings

Warum es zählt

Echtes Threat Hunting heißt: Ein Mensch bildet eine Hypothese über deine Umgebung und sucht in den Daten danach. Viele Services etikettieren automatisierte Alarm-Triage als Hunting um. Der Unterschied zählt, weil die Angriffe, die wehtun, genau die sind, bei denen keine Regel angeschlagen hat, und nur Hunting findet die.

Was du fragst

Frag, wie viele Hunting-Stunden pro Monat deinem Tenant zugeordnet sind, wer sie leistet, und bitte um die letzten drei schriftlichen Hunt-Reports für einen vergleichbaren Kunden, inklusive der geprüften Hypothesen und dessen, was gefunden wurde.

Die Falle

"Kontinuierliches, KI-gestütztes Threat Hunting" ist meist eine Detection-Engine mit neuem Etikett. Ein Anbieter, der dir keinen Hunt-Report mit Hypothese, Query und Ergebnis zeigen kann, huntet nicht. Er leitet Alarme weiter, und das ist in Ordnung, solange du dafür keine Hunting-Preise zahlst.

Kriterium 04

Flexibilität des Co-Managed-Modells & Kundeneinblick (Portal-Transparenz)

Warum es zählt

Dein eigenes Team verschwindet nicht, wenn du MDR kaufst; es muss mit den Analysten des Anbieters arbeiten, sehen, was sie sehen, und Teile der Arbeit übernehmen, wenn es sinnvoll ist. Ein Anbieter, dessen Portal eine Liste geschlossener Tickets und sonst nichts zeigt, macht dein Team zum Empfänger von Schlussfolgerungen, und unter NIS2 muss die Geschäftsleitung trotzdem eine Maßnahme überwachen, in die sie nicht hineinschauen kann.

Was du fragst

Frag, ob deine Analysten die Rohtelemetrie, die Detection-Regeln und die Analystennotizen zu jedem Fall in derselben Konsole sehen, die der Anbieter nutzt, ob du eigene Abfragen und Hunts auf deinen Daten fahren kannst, und wie die Aufgabenteilung während der Laufzeit verändert werden kann, wenn dein Team wächst.

Die Falle

"Portal mit voller Transparenz" heißt oft: ein Dashboard mit Zahlen und eine Ticketliste, während die eigentlichen Daten und Regeln im internen Tooling des Anbieters bleiben. Bitte um einen Login in das Portal eines echten Kunden, geschwärzt, und versuch, einen Vorfall aus dem zu rekonstruieren, was du siehst.

Kriterium 05

Integrierte IR-Fähigkeit (Retainer inklusive vs. Zusatzkosten)

Warum es zählt

Das R in MDR reicht von "wir schicken einen Alarm mit Empfehlung" bis "wir isolieren den Host, sperren das Konto und blocken den Hash, ohne auf dich zu warten", und jenseits der Eindämmung liegt die eigentliche Incident Response: Forensik, Beseitigung, Wiederherstellungsunterstützung und der schriftliche Bericht, den deine Aufsicht will. Ob das enthalten ist, in einem Retainer mit vorbezahlten Stunden oder zu Notfalltarifen berechnet wird, wenn du es am dringendsten brauchst, entscheidet die echten Kosten deines schlimmsten Tages.

Was du fragst

Bitte um die Liste der Eindämmungsmaßnahmen, die der Anbieter ohne vorherigen Anruf auf deinen Systemen ausführen darf, die Liste derer, die deine Freigabe brauchen, und den Weg, wie diese Freigabe um drei Uhr nachts eingeholt wird. Frag dann, welche Incident Response über die Eindämmung hinaus enthalten ist, wie viele Stunden, zu welchem Tarif darüber hinaus, und wie schnell ein IR-Engineer vor Ort oder online ist.

Die Falle

"Guided Response" und "Response-Empfehlungen" heißen: Der Anbieter handelt nicht. Und "integrierte IR" kann eine Notfall-Hotline sein, die dich mit einem Partner zu einem vierstelligen Tagessatz verbindet. Bitte um die Vorab-Freigabematrix und die IR-Preisliste eines echten Kunden, keine Vorlage.

Technologie-Stack & Abdeckung


Kriterium 06

Technologie-Agnostik vs. Lock-in-Risiko durch proprietären Stack

Warum es zählt

Manche MDR-Anbieter überwachen, welches EDR, SIEM und welche Cloud du ohnehin betreibst. Andere liefern den vollen Service nur auf dem eigenen Stack und behandeln alles andere als Log-Feed. Das zweite Modell kann heißen, Tools zu ersetzen, die du vor zwei Jahren gekauft hast, und es koppelt den Ausstieg aus dem Service an den Ausstieg aus dem Tooling, was die Wechselkosten verdoppelt, die DORA dich planen lässt.

Was du fragst

Liste dein aktuelles EDR, SIEM, deinen Identity Provider und deine Cloud-Plattformen auf und frag pro Eintrag, ob der Anbieter darauf Erkennung, Reaktionsmaßnahmen und das volle SLA liefert, oder ob das SLA nur für den eigenen Agenten gilt. Frag, was mit dem Service passiert, wenn du eines dieser Tools während der Laufzeit ersetzt.

Die Falle

"Wir unterstützen alle führenden EDR-Plattformen" heißt oft: Die Alarme werden weitergeleitet, während Hunting, Eindämmung und das Response-SLA nur für den eigenen Agenten gelten. Lies die Klausel zum SLA-Umfang, nicht die Integrationsseite.

Kriterium 07

EDR- / SIEM-Abdeckung & Integrationsqualität bestehender Tools

Warum es zählt

Die meisten MDR-Services sind aus einem EDR-Produkt entstanden und sehen die Welt durch den Endpunkt-Agenten. Moderne Einbrüche beginnen mit einer gestohlenen Identität, einer falsch konfigurierten Cloud-Rolle oder einer VPN-Appliance, und auf keinem davon läuft ein Agent. Ob der Anbieter dein bestehendes EDR und SIEM in voller Tiefe einliest, Detections für diese Quellen schreibt und Analysten hat, die tatsächlich hineinschauen, entscheidet, ob der Angriff früh gesehen wird oder erst, wenn der Angreifer hat, was er wollte.

Was du fragst

Frag, welche deiner tatsächlichen Quellen eingebunden und von Analysten überwacht werden, nicht nur gesammelt: dein EDR, dein SIEM, Identity-Provider-Logs, E-Mail, Netzwerk und Firewall, SaaS-Audit-Logs. Frag pro Quelle, ob Detection-Regeln existieren, wer sie pflegt, und wie die Integration gebaut wurde und in Betrieb gehalten wird.

Die Falle

"Integriert über 200 Quellen" heißt: Konnektoren existieren. Es heißt nicht, dass jemand Detections dafür schreibt oder ein Analyst hineinschaut. Bitte um die Zahl der Detection-Regeln pro Quelle auf deinem Tenant nach dem Onboarding, und vergleich sie mit der Zahl der Endpunkt-Regeln.

Kriterium 08

Cloud-native & Multi-Cloud-Abdeckung (AWS, Azure, GCP)

Warum es zählt

Ein wachsender Teil dessen, was ein Angreifer will, liegt in der Cloud-Steuerungsebene: Identitätsrollen, Storage-Buckets, Serverless-Funktionen und die Audit-Trails, die festhalten, wer sie angefasst hat. Ein MDR, das Endpunkte beobachtet und Cloud-Logs ungelesen weiterleitet, verpasst die falsch konfigurierte Rolle, die eine Datenbank freigelegt hat, und zwar in jeder Cloud, die du betreibst, nicht nur in der, die das eigene Produkt des Anbieters unterstützt.

Was du fragst

Frag, welche Cloud-Plattformen von Analysten mit cloud-spezifischen Detections überwacht werden, ob Signale aus Steuerungsebene, Identität und Workloads mit Endpunkt-Aktivität in einem Vorfall korreliert werden, wie ein Cloud-Vorfall eingedämmt wird (Rollenentzug, Schlüsselrotation, Instanz-Isolation) und von wem, und wie die Abdeckung für die zweite und dritte Cloud aussieht, die du betreibst.

Die Falle

"Multi-Cloud-Abdeckung" heißt häufig: Das Cloud-Security-Produkt des Anbieters gibt es für eine Cloud, die anderen sind Logquellen. Frag nach der Zahl der Detection-Regeln und den Eindämmungsmaßnahmen pro Cloud, und nach einem Cloud-Vorfallsbericht eines echten Kunden.

Kriterium 09

OT- / IoT-Abdeckungsoption (industrielle Umgebungen)

Warum es zählt

Betreibst du Produktionsanlagen, geht der Angriff, der das Geschäft stoppt, durch das OT-Netz, und ein Analyst, der an Windows-Prozessbäumen ausgebildet ist, weiß nicht, wie ein verdächtiger Modbus-Schreibzugriff aussieht. OT-Monitoring ist passiv, protokollbewusst und kann eine SPS nicht so isolieren wie einen Laptop, also muss die OT-Option des Anbieters ein anderer Service mit anderen Menschen sein, nicht dasselbe SOC mit einer weiteren Logquelle.

Was du fragst

Frag, ob OT- und IoT-Monitoring eine echte Servicelinie mit dedizierten Analysten mit Industrieerfahrung ist, welche OT-Protokolle und Sensoren unterstützt werden, wie ein OT-Vorfall eingedämmt wird, ohne die Produktion zu stoppen, und nach einem Referenzkunden mit Anlagen deiner Art.

Die Falle

"OT-Sichtbarkeit" heißt oft: Der Anbieter liest Alarme aus einem OT-Monitoring-Produkt ein, das du selbst kaufen und betreiben musst, und eskaliert sie an dich. Hat der Analyst in der Nachtschicht nie eine Anlage gesehen, ist die OT-Option ein Log-Forwarder mit Premium-Preis.

Kriterium 10

Geografischer SOC-Standort & Data Residency (Option für reines EU-SOC)

Warum es zählt

Ein MDR-Analyst sieht Prozessbäume, Benutzernamen, Dateinamen und manchmal Dateiinhalte aus deinen Systemen. Wo dieser Analyst sitzt, zählt unter der DSGVO und bei regulierten Workloads unter NIS2 und DORA. Ein Follow-the-Sun-Modell heißt, deine Nachtschicht wird von einem anderen Kontinent aus bearbeitet, und das ist Zugriff auf personenbezogene Daten von außerhalb der EU, egal wo die Daten gespeichert sind.

Was du fragst

Frag, wo die Analysten, die deine Alarme bearbeiten, physisch sitzen, pro Schicht, und ob der Vertrag reinen EU-Analystenzugriff garantiert. Frag, was aus dieser Garantie bei einer Eskalation oder einem Großvorfall wird, wenn zusätzliches Personal hinzugezogen wird, und wo Data Lake und Backups liegen.

Die Falle

"Daten werden in der EU gespeichert" beantwortet die Frage nach dem Data Lake, nicht die nach den Menschen. Residenz der Speicherung ist nicht Residenz des Zugriffs. Ein SOC mit EU-Rechenzentrum und Analysten, die sich von drei Kontinenten einloggen, hat die Speicherfrage gelöst und nicht die, die du gestellt hast.

Betrieb & Governance


Kriterium 11

SOC-Reifegrad (SOC-CMM- / CMMI-Zertifizierung oder gleichwertig)

Warum es zählt

Ein SOC ist eine Prozessorganisation, und seine Reife zeigt sich daran, ob Verfahren dokumentiert, gemessen und verbessert werden oder ob alles an den zwei Senior-Analysten hängt, die gehen könnten. SOC-CMM, eine Bewertung nach CMMI-Art oder ein gleichwertiges unabhängiges Review ist das Nächste an einem Nachweis, dass das SOC im achtzehnten Monat genauso arbeitet wie in der Verkaufsdemo.

Was du fragst

Bitte um die letzte unabhängige Reifegradbewertung des SOC mit Scope und Befunden, frag, wie Detection Engineering, Vorfallsbearbeitung und Qualitätsreview dokumentiert und gemessen werden, wie hoch die Analystenfluktuation im letzten Jahr war, und wie ein neuer Analyst geschult wird, bevor er einen Kunden-Tenant anfasst.

Die Falle

"Zertifiziertes SOC" meint häufig das ISO-27001-Zertifikat der Firma, und das sagt nichts darüber, wie das SOC einen Vorfall bearbeitet. Und eine Reifegradbewertung von vor drei Jahren beschreibt ein anderes Team. Frag nach Datum, Scope und den Verbesserungsmaßnahmen seither.

Kriterium 12

Qualität des Eskalationsprozesses & Kommunikations-SLA

Warum es zählt

Im echten Vorfall lautet die Frage nicht, ob der Anbieter erkennt, sondern wer wen anruft, wie schnell, auf welcher Nummer, und was passiert, wenn der erste Kontakt nicht abnimmt. NIS2 gibt dir 24 Stunden ab Kenntnis für die Frühwarnung, und der Anbieter ist derjenige, der zuerst Kenntnis hat. Eskalationsweg und Kommunikations-SLA sind die Stellen, an denen diese Uhr gewonnen oder verloren wird.

Was du fragst

Bitte um die Eskalationsmatrix mit Namen, Rollen, Kanälen und Zeitlimits pro Schweregrad, frag, wie der Anbieter dich erreicht, wenn E-Mail und Telefonanlage Teil des Vorfalls sind, was das Kommunikations-SLA garantiert (Erstkontakt, Statusupdates, schriftliche Zusammenfassung), und nach der Kommunikations-Zeitleiste des letzten Großvorfalls.

Die Falle

"Dedizierter Customer Success Manager" ist eine Tagesrolle. Frag, wer dich um drei Uhr nachts anruft, wenn Tier 2 des Anbieters den Alarm als kritisch einstuft, über welchen Out-of-Band-Kanal, und was der Vertrag sagt, wenn dieser Anruf zu spät kommt.

Kriterium 13

Austausch von Threat Intelligence & Community-Teilnahme (ISACs)

Warum es zählt

Ein Anbieter, der Indikatoren mit dem ISAC seiner Branche, dem nationalen CERT und seinen Peers teilt, sieht Kampagnen gegen Organisationen wie deine, bevor sie dich erreichen, und speist zurück, was er aus deinen Vorfällen lernt. Ein Anbieter, der nur kommerzielle Feeds konsumiert, weiß, was alle wissen, einen Tag später.

Was du fragst

Frag, an welchen ISACs, CERTs und Sharing-Communities der Anbieter aktiv teilnimmt, was er im letzten Jahr beigetragen hat, wie schnell ein Indikator aus einem Peer-Vorfall zur Detection auf deinem Tenant wird, und ob du die Feeds deiner eigenen Branche in den Service einbringen kannst.

Die Falle

"Globale Threat Intelligence" beschreibt die eigene Telemetriebasis des Anbieters, und die wird von seinen größten Märkten dominiert. Mitgliedschaftslogos auf einer Folie sagen nichts über aktive Teilnahme. Frag nach einem aktuellen Beispiel einer europäischen Kampagne, die der Anbieter über Community-Sharing vor der öffentlichen Berichterstattung erkannt hat.

Kriterium 14

QBR-Qualität & strategische Beratungsfähigkeit

Warum es zählt

Unter NIS2 verantwortet die Geschäftsleitung die Cyberrisiko-Maßnahmen und muss sie überwachen können; unter DORA ist das Leitungsorgan für das IKT-Drittparteienrisiko verantwortlich. Beide brauchen Berichte, die sie lesen können, und beide profitieren von einem Anbieter, der ihnen sagt, was als Nächstes zu beheben ist. Das Quartalsreview ist der Ort, an dem ein MDR-Vertrag von einem Monitoring-Service zu einem Sicherheitsprogramm wird, oder eine Seite Alarmzahlen bleibt.

Was du fragst

Bitte um einen echten Monatsbericht und einen echten Quartalsbericht für das Management eines bestehenden Kunden, geschwärzt. Prüf, ob sie SLA-Erfüllung pro Schweregrad, offene Findings, Tuning-Änderungen, Analystenabdeckung und eine priorisierte Verbesserungsliste zeigen, oder ob sie Alarmzahlen und eine Bedrohungslage-Folie sind. Frag, wer das QBR präsentiert und welchen Hintergrund diese Person hat.

Die Falle

Hübsche Dashboards mit großen Zahlen "abgewehrter Bedrohungen" genügen niemandem, der etwas unterschreiben muss. Ein Bericht, der verfehlte SLAs nicht zeigen kann, kann auch erfüllte nicht zeigen. Enthält der Bericht des Anbieters nie schlechte Nachrichten oder eine Empfehlung, die den Anbieter Umsatz kostet, ist er ein Marketing-Dokument.

Kriterium 15

Onboarding-Dauer & Integrationskomplexität

Warum es zählt

Ein MDR-Service ist nicht live, wenn der Vertrag unterschrieben ist. Er ist live, wenn die Agenten ausgerollt, die Log-Quellen angebunden, das Asset-Inventar den Analysten bekannt und die False Positives deiner Umgebung ausgetunt sind. Diese Phase dauert typischerweise Wochen bis Monate, und währenddessen ist der Service teilweise blind, während du schon zahlst.

Was du fragst

Bitte um den Onboarding-Plan mit Meilensteinen, den erwarteten Aufwand auf deiner Seite in Personentagen, den Zeitpunkt, ab dem das volle Response-SLA gilt, und was die Tuning-Phase bei den letzten drei vergleichbaren Onboardings gekostet hat.

Die Falle

"In wenigen Tagen einsatzbereit" meint den Agenten-Rollout. Erkennungsqualität und Response-Zusagen kommen später, und manche Verträge nehmen die ersten neunzig Tage stillschweigend vom SLA aus. Such diesen Ausschluss und entscheide, ob du dafür den vollen Preis zahlen willst.

Wirtschaftlichkeit & Compliance


Kriterium 16

Gesamtkosten vs. Aufbau eines eigenen SOC (3-Jahres-Vergleich auf gleicher Basis)

Warum es zählt

Der ehrliche Vergleich ist nicht MDR gegen nichts, sondern MDR gegen das SOC, das du sonst aufbauen müsstest: Analysten im Schichtbetrieb, Tooling, Schulung, Fluktuation, und die Management-Aufmerksamkeit, die es kostet. Beide Zahlen müssen auf demselben Umfang über dieselben drei Jahre gebaut sein, sonst ist die günstigere Option einfach die, die mehr weggelassen hat.

Was du fragst

Bau die Dreijahreskosten eines eigenen SOC bei der Abdeckung, die das MDR verspricht (Schichtplan, Gehälter, Tooling, Schulung, Recruiting), und bitte den Anbieter um die Dreijahressumme für dieselbe Abdeckung, inklusive Onboarding, IR-Stunden, Log-Volumenwachstum und Preisanpassung bei Verlängerung. Vergleich die beiden Zahlen, nicht den Preis pro Endpunkt.

Die Falle

Das MDR-Angebot nimmt den heutigen Endpunktbestand an, und die Inhouse-Schätzung nimmt keine Fluktuation an. Beides stimmt nicht. Der Vergleich auf gleicher Basis ist der, bei dem beide Seiten dasselbe Wachstum, dieselben Abdeckungsstunden und dieselbe Vorfallslast tragen.

Kriterium 17

DSGVO / Data Residency & AVV für den verwalteten Zugriff auf Security-Telemetrie

Warum es zählt

Die Analysten des Anbieters greifen jeden Tag auf personenbezogene Daten in deiner Telemetrie zu, was den Anbieter unter der DSGVO zum Auftragsverarbeiter macht und den Vertrag zu einem Auftragsverarbeitungsvertrag mit einer Liste der Unterauftragsverarbeiter, Standorte und Schutzmaßnahmen für jeden Zugriff von außerhalb der EU. Für ein Finanzunternehmen gehen dieselben Fakten ins DORA-Informationsregister. Ist der AVV ein generischer Anhang, steht die Residenz, die du verhandelt hast, nicht darin.

Was du fragst

Bitte um den Auftragsverarbeitungsvertrag und die Liste der Unterauftragsverarbeiter mit Standorten, prüf, ob er reinen EU-Analystenzugriff und den Übermittlungsmechanismus für jede Ausnahme benennt, frag, welche Daten der Anbieter nach Vertragsende wie lange behält, und frag, wie ein Betroffenenantrag behandelt würde, der deine Telemetrie berührt.

Die Falle

Ein AVV, der sagt "Daten können in Ländern mit angemessenem Schutzniveau verarbeitet werden", plus eine Unterauftragsverarbeiterliste, die mit "und verbundene Unternehmen" endet, sagt dir nichts darüber, wer deine Daten sieht. Frag nach den benannten Gesellschaften, den benannten Ländern und der Klausel, die das EU-only-Versprechen vertraglich macht.

Kriterium 18

Anbieterabhängigkeit & Exit-Bedingungen (Runbook-IP, Datenrückgabe, Übergangsunterstützung)

Warum es zählt

Am Vertragsende brauchst du deine Telemetrie, deine Vorfallshistorie, deine Detection-Regeln und deine Tuning-Entscheidungen, sonst fängt der nächste Anbieter bei null an, und der Audit-Trail von drei Jahren Vorfällen verschwindet. Unter DORA ist eine Exit-Strategie für kritische Funktionen Pflicht; unter NIS2 ist sie schlicht vernünftig.

Was du fragst

Frag, welche Daten beim Exit zurückgegeben werden, in welchem Format, in welcher Frist und zu welchen Kosten, ob die für dich geschriebenen Detection-Regeln und Runbooks dein Eigentum sind, und bitte um die Klausel zur Übergangsunterstützung und die Dauer, die der Anbieter während einer Übergabe weiterbetreibt.

Die Falle

"Vollständiger Datenexport verfügbar" heißt oft: Rohlogs in proprietärem Format, ohne Fallnotizen, Analystenentscheidungen oder Regeln. Und der Export selbst kann eine Gebühr tragen, die unsichtbar bleibt, bis du ihn brauchst. Bepreise den Exit vor der Unterschrift, solange du noch Verhandlungsmacht hast.

Kriterium 19

Erfolgsbilanz des Anbieters & Referenzkunden (relevante Branche)

Warum es zählt

Ein MDR-Anbieter wird an den Vorfällen gemessen, die er bearbeitet hat, und ein Anbieter, der nie einen Ransomware-Fall in einem Krankenhaus, einer Bank oder einer Anlage deiner Art bearbeitet hat, lernt an deinem. Referenzen aus deiner Branche, mit Vorfällen dahinter, sind der einzige Nachweis, dass die Runbooks zu deiner Realität passen und der Anbieter ein Audit durch deine Aufsicht übersteht.

Was du fragst

Bitte um drei Referenzkunden aus deiner Branche und Größe, und frag sie nach dem letzten echten Vorfall: wie schnell der Anbieter erkannt hat, was er getan hat, wie die Kommunikation lief und wie der Post-Incident-Bericht aussah. Frag den Anbieter, wie viele Kunden in den letzten zwei Jahren gegangen sind und warum.

Die Falle

Referenzkunden wählt der Anbieter aus, und Logos auf einer Folie sind keine Referenzen. Die nützliche Frage an eine Referenz ist nicht "sind Sie zufrieden", sondern "erzählen Sie vom letzten Mal, als es schiefging". Eine Referenz ohne so eine Geschichte hatte noch keinen Vorfall.

Kriterium 20

Abstimmung mit der Cyberversicherung & Compliance-Zertifizierung (ISO 27001, SOC2)

Warum es zählt

Dein Cyberversicherer fragt zunehmend, welches MDR du betreibst und was es garantiert, und manche Policen gewähren Rabatt für oder verlangen bestimmte Fähigkeiten wie 24/7-Überwachung und vertragliche Reaktionszeiten. Die eigenen Zertifizierungen des Anbieters (ISO 27001, SOC 2) sind das, wonach deine Lieferantenakte und der Fragebogen deines Versicherers fragen, und eine Lücke in beidem kostet Geld bei der Verlängerung oder, schlimmer, im Schadensfall.

Was du fragst

Frag, welche Punkte des Fragebogens deines Versicherers der Anbieter schriftlich belegen kann, ob der Anbieter im Schadensfall schon mit den Panel-IR-Firmen von Versicherern zusammengearbeitet hat, und bitte um das aktuelle ISO-27001-Zertifikat und den SOC-2-Typ-II-Bericht mit einem Scope, der den SOC-Service selbst abdeckt, nicht nur die Unternehmens-IT.

Die Falle

"ISO 27001 zertifiziert" für die Firma, mit einem Scope, der die SOC-Plattform ausschließt, und ein Versicherungsfragebogen, der mit "ja" beantwortet wird, wo der Vertrag "Best Effort" sagt. Gleiche die schriftlichen Zusagen des Anbieters mit den Garantien der Police ab, bevor der Vorfall kommt, nicht während des Schadensfalls.

Preis


Kriterium 21

Passung des Preismodells (pro Endpoint vs. pro Nutzer vs. monatliche Pauschale)

Warum es zählt

Preise pro Endpunkt sind leicht zu vergleichen und schließen Identity-, Cloud- und Netzwerkabdeckung stillschweigend aus, die als Zusatzmodul oder pro eingelesenem Gigabyte berechnet werden. Preise pro Nutzer wirken fair, bis Service-Konten und externe Mitarbeiter mitgezählt werden. Eine monatliche Pauschale wirkt sicher, bis du erfährst, welchen Umfang sie voraussetzt. Jedes Modell belohnt ein anderes Verhalten, und das falsche macht jede neue Logquelle zu einer Budgetverhandlung.

Was du fragst

Bitte um die Gesamtkosten über drei Jahre für die Abdeckung, die du tatsächlich brauchst, unter jedem Modell, das der Anbieter bietet, inklusive aller Log-Quellen, Aufbewahrung, Incident-Response-Stunden über eine Obergrenze hinaus, Onboarding und Preisanpassung bei Verlängerung. Frag, was mit dem Preis passiert, wenn sich dein Cloud-Log-Volumen verdoppelt oder eine Tochtergesellschaft dazukommt.

Die Falle

Die Zahl pro Endpunkt gewinnt die Vergleichstabelle, und die Gigabyte-Zusatzmodule gewinnen die Rechnung. Lass den Anbieter die Gesamtsumme unterschreiben, nicht den Stückpreis. Ein Anbieter, der für einen definierten Umfang keine Gesamtsumme nennen kann, hat dir gesagt, dass der Umfang nicht definiert ist.

Kriterium 22

Preisplanbarkeit & Mehrverbrauchsbedingungen für Alert-Volumen / IR-Eskalationen

Warum es zählt

Das Angebot nimmt einen normalen Monat an. Die Rechnung, die wehtut, kommt nach dem unnormalen: ein Alarmsturm aus einer falsch konfigurierten Quelle, der gegen eine Volumengrenze zählt, ein Vorfall, der vierzig IR-Stunden über die enthaltenen zehn hinaus verbraucht hat, eine Eskalation an das Forensik-Team des Anbieters zu Notfalltarifen. Planbarkeit ist das, was der Vertrag über diese Monate sagt.

Was du fragst

Frag nach den Obergrenzen für Alarm- und Log-Volumen und den Überschreitungstarifen, den enthaltenen Incident-Response-Stunden und dem Tarif darüber hinaus, ob eine Notfall-Eskalation an die Forensik vorab bepreist ist, und nach der größten einzelnen Überschreitungsrechnung, die ein Kunde im letzten Jahr bekommen hat, und was sie ausgelöst hat.

Die Falle

"Unbegrenzte Alarme" mit einer Fair-Use-Klausel, die der Anbieter auslegt, und "IR inklusive" mit zehn Stunden, die ein echter Vorfall am ersten Tag aufbraucht. Der planbare Preis ist der, bei dem der schlechte Monat eine Zahl hat, bevor er passiert.

Kriterium 23

Angebotener jährlicher Servicepreis

Warum es zählt

Am Ende braucht die Entscheidung eine Zahl pro Anbieter, die sich vergleichen lässt: den angebotenen jährlichen Servicepreis für die Abdeckung, die du wirklich kaufst, ü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 Anbieter um ein verbindliches schriftliches Angebot für denselben Umfang: Endpunkt- und Nutzerzahlen, die in den Kriterien oben identifizierten Log-Quellen und Clouds, Response-Modell und SLA-Stufe, enthaltene IR-Stunden, Onboarding und Laufzeit, mit Jahrespreis und Dreijahressumme getrennt ausgewiesen.

Die Falle

Angebote mit unterschiedlichem Umfang lassen sich nicht vergleichen, und Anbieter wissen das. Ein Angebot enthält IR, das nächste schließt Cloud-Quellen aus, das dritte nimmt die Hälfte deiner Endpunkte an. 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.

PflichtQuelleAbgedeckt durch
Vorfallsbehandlung und Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines MonatsNIS2 Art. 23
Bewältigung von Sicherheitsvorfällen als RisikomanagementmaßnahmeNIS2 Art. 21(2)(b)
Sicherheit der Lieferkette, einschließlich der Beziehungen zu unmittelbaren Anbietern und DiensteanbieternNIS2 Art. 21(2)(d)
Leitungsorgan billigt und überwacht die RisikomanagementmaßnahmenNIS2 Art. 20
Vertragliche Vereinbarungen mit IKT-Drittdienstleistern, erweiterter Katalog für kritische oder wichtige FunktionenDORA Art. 30
IKT-Drittparteienrisiko: Informationsregister, Untervergabekette, Konzentrationsrisiko, Exit-StrategienDORA Art. 28
Meldung schwerwiegender IKT-bezogener VorfälleDORA Art. 19
Auftragsverarbeitung, Sicherheit der Verarbeitung und Drittlandtransfer, wenn Analysten von außerhalb der EU auf personenbezogene Daten zugreifenGDPR Art. 28, Art. 32, 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.

  1. 24/7-SOC-Abdeckung & Analysten-Tiefe (dediziert vs. geteilt, Tier-Struktur)

    Frag nach der Zahl der Analysten pro Schicht und pro Tier, dem Verhältnis von Analysten zu Kunden, ob dein Tenant benannte Analysten hat, die deine Umgebung kennen, wo Tier-3- und Incident-Response-Fähigkeit nachts und am Wochenende sitzt, und nach dem Schichtplan einer typischen Woche.

  2. Vertragliche MTTD- / MTTR-SLA-Zusage & historische Performance

    Bitte um die Vertragsklausel, die Time to Detect, Time to Triage und Time to Contain für einen kritischen Vorfall definiert, mit Messbeginn, garantiertem Wert und Service Credit oder Kündigungsrecht bei Verfehlung. Dann bitte um die tatsächlich gemessenen Werte der letzten zwölf Monate bei bestehenden Kunden.

  3. Frequenz & Methodik des proaktiven Threat Huntings

    Frag, wie viele Hunting-Stunden pro Monat deinem Tenant zugeordnet sind, wer sie leistet, und bitte um die letzten drei schriftlichen Hunt-Reports für einen vergleichbaren Kunden, inklusive der geprüften Hypothesen und dessen, was gefunden wurde.

  4. Flexibilität des Co-Managed-Modells & Kundeneinblick (Portal-Transparenz)

    Frag, ob deine Analysten die Rohtelemetrie, die Detection-Regeln und die Analystennotizen zu jedem Fall in derselben Konsole sehen, die der Anbieter nutzt, ob du eigene Abfragen und Hunts auf deinen Daten fahren kannst, und wie die Aufgabenteilung während der Laufzeit verändert werden kann, wenn dein Team wächst.

  5. Integrierte IR-Fähigkeit (Retainer inklusive vs. Zusatzkosten)

    Bitte um die Liste der Eindämmungsmaßnahmen, die der Anbieter ohne vorherigen Anruf auf deinen Systemen ausführen darf, die Liste derer, die deine Freigabe brauchen, und den Weg, wie diese Freigabe um drei Uhr nachts eingeholt wird. Frag dann, welche Incident Response über die Eindämmung hinaus enthalten ist, wie viele Stunden, zu welchem Tarif darüber hinaus, und wie schnell ein IR-Engineer vor Ort oder online ist.

  6. Technologie-Agnostik vs. Lock-in-Risiko durch proprietären Stack

    Liste dein aktuelles EDR, SIEM, deinen Identity Provider und deine Cloud-Plattformen auf und frag pro Eintrag, ob der Anbieter darauf Erkennung, Reaktionsmaßnahmen und das volle SLA liefert, oder ob das SLA nur für den eigenen Agenten gilt. Frag, was mit dem Service passiert, wenn du eines dieser Tools während der Laufzeit ersetzt.

  7. EDR- / SIEM-Abdeckung & Integrationsqualität bestehender Tools

    Frag, welche deiner tatsächlichen Quellen eingebunden und von Analysten überwacht werden, nicht nur gesammelt: dein EDR, dein SIEM, Identity-Provider-Logs, E-Mail, Netzwerk und Firewall, SaaS-Audit-Logs. Frag pro Quelle, ob Detection-Regeln existieren, wer sie pflegt, und wie die Integration gebaut wurde und in Betrieb gehalten wird.

  8. Cloud-native & Multi-Cloud-Abdeckung (AWS, Azure, GCP)

    Frag, welche Cloud-Plattformen von Analysten mit cloud-spezifischen Detections überwacht werden, ob Signale aus Steuerungsebene, Identität und Workloads mit Endpunkt-Aktivität in einem Vorfall korreliert werden, wie ein Cloud-Vorfall eingedämmt wird (Rollenentzug, Schlüsselrotation, Instanz-Isolation) und von wem, und wie die Abdeckung für die zweite und dritte Cloud aussieht, die du betreibst.

  9. OT- / IoT-Abdeckungsoption (industrielle Umgebungen)

    Frag, ob OT- und IoT-Monitoring eine echte Servicelinie mit dedizierten Analysten mit Industrieerfahrung ist, welche OT-Protokolle und Sensoren unterstützt werden, wie ein OT-Vorfall eingedämmt wird, ohne die Produktion zu stoppen, und nach einem Referenzkunden mit Anlagen deiner Art.

  10. Geografischer SOC-Standort & Data Residency (Option für reines EU-SOC)

    Frag, wo die Analysten, die deine Alarme bearbeiten, physisch sitzen, pro Schicht, und ob der Vertrag reinen EU-Analystenzugriff garantiert. Frag, was aus dieser Garantie bei einer Eskalation oder einem Großvorfall wird, wenn zusätzliches Personal hinzugezogen wird, und wo Data Lake und Backups liegen.

  11. SOC-Reifegrad (SOC-CMM- / CMMI-Zertifizierung oder gleichwertig)

    Bitte um die letzte unabhängige Reifegradbewertung des SOC mit Scope und Befunden, frag, wie Detection Engineering, Vorfallsbearbeitung und Qualitätsreview dokumentiert und gemessen werden, wie hoch die Analystenfluktuation im letzten Jahr war, und wie ein neuer Analyst geschult wird, bevor er einen Kunden-Tenant anfasst.

  12. Qualität des Eskalationsprozesses & Kommunikations-SLA

    Bitte um die Eskalationsmatrix mit Namen, Rollen, Kanälen und Zeitlimits pro Schweregrad, frag, wie der Anbieter dich erreicht, wenn E-Mail und Telefonanlage Teil des Vorfalls sind, was das Kommunikations-SLA garantiert (Erstkontakt, Statusupdates, schriftliche Zusammenfassung), und nach der Kommunikations-Zeitleiste des letzten Großvorfalls.

  13. Austausch von Threat Intelligence & Community-Teilnahme (ISACs)

    Frag, an welchen ISACs, CERTs und Sharing-Communities der Anbieter aktiv teilnimmt, was er im letzten Jahr beigetragen hat, wie schnell ein Indikator aus einem Peer-Vorfall zur Detection auf deinem Tenant wird, und ob du die Feeds deiner eigenen Branche in den Service einbringen kannst.

  14. QBR-Qualität & strategische Beratungsfähigkeit

    Bitte um einen echten Monatsbericht und einen echten Quartalsbericht für das Management eines bestehenden Kunden, geschwärzt. Prüf, ob sie SLA-Erfüllung pro Schweregrad, offene Findings, Tuning-Änderungen, Analystenabdeckung und eine priorisierte Verbesserungsliste zeigen, oder ob sie Alarmzahlen und eine Bedrohungslage-Folie sind. Frag, wer das QBR präsentiert und welchen Hintergrund diese Person hat.

  15. Onboarding-Dauer & Integrationskomplexität

    Bitte um den Onboarding-Plan mit Meilensteinen, den erwarteten Aufwand auf deiner Seite in Personentagen, den Zeitpunkt, ab dem das volle Response-SLA gilt, und was die Tuning-Phase bei den letzten drei vergleichbaren Onboardings gekostet hat.

  16. Gesamtkosten vs. Aufbau eines eigenen SOC (3-Jahres-Vergleich auf gleicher Basis)

    Bau die Dreijahreskosten eines eigenen SOC bei der Abdeckung, die das MDR verspricht (Schichtplan, Gehälter, Tooling, Schulung, Recruiting), und bitte den Anbieter um die Dreijahressumme für dieselbe Abdeckung, inklusive Onboarding, IR-Stunden, Log-Volumenwachstum und Preisanpassung bei Verlängerung. Vergleich die beiden Zahlen, nicht den Preis pro Endpunkt.

  17. DSGVO / Data Residency & AVV für den verwalteten Zugriff auf Security-Telemetrie

    Bitte um den Auftragsverarbeitungsvertrag und die Liste der Unterauftragsverarbeiter mit Standorten, prüf, ob er reinen EU-Analystenzugriff und den Übermittlungsmechanismus für jede Ausnahme benennt, frag, welche Daten der Anbieter nach Vertragsende wie lange behält, und frag, wie ein Betroffenenantrag behandelt würde, der deine Telemetrie berührt.

  18. Anbieterabhängigkeit & Exit-Bedingungen (Runbook-IP, Datenrückgabe, Übergangsunterstützung)

    Frag, welche Daten beim Exit zurückgegeben werden, in welchem Format, in welcher Frist und zu welchen Kosten, ob die für dich geschriebenen Detection-Regeln und Runbooks dein Eigentum sind, und bitte um die Klausel zur Übergangsunterstützung und die Dauer, die der Anbieter während einer Übergabe weiterbetreibt.

  19. Erfolgsbilanz des Anbieters & Referenzkunden (relevante Branche)

    Bitte um drei Referenzkunden aus deiner Branche und Größe, und frag sie nach dem letzten echten Vorfall: wie schnell der Anbieter erkannt hat, was er getan hat, wie die Kommunikation lief und wie der Post-Incident-Bericht aussah. Frag den Anbieter, wie viele Kunden in den letzten zwei Jahren gegangen sind und warum.

  20. Abstimmung mit der Cyberversicherung & Compliance-Zertifizierung (ISO 27001, SOC2)

    Frag, welche Punkte des Fragebogens deines Versicherers der Anbieter schriftlich belegen kann, ob der Anbieter im Schadensfall schon mit den Panel-IR-Firmen von Versicherern zusammengearbeitet hat, und bitte um das aktuelle ISO-27001-Zertifikat und den SOC-2-Typ-II-Bericht mit einem Scope, der den SOC-Service selbst abdeckt, nicht nur die Unternehmens-IT.

  21. Passung des Preismodells (pro Endpoint vs. pro Nutzer vs. monatliche Pauschale)

    Bitte um die Gesamtkosten über drei Jahre für die Abdeckung, die du tatsächlich brauchst, unter jedem Modell, das der Anbieter bietet, inklusive aller Log-Quellen, Aufbewahrung, Incident-Response-Stunden über eine Obergrenze hinaus, Onboarding und Preisanpassung bei Verlängerung. Frag, was mit dem Preis passiert, wenn sich dein Cloud-Log-Volumen verdoppelt oder eine Tochtergesellschaft dazukommt.

  22. Preisplanbarkeit & Mehrverbrauchsbedingungen für Alert-Volumen / IR-Eskalationen

    Frag nach den Obergrenzen für Alarm- und Log-Volumen und den Überschreitungstarifen, den enthaltenen Incident-Response-Stunden und dem Tarif darüber hinaus, ob eine Notfall-Eskalation an die Forensik vorab bepreist ist, und nach der größten einzelnen Überschreitungsrechnung, die ein Kunde im letzten Jahr bekommen hat, und was sie ausgelöst hat.

  23. Angebotener jährlicher Servicepreis

    Bitte jeden Anbieter um ein verbindliches schriftliches Angebot für denselben Umfang: Endpunkt- und Nutzerzahlen, die in den Kriterien oben identifizierten Log-Quellen und Clouds, Response-Modell und SLA-Stufe, enthaltene IR-Stunden, 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

Diesen Katalog drucken oder als PDF fürs Meeting sichern