So bewerten Sie DSPM-Anbieter: Das Auswahlkriterien-Raster für Unternehmenskunden

Skyhigh Security

Mai 2026 · 16 Minuten Lesezeit

Datensicherheit

Kurzzusammenfassung

Die Breite der Erkennung allein ist ein unzureichender Indikator für die Wirksamkeit von DSPM – die Klassifizierungsgenauigkeit und die Risikobewertung sind von größerer Bedeutung.
Bei Proof-of-Concept-Bewertungen sollten echte Produktionsdaten und SaaS-Lösungen im Unternehmensmaßstab verwendet werden, nicht synthetische Testdatensätze.
Die Klassifizierungsgenauigkeit und die Risikopriorisierung haben im Bewertungsrahmen für Anbieter das höchste Gewicht.
DSPM ist keine eigenständige Lösung – prüfen Sie die Integrationsmöglichkeiten im Hinblick auf Ihre bestehenden SSE-, DLP-, SIEM- und IAM-Systeme.
Stellen Sie Ihren Bewertungsausschuss so zusammen, dass die Bereiche Sicherheit, Compliance, Datenverwaltung und IT-Betrieb darin vertreten sind.
Die kostspieligsten DSPM-Fehlschläge sind die langsamen – also Lösungen, die zwar eingeführt werden, aber niemals ihre volle Betriebsreife erreichen.
Stellen Sie den Anbietern kritische Fragen. Allgemeine Antworten auf Ausschreibungen geben weniger Aufschluss als gezielte, auf bestimmte Szenarien zugeschnittene Herausforderungen.

Die Auswahl einer Lösung für das Datensicherheits-Posture-Management ist eine der beschaffungspolitischen Entscheidungen mit den höchsten Risiken, die ein Sicherheitsteam in diesem Jahr treffen wird. Wenn Sie die richtige Wahl treffen, erhalten Sie kontinuierlichen Einblick darin, wo sich sensible Daten befinden, wer darauf zugreifen kann und wie stark sie tatsächlich gefährdet sind. Treffen Sie die falsche Wahl, haben Sie ein teures Dashboard erworben, das Warnmeldungen generiert, auf die niemand reagiert. Die Herausforderung besteht darin, dass jeder Anbieter in dieser Kategorie in seinen Demos einen guten Eindruck hinterlässt – ausgefeilte Klassifizierungs-Engines, die kuratierte Testumgebungen scannen, ansprechende Risiko-Heatmaps und auf einer Folie aufgelistete Integrationen. Die Kluft zwischen dem, was Sie in einer Anbieter-Demo sehen, und dem, was Sie im Produktivbetrieb erleben, ist der Grund, warum die meisten DSPM-Anschaffungen schiefgehen.

Dieser Leitfaden bietet einen strukturierten, herstellerneutralen Rahmen für die Bewertung von DSPM-Plattformen. Er orientiert sich an den Bewertungsdimensionen, die Analystenhäuser wie Forrester und Gartner in ihren „Wave“- und Magic Quadrant verwenden – Erkennung, Klassifizierung, Risikoanalyse, Behebung, Integrationsgrad und operative Reife –, setzt diese Dimensionen jedoch in eine praktische Bewertungsmethodik um, die Ihr Team bei der Vorauswahl und bei Proof-of-Concept-Tests anwenden kann. Der DSPM-Leitfaden der Cloud Security Alliance betont zudem, dass eine effektive Bewertung über reine Funktionschecklisten hinausgehen muss, um zu beurteilen, wie sich eine Lösung in Ihrer tatsächlichen Datenumgebung, bei Ihren Zugriffsmustern und im Hinblick auf Ihre Compliance-Verpflichtungen bewährt.

Ganz gleich, ob Sie als CISO einen Business Case erstellen, als Datenschutzbeauftragter (DPO) die gesetzlichen Anforderungen an die Nachweisführung erfassen, als Cloud-Sicherheitsingenieur die API-Abdeckung einem Stresstest unterziehen oder als Leiter der Beschaffungsabteilung die Gesamtbetriebskosten modellieren – das im Folgenden vorgestellte Rahmenwerk bietet jedem Beteiligten einen klaren Handlungsrahmen innerhalb eines einzigen, einheitlichen Bewertungsprozesses.

Die Realitätsprüfung des Proof-of-Concept

Anbieterdemonstrationen sind naturgemäß optimierte Umgebungen. Die Testdaten sind bereinigt, die Berechtigungsstrukturen sind einfach, und die Klassifizierungsmodelle wurden speziell auf die gezeigten Szenarien abgestimmt. Wirksame Proof-of-Concept-Bewertungen sollten, soweit angemessen, echte Produktionsdaten und SaaS-Umgebungen im Unternehmensmaßstab einbeziehen, da vereinfachte Testdatensätze selten die Herausforderungen in Bezug auf Betrieb, Transparenz und Governance aufzeigen, die in komplexen Microsoft 365- und Multi-Cloud-Bereitstellungen auftreten.

Das M365-Problem

Hier ist ein Szenario, das sich bei fast jeder DSPM-Evaluierung in Unternehmen abspielt: Bei der Demo des Anbieters wird eine SharePoint-Testseite mit einigen hundert Dokumenten und einfachen Berechtigungen gescannt. Die Klassifizierungsgenauigkeit erscheint hervorragend – über 95 % Präzision bei der Erkennung personenbezogener Daten, ein einwandfreies Risikoscoring und nur minimale Fehlalarme. Dann verbinden Sie das System mit Ihrer tatsächlichen Microsoft 365-Umgebung.

Was der Anbieter Ihnen jedoch nicht gezeigt hat, ist, was geschieht, wenn sein Scanner auf verschachtelte Teams-Berechtigungen stößt, die über Kanalhierarchien hinweg vererbt werden, auf SharePoint-Websites mit komplexen Freigabelinks („Jeder mit dem Link“, „bestimmte Personen“, „unternehmensweit“), auf Zugriffsberechtigungen für Gastbenutzer, die drei Ebenen tief in Gruppenmitgliedschaften verborgen sind, auf OneDrive-Dateien, die über den Teams-Chat freigegeben werden (wodurch Freigabeberechtigungen entstehen, die in der SharePoint-Verwaltung nicht sichtbar sind), sowie auf Vertraulichkeitskennzeichnungen, die über Geschäftsbereiche hinweg uneinheitlich angewendet werden. Unter diesen realen Bedingungen sinkt die Klassifizierungsgenauigkeit oft erheblich, die Zahl der Fehlalarme steigt sprunghaft an, da der Scanner die Berechtigungsvererbungsketten nicht auflösen kann und standardmäßig alles als übermäßig offengelegt markiert, und das Risiko-Dashboard wird so unübersichtlich, dass Ihr Sicherheitsteam es bereits nach wenigen Wochen ignoriert.

Was bei einem echten POC getestet werden sollte

Gestalten Sie Ihren Proof of Concept anhand von Szenarien, die eine DSPM-Plattform tatsächlich auf die Probe stellen. Verbinden Sie den Anbieter mit einer repräsentativen M365-Produktionsumgebung – nicht mit einem Test-Tenant. Wählen Sie ein Tenant-Segment mit echter Komplexität bei der Freigabe: eine Abteilung, die intensiv mit externen Partnern zusammenarbeitet, eine Teams-Umgebung mit verschachtelten privaten Kanälen sowie SharePoint-Websites, auf denen sich über Jahre hinweg Ad-hoc-Freigabeberechtigungen angesammelt haben.

Vergleichen Sie die Klassifizierung mit der Referenzdatenbank. Kennzeichnen Sie vor dem POC manuell eine Stichprobe von 200–500 Dokumenten über verschiedene Sensitivitätsstufen hinweg. Vergleichen Sie nach den DSPM-Scans die Klassifizierungen des Systems mit Ihrer Referenzdatenbank. Berechnen Sie die Präzision (welcher Prozentsatz der markierten Elemente ist tatsächlich sensibel) und den Recall (welcher Prozentsatz der tatsächlich sensiblen Elemente wurde gefunden). Anbieter, die bei einem optimierten POC mit Ihren realen Daten keine Präzision von mindestens 85 % und keinen Recall von mindestens 80 % erreichen, werden im Produktivbetrieb schlechtere Ergebnisse erzielen.

Testen Sie die Tiefe der Berechtigungsauflösung. Erstellen Sie Testszenarien mit bekannten komplexen Berechtigungsketten: ein Dokument, das über den Chat einer Teams-Besprechung freigegeben wurde, eine SharePoint-Datei, deren Berechtigungen über eine verschachtelte Sicherheitsgruppe vererbt wurden, die Gastbenutzer umfasst, sowie einen OneDrive-Ordner, der für eine M365-Gruppe freigegeben wurde. Stellen Sie sicher, dass das DSPM genau ermitteln kann, wer tatsächlich Zugriff hat – und nicht nur, wer nominelle Berechtigungen besitzt.

Bewerten Sie den Triage-Workflow hinsichtlich falsch-positiver Ergebnisse. Eine hohe Falsch-Positiv-Rate ist verkraftbar, wenn der Triage- und Entlassungs-Workflow effizient ist. Eine moderate Falsch-Positiv-Rate in Verbindung mit einer umständlichen Triage-Oberfläche ist hingegen ungünstiger. Messen Sie, wie lange ein Analyst benötigt, um einen Befund zu prüfen, zu validieren und entweder zu entlassen oder zu eskalieren. Multiplizieren Sie diesen Wert mit Ihrem prognostizierten täglichen Alarmvolumen.

Führen Sie einen Rundlauf zur Behebung durch. Wählen Sie fünf tatsächliche Befunde zu übermäßiger Offenlegung aus dem POC-Scan aus. Versuchen Sie, diese über den Workflow des DSPM zu beheben – indem Sie einen Freigabelink widerrufen, Berechtigungen anpassen oder eine Vertraulichkeitskennzeichnung zuweisen. Überprüfen Sie, ob die Behebung in M365 tatsächlich wirksam wird und ob das DSPM den aktualisierten Sicherheitsstatus im nächsten Scanzyklus widerspiegelt.

Testen Sie unter den Bedingungen Ihres tatsächlichen Datenumfangs. Wenn Ihr Unternehmen über 50 TB Daten in M365 und AWS S3 verfügt, sagt ein POC, bei dem 500 GB gescannt werden, nichts über die Leistung, die Scan-Dauer oder die Effizienz inkrementeller Scans aus. Setzen Sie sich für einen POC-Umfang ein, der mindestens 20 % Ihres Produktionsdatenvolumens abdeckt.

Fragen, die Sie Anbietern stellen sollten

Allgemeine Checklisten für Ausschreibungen führen zu allgemeinen Antworten. Die folgenden Fragen sollen konkrete Kompetenzlücken und betriebliche Gegebenheiten aufdecken, die in den Marketingunterlagen der Anbieter nicht zum Vorschein kommen.

Zur Klassifizierungsgenauigkeit: „Wie hoch ist Ihre gemessene Falsch-Positiv-Rate bei unstrukturierten Daten in M365-Umgebungen mit mehr als 10.000 Benutzern? Können Sie Referenzkunden ähnlicher Größe nennen, die ihre Genauigkeitskennzahlen nach der Feinabstimmung offenlegen können?“ Anbieter, die Genauigkeitswerte ausschließlich aus kontrollierten Umgebungen angeben oder sich weigern, Sie mit Referenzkunden für Gespräche zur Genauigkeit in Kontakt zu bringen, lassen eine Lücke erkennen.

Zur Berechtigungsauflösung: „Wenn Ihr Scanner auf eine SharePoint-Datei stößt, deren effektiver Zugriff von einer verschachtelten Azure AD-Sicherheitsgruppe abgeleitet wird, die B2B-Gastbenutzer umfasst, wie lösen Sie dann die effektiven Berechtigungen auf? Erläutern Sie mir bitte die konkreten API-Aufrufe und die Logik der Berechtigungsvererbung.“ Hiermit wird geprüft, ob die Zugriffszuordnung des Anbieters tatsächlich identitätsorientiert ist oder ob sie sich auf nominelle Berechtigungsdaten stützt, ohne die Gruppennestung aufzulösen.

Zur Anpassung der Klassifizierung: „Wir verfügen über branchenspezifische sensible Datentypen, die von den Standardklassifikatoren für PII/PHI/PCI nicht abgedeckt werden. Wie sieht der Prozess zur Erstellung benutzerdefinierter Klassifikatoren aus? Wie viele Trainingsbeispiele sind erforderlich, wie lange dauert ein typischer Optimierungszyklus und welche Genauigkeit können wir bei benutzerdefinierten Typen im Vergleich zu den integrierten Typen erwarten?“ Dies unterscheidet Anbieter mit tatsächlich trainierbaren Klassifizierungsmodulen von solchen, die auf regulären Ausdrücken basierende benutzerdefinierte Regeln anbieten, die als maschinelles Lernen vermarktet werden.

Zur Transparenz des Risikomodells: „Wie wird Ihre Risikobewertung berechnet? Welche Variablen fließen in die Bewertung ein, wie werden sie gewichtet, und können wir die Gewichtungen anpassen? Wenn zwei Dateien identische personenbezogene Daten enthalten, eine jedoch für 5 Benutzer zugänglich ist und die andere für 5.000, wie unterscheidet Ihr Risikomodell zwischen diesen beiden?“ Eine undurchsichtige Risikobewertung, die weder erklärt noch angepasst werden kann, wird der genauen Prüfung durch Ihren CISO oder den Fragen Ihres Wirtschaftsprüfers nicht standhalten.

Zur Integrationsmechanik: „Zeigen Sie mir die tatsächliche Ereignis-Nutzlast, die Ihre Plattform an ein SIEM sendet. Welche Felder sind enthalten? Handelt es sich um ein strukturiertes CEF-/LEEF-Ereignis, einen JSON-Webhook oder einen Syslog-Dump? Können wir filtern, welche Ereignisse weitergeleitet werden?“ Der Unterschied zwischen einer SIEM-Integration, die Ihr SOC bereichert, und einer, die es mit unbrauchbaren Ereignissen überflutet, liegt in der Struktur der Nutzlast und der Granularität der Filterung.

Zu den Korrekturmaßnahmen: „Welche Korrekturmaßnahmen kann Ihre Plattform nativ ausführen – nicht nur empfehlen, sondern tatsächlich ausführen? Können Sie speziell für M365 einen Freigabelink widerrufen, Website-Berechtigungen ändern, eine Vertraulichkeitskennzeichnung zuweisen und eine Datei unter Quarantäne stellen?“ Viele DSPM-Plattformen stellen Korrekturmaßnahmen als Funktion dar, liefern jedoch tatsächlich lediglich eine Empfehlung, die ein Mitarbeiter manuell in einer separaten Konsole ausführt.

Zum betrieblichen Aufwand: „Wie viele Vollzeitäquivalentstunden pro Woche wendet ein typischer Kunde unserer Größe nach der Erstimplementierung für die Feinabstimmung der Klassifizierung, die Triage von Fehlalarmen, die Anpassung von Richtlinien und die Wartung der Integration auf? Ist die Unterstützung bei der Feinabstimmung im Preis inbegriffen oder werden dafür zusätzliche Kosten für professionelle Dienstleistungen anfallen?“ Die Gesamtbetriebskosten eines DSPM werden maßgeblich von den Betriebskosten bestimmt, nicht von den Lizenzgebühren.

Abstimmung der Anforderungen der Interessengruppen

Eine DSPM-Bewertung scheitert, wenn sie die Prioritäten eines einzelnen Interessengruppenvertreters auf Kosten anderer optimiert. Jede Rolle in Ihrem Bewertungsgremium bringt eine andere Perspektive mit sich, und das Bewertungsschema muss all diesen gerecht werden.

CISO: Risikoberichterstattung und Kommunikation mit dem Vorstand

Der CISO benötigt ein DSPM, das Risikoberichte auf Führungsebene erstellt – nicht nur technische Befunde, sondern auch Trenddaten, aus denen hervorgeht, ob sich die Datensicherheitslage im Laufe der Zeit verbessert oder verschlechtert. Prüfen Sie, ob die Plattform vorlegungsfertige Zusammenfassungen erstellen kann, die Kennzahlen zur Datengefährdung in die Sprache der Geschäftsrisiken übersetzen. Erkundigen Sie sich, ob die Risikobewertung nach Geschäftsbereichen, Datentypen oder regulatorischen Bereichen segmentiert werden kann, damit der CISO über die Sicherheitslage anhand der für den Vorstand relevanten Dimensionen berichten kann. Ein DSPM, das zwar hervorragende technische Ergebnisse liefert, diese jedoch nicht zu strategischen Risikobeschreibungen zusammenfassen kann, wird den Anforderungen des CISO nicht gerecht.

Datenschutzbeauftragter: Nachweis der Einhaltung von Vorschriften und Vorbereitung auf Prüfungen

Der Datenschutzbeauftragte benötigt das DSPM, damit es als Instrument zur Nachweiserstellung im Bereich der Compliance fungieren kann. Bewerten Sie die integrierten Richtlinienrahmen für die DSGVO, den CCPA, HIPAA, PCI DSS sowie alle branchenspezifischen Vorschriften, denen Ihre Organisation unterliegt. Prüfen Sie, ob die Plattform auditfähige Berichte erstellen kann, die Datenergebnisse bestimmten regulatorischen Anforderungen zuordnen – nicht nur ein Compliance-Dashboard, sondern exportierbare Nachweise, die ein Auditor vom Befund über die Kontrollmaßnahme bis hin zur Abhilfemaßnahme nachverfolgen kann. Der Datenschutzbeauftragte benötigt zudem Unterstützung bei Auskunftsersuchen betroffener Personen: Kann das DSPM alle Vorkommen der Daten einer bestimmten Person in allen gescannten Repositorien ausfindig machen?

Cloud-Sicherheitsingenieur: API-Abdeckung und Automatisierung

Der Cloud-Sicherheitsingenieur prüft, ob sich das DSPM in bestehende „Infrastructure-as-Code“- und Sicherheitsautomatisierungs-Workflows einbinden lässt. Er benötigt eine umfassende API-Abdeckung – nicht nur eine REST-API zum Abrufen von Ergebnissen, sondern auch die Möglichkeit, Scans auszulösen, Richtlinien zu aktualisieren und Korrekturmaßnahmen programmgesteuert durchzuführen. Prüfen Sie die Unterstützung von Webhooks, die Verfügbarkeit von Terraform- oder Pulumi-Providern sowie die Integration in CI/CD-Pipelines. Dem Ingenieur ist zudem die Scan-Leistung wichtig: Wie lange dauert ein inkrementeller Scan, wie hoch ist die API-Ratenbegrenzung und lässt sich die Scan-Architektur bei wachsenden Datenmengen horizontal skalieren?

Beschaffung: Gesamtbetriebskosten

Die Beschaffungsabteilung muss die Gesamtbetriebskosten (TCO) über die Lizenzgebühren hinaus modellieren. Die Preismodelle für DSPM variieren erheblich: pro Datenspeicher, pro gescanntem TB, pro Benutzer, pro Befund, pauschale Plattformgebühr oder Hybridmodelle. Bitten Sie die Anbieter um eine detaillierte Preisaufschlüsselung für Ihren prognostizierten Umfang, einschließlich Gebühren für die Überschreitung von Kontingenten, zusätzlicher Gebühren für Konnektoren, professioneller Dienstleistungen für die Bereitstellung und Optimierung sowie Bedingungen für Preiserhöhungen bei Vertragsverlängerungen. Modellieren Sie die Gesamtbetriebskosten (TCO) über drei Jahre einschließlich interner Betriebskosten (Vollzeitäquivalent-Stunden für Verwaltung, Optimierung und Triage). Ein DSPM, dessen Lizenzkosten zwar 30 % geringer sind, das jedoch den doppelten Aufwand an Vollzeitäquivalenten erfordert, ist nicht die kostengünstigere Option.

Häufige Fehler von Käufern

Kaufen allein aufgrund der Breite des Angebots

Der häufigste Fehler bei der Bewertung besteht darin, Anbieter in erster Linie danach zu bewerten, wie viele Datenspeicher sie scannen können. Die Breite der Erfassung ist eine Grundvoraussetzung – nahezu jeder DSPM-Anbieter für Unternehmen deckt die wichtigsten IaaS-Anbieter, M365, Google Workspace und gängige Datenbankplattformen ab. Die Unterschiede zwischen den Anbietern liegen in der Tiefe der Klassifizierung, der Kontextualisierung von Risiken und der Fähigkeit zur Behebung von Schwachstellen. Eine Bewertung, bei der die Erfassung mit 40 % oder mehr gewichtet wird, führt zur Auswahl des Anbieters mit der längsten Liste an Konnektoren – was jedoch nicht gleichbedeutend ist mit dem Anbieter, der die besten Sicherheitsergebnisse liefert.

Überspringen des POC mit Echtdaten

Die Durchführung eines Proof-of-Concept mit synthetischen Daten oder einem sauberen Testmandanten ist kaum aufschlussreicher als das Anschauen einer Demo. Echte Daten weisen unübersichtliche Klassifizierungen, mehrdeutige Inhalte, die an der Grenze zwischen sensiblen und nicht-sensiblen Daten liegen, sowie Berechtigungsstrukturen auf, deren Komplexität sich über Jahre hinweg organisch aufgebaut hat. Anbieter wissen das – weshalb manche davon abraten, während der Evaluierungsphase eine Verbindung zu Produktionsumgebungen herzustellen. Bestehen Sie auf einem POC in der Produktionsumgebung. Ein Anbieter, der mit Ihren echten Daten keine guten Ergebnisse erzielen kann, wird auch nach dem Kauf keine guten Ergebnisse liefern.

Nichtberücksichtigung des betrieblichen Gemeinkostenaufwands

Die Lizenzkosten sind der auffälligste Posten bei der Anschaffung eines DSPM, doch die Betriebskosten – also die Vollzeitäquivalent-Stunden für Feinabstimmung, Triage, Richtlinienverwaltung und Integrationswartung – betragen über einen Zeitraum von drei Jahren in der Regel das Zwei- bis Dreifache der Lizenzkosten. Bewerten Sie den Betriebsaufwand genau: Wie viel Feinabstimmung ist erforderlich, um eine akzeptable Klassifizierungsgenauigkeit zu erreichen, wie viele Fehlalarme wird Ihr Team täglich bearbeiten müssen und welches Fachwissen ist für die Verwaltung der Plattform erforderlich?

Behandlung von DSPM als eigenständige Erkrankung

DSPM funktioniert nicht isoliert. Sein Nutzen wird dadurch verstärkt oder geschmälert, wie gut es sich in Ihre übergeordnete Sicherheitsarchitektur integrieren lässt. Die Cloud Security Alliance betont, dass eine effektive DSPM-Implementierung von einer SSE-Plattform profitiert, die unterstützende Funktionen wie CSPM, SSPM, UEBA und Echtzeit-Aktivitätsüberwachung bereitstellt. Bewerten Sie jeden DSPM-Anbieter im Kontext Ihrer bestehenden Infrastruktur: Ergänzt er Ihr DLP oder dupliziert er dessen Funktionen? Kann er Ergebnisse zur Durchsetzung an Ihr CASB weiterleiten? Bereichert er Ihr SIEM mit Kontextdaten oder erhöht er lediglich das Alarmaufkommen?

Die AI-Daten-Governance wird zu wenig berücksichtigt

Da Unternehmen generative KI-Tools, Copilots und RAG-Pipelines einsetzen, gehen die Anforderungen an die Daten-Governance über die traditionellen Compliance-Kategorien hinaus. Ein DSPM, das Daten lediglich anhand von PII-/PHI-/PCI-Taxonomien klassifiziert, könnte die neu entstehende Anforderung übersehen, Daten zu identifizieren und zu steuern, die in KI-Trainingsdatensätze, Fine-Tuning-Pipelines und „Retrieval-Augmented Generation“-Speicher fließen. Prüfen Sie, ob das DSPM die Offenlegung sensibler Daten gegenüber KI-Diensten erkennen kann und ob seine Klassifizierungstaxonomie ausreichend erweiterbar ist, um KI-spezifische Governance-Anforderungen abzudecken.

Gestaltung des Bewertungsprozesses

Ein strukturierter Bewertungsprozess verhindert eine schleichende Ausweitung des Projektumfangs und eine durch Anbieter verursachte Fehlausrichtung.

Wochen 1–2: Anforderungsdefinition. Stellen Sie Ihren Bewertungsausschuss zusammen (CISO oder dessen Beauftragter, Datenschutzbeauftragter, Cloud-Sicherheitsingenieur, Beschaffungsabteilung). Legen Sie fest, welche Funktionen unverzichtbar sind und welche wünschenswert sind. Passen Sie die gewichtete Bewertungstabelle an die Prioritäten Ihrer Organisation an. Richten Sie die POC-Umgebung und den Referenzdatensatz ein.

Wochen 3–4: Ausschreibung und Vorauswahl. Versenden Sie gezielte Ausschreibungen unter Verwendung der in diesem Leitfaden enthaltenen Fragen an die Anbieter. Bewerten Sie die schriftlichen Antworten anhand Ihrer gewichteten Kriterien. Grenzen Sie die Auswahl auf drei bis vier Anbieter für Vorführungen ein.

Wochen 5–6: Strukturierte Vorführungen. Führen Sie die Vorführungen anhand einer standardisierten Szenarienliste durch, nicht anhand des vom Anbieter bevorzugten Vorführungsskripts. Verlangen Sie von jedem Anbieter, dass er dieselben Anwendungsfälle vorführt: M365-Berechtigungsauflösung, Erstellung benutzerdefinierter Klassifikatoren, Durchführung von Korrekturmaßnahmen und SIEM-Integration.

Wochen 7–10: Proof of Concept. Führen Sie mit zwei in die Endauswahl gekommenen Anbietern gleichzeitig einen POC unter Produktionsbedingungen durch. Bewerten Sie die POC-Leistung anhand der gewichteten Kriterien unter Verwendung der gemessenen Daten – Klassifizierungsgenauigkeit, Falsch-Positiv-Rate, Scan-Leistung und Round-Trip-Zeit für die Behebung.

Wochen 11–12: Endauswertung, Verhandlungen und Entscheidung. Ermitteln Sie die Gesamtpunktzahlen aller Bewerter. Legen Sie den verantwortlichen Führungskräften die Bewertungsmatrix zusammen mit einer klaren Empfehlung vor. Verhandeln Sie die Vertragsbedingungen mit dem ausgewählten Anbieter und nutzen Sie dabei die Leistungsdaten aus dem POC als Verhandlungsgrundlage für die SLAs.

Häufig gestellte Fragen

Planen Sie drei bis vier Wochen für aktive Tests ein. In der ersten Woche stehen die Bereitstellung und erste Scans im Vordergrund, in der zweiten Woche die Feinabstimmung der Klassifizierung und die Messung der Genauigkeit, und in der dritten und vierten Woche erfolgen Tests zur Fehlerbehebung, die Validierung der Integration sowie Skalierungstests. Bei einer Dauer von weniger als drei Wochen lassen sich die betrieblichen Realitäten der Feinabstimmung der Klassifizierung und des Umgangs mit Fehlalarmen nicht ausreichend aufdecken. Wenn ein Anbieter auf einen einwöchigen POC drängt, optimiert er möglicherweise eher eine eng gefasste „Happy-Path“-Demonstration als eine realistische Bewertung.

Dies hängt von Ihrer Architekturstrategie ab. Wenn sich Ihr Unternehmen für eine SSE-Plattform entschieden hat, die DSPM-Funktionen umfasst, sollten Sie zunächst das integrierte Angebot prüfen – eine native Integration innerhalb einer SSE-Suite sorgt häufig für eine höhere betriebliche Effizienz als eine eigenständige DSPM-Lösung, die an eine separate SSE-Lösung angehängt wird. Sollte das in die SSE-Lösung eingebettete DSPM bei Ihrer gewichteten Bewertung jedoch hinsichtlich Klassifizierungsgenauigkeit oder Risikopriorisierung schlecht abschneiden, kann ein eigenständiges DSPM mit leistungsstarken Integrations-APIs möglicherweise bessere Ergebnisse liefern. Entscheidend ist, beide Optionen anhand desselben Bewertungsrahmens zu beurteilen.

Bei Standardkategorien personenbezogener Daten (Namen, Sozialversicherungsnummern, Kreditkartennummern, E-Mail-Adressen) können Sie bei einer optimierten Bereitstellung auf Basis Ihrer realen Daten mit einer Präzision von über 90 % und einem Recall von über 85 % rechnen. Bei komplexeren Kategorien wie geschützten Gesundheitsdaten (PHI) in klinischen Notizen, geistigem Eigentum (IP) in technischen Dokumenten oder benutzerdefinierten Datentypen sind eine Präzision von über 80 % und ein Recall von über 75 % ein realistisches Ziel. Seien Sie skeptisch gegenüber Anbietern, die eine Genauigkeit von 99 % behaupten – diese Zahl stammt mit ziemlicher Sicherheit aus Tests mit kuratierten Datensätzen, die saubere, eindeutige Beispiele enthalten.

Analysten-Rahmenwerke wie die „Forrester Wave“ unterscheiden zwischen der aktuellen Stärke des Angebots und der strategischen Vision. Wenden Sie einen ähnlichen Ansatz an: Legen Sie bei der Bewertung den Schwerpunkt auf Funktionen, die bereits heute allgemein verfügbar und testbar sind, und nicht auf Roadmap-Zusagen. Wenn die KI-Daten-Governance-Fähigkeit eines Anbieters in der Roadmap für das nächste Quartal vorgesehen ist, bewerten Sie diese in Ihrer aktuellen Bewertung mit null und nehmen Sie eine Neubewertung vor, sobald sie verfügbar ist. Roadmap-Funktionen sind Absichten des Anbieters, keine vertraglichen Verpflichtungen.

Der Anbieter weigert sich, während des POC eine Verbindung zu Ihrer Produktionsumgebung herzustellen. Die Risikobewertung ist undurchsichtig, und der Anbieter kann die Variablen und Gewichtungen nicht erläutern. Die Plattform erfordert einen dedizierten Administrator, was die Kapazitäten Ihres Teams übersteigt. Der Anbieter kann keine Referenzkunden vergleichbarer Größe nennen, die bereit sind, über die betrieblichen Gegebenheiten nach der Implementierung zu sprechen. Und was die Preisgestaltung betrifft: Wenn der Anbieter kein klares, schriftliches Preismodell für Ihr prognostiziertes Volumen mit expliziten Bedingungen für die Überschreitung der Kontingente vorlegen kann, müssen Sie bei der Vertragsverlängerung mit Überraschungen rechnen.

In den meisten Cloud-nativen Umgebungen reduziert eine agentenlose Architektur Reibungsverluste bei der Bereitstellung, macht die Wartung von Scannern überflüssig und vermeidet Leistungsbeeinträchtigungen bei Produktionsdatenspeichern. Allerdings ist das agentenlose Scannen auf den API-Zugriff angewiesen, was bedeutet, dass die Scantiefe durch die von den Cloud-Anbietern bereitgestellten APIs begrenzt ist. Agentenbasierte oder hybride Ansätze können eine gründlichere Überprüfung für lokale Datenbanken, ältere Dateifreigaben oder Umgebungen mit begrenzter API-Abdeckung bieten. Wenn sich mehr als 80 % Ihrer sensiblen Daten auf großen Cloud-Plattformen befinden, ist ein agentenloser Ansatz wahrscheinlich ausreichend.

Schützen Sie Ihre Daten überall

Skyhigh Security einen einheitlichen Datenschutz mit branchenführenden DLP-, CASB- und DSPM-Lösungen – alles auf einer einzigen konvergenten SSE-Plattform.

Produkte entdecken Demo anfordern