Kurzantwort
Privacy-IRM-Software sollte im Rahmen einer RFP-Ausschreibung nicht ausschließlich anhand allgemeiner Funktionslisten bewertet werden. Maßgeblich ist vielmehr, ob die jeweilige Lösung Governance-Prozesse im laufenden Betrieb nachvollziehbar, dauerhaft und skalierbar abbilden kann.
Zu berücksichtigen sind insbesondere Rollen und Berechtigungen, Freigaben, Eskalationen, Nachweise, strukturierte Daten, Exportmöglichkeiten, Integrationen sowie das zugrunde liegende Betriebsmodell. Eine belastbare Bewertungslogik sollte deshalb jede geforderte Funktion mit einem konkreten Nachweis, dem damit verbundenen Betriebsrisiko und dem erkennbaren Nutzen für die Unternehmenssteuerung verknüpfen.
Begrenzte Aussagekraft allgemeiner Feature-Listen
RFPs für Datenschutz-, Compliance- und Integrated-Risk-Management-Software enthalten häufig umfangreiche Funktionskataloge. Abgefragt wird etwa, ob Workflows, Reporting-Funktionen, Dashboards, Rollenmodelle, Exporte, APIs, Mehrsprachigkeit oder Audit Trails vorhanden sind.
In der Praxis führt dieses Vorgehen häufig dazu, dass nahezu alle Anbieter einen großen Teil der Anforderungen formal erfüllen. Die Ergebnisse liegen eng beieinander, obwohl sich die Lösungen im späteren Betrieb erheblich unterscheiden können.
Der Grund hierfür liegt weniger in der Anzahl der abgefragten Funktionen als in der Abstraktion der verwendeten Begriffe. Ein allgemeiner Feature-Haken lässt regelmäßig keine belastbare Aussage darüber zu, wie umfassend, konfigurierbar und betriebstauglich die jeweilige Funktion tatsächlich ausgestaltet ist.
Dies zeigt sich beispielsweise beim Begriff „Workflow“. Darunter kann sowohl eine einfache E-Mail-Benachrichtigung als auch ein konfigurierbarer Prozess mit Rollen, Bedingungen, Fristen, Eskalationen, Wiedervorlagen, Entscheidungspunkten und Audit Trail verstanden werden. Werden beide Ausprägungen in einer Bewertungsmatrix lediglich als „Workflow vorhanden“ erfasst, entsteht eine Vergleichbarkeit, die den tatsächlichen Leistungsumfang nur unzureichend abbildet.
Auswahlentscheidungen großer Unternehmen
Große Unternehmen beschaffen Governance-Software regelmäßig nicht nur für einen einzelnen Nutzer oder einen isolierten Prozess. Die Lösung muss vielmehr in ein bestehendes organisatorisches und technisches Betriebsmodell eingeordnet werden.
Zu berücksichtigen sind dabei unter anderem mehrere Fachbereiche, Regionen, Gesellschaften, Rollen, Sprachen und regulatorische Anforderungen. Hinzu kommen wechselnde Zuständigkeiten, Anforderungen an die Auditfähigkeit, Import- und Exportmöglichkeiten, Berechtigungskonzepte sowie die Notwendigkeit, Prozesse auch bei veränderten rechtlichen oder organisatorischen Rahmenbedingungen weiterzuentwickeln.
Vor diesem Hintergrund reicht die Frage, ob eine Software eine bestimmte Funktion grundsätzlich bereitstellt, für die Bewertung nicht aus. Zu prüfen ist vielmehr, ob die Organisation den zugrunde liegenden Prozess mit der Lösung dauerhaft, nachvollziehbar und skalierbar steuern kann.
Der Bewertungsmaßstab verschiebt sich damit von der bloßen Funktionsoberfläche auf die mit dem späteren Betrieb verbundenen Risiken und Anforderungen.
Steuerbarkeit in Governance-Lösungen
Steuerbarkeit bedeutet, dass eine Organisation Informationen nicht nur dokumentiert, sondern Vorgänge anhand definierter Zuständigkeiten, Prüfungen und Entscheidungen verlässlich bearbeiten kann.
Am Beispiel eines Verzeichnisses von Verarbeitungstätigkeiten lässt sich dieser Unterschied nachvollziehen. Eine rein funktionsbezogene Bewertung würde insbesondere danach fragen,
- ob Verarbeitungstätigkeiten erfasst werden können,
- ob Pflichtfelder vorhanden sind und
- ob sich Berichte exportieren lassen.
Eine stärker betriebsbezogene Bewertung berücksichtigt darüber hinaus,
- wer eine Verarbeitungstätigkeit anlegen darf,
- welche Informationen vor einer Prüfung vollständig vorliegen müssen,
- zu welchem Zeitpunkt der Datenschutzbeauftragte einzubinden ist,
- wer die fachliche Verantwortung trägt,
- welche Änderungen eine erneute Prüfung auslösen,
- wie offene Maßnahmen nachverfolgt werden,
- wie Freigaben dokumentiert werden,
- welche Version zu welchem Zeitpunkt maßgeblich war,
- welche Gesellschaft oder Region auf welche Informationen zugreifen darf,
- wie ein Nachweis für ein Audit erzeugt wird und
- wie das System reagiert, wenn der zuständige Owner nicht innerhalb der vorgesehenen Frist tätig wird.
Im ersten Fall wird im Wesentlichen die Erfassung eines Datensatzes bewertet. Im zweiten Fall steht die Frage im Vordergrund, ob der zugrunde liegende Governance-Prozess im laufenden Betrieb verlässlich umgesetzt werden kann.
Bedeutung von KO-Kriterien
Viele RFP-Bewertungen behandeln Anforderungen weitgehend gleich. Eine Komfortfunktion kann dabei ähnlich gewichtet werden wie ein wesentliches Berechtigungs-, Integrations- oder Exportproblem. Dies kann dazu führen, dass eine wesentliche Schwäche durch mehrere weniger bedeutsame Funktionen rechnerisch ausgeglichen wird.
Für bestimmte Anforderungen ist ein solcher Ausgleich jedoch regelmäßig nicht sachgerecht.
Kann eine Lösung beispielsweise Mandanten, Gesellschaften oder sensible Daten nicht hinreichend trennen, dürfte ein zusätzliches Dashboard diesen Mangel nicht kompensieren. Entsprechendes gilt bei unvollständigen Audit Trails, unzureichenden Exportmöglichkeiten oder fehlender Datenportabilität. Auch die Frage, ob zentrale Prozesse nur durch kundenspezifische Entwicklung angepasst werden können, betrifft unmittelbar die späteren Kosten, die Reaktionsgeschwindigkeit und die Abhängigkeit vom Anbieter.
RFPs sollten deshalb zunächst solche Anforderungen bestimmen, deren Nichterfüllung zu einem Ausschluss führt.
Als KO-Kriterien kommen insbesondere in Betracht:
- Informationssicherheits- und Hosting-Anforderungen,
- Datenstandort,
- Rollen- und Berechtigungsmodell,
- Mandanten- oder Gesellschaftstrennung,
- Audit Trail,
- Exportierbarkeit und Datenportabilität,
- Integrationsfähigkeit,
- regulatorisch erforderliche Nachweise,
- Skalierbarkeit,
- Verfügbarkeit und Support,
- vertragliche Mindestanforderungen sowie
- definierte Exit-Möglichkeiten.
Erst wenn diese Mindestanforderungen erfüllt sind, sollte eine weitergehende differenzierte Punktebewertung erfolgen.
Abgrenzung von Must-haves und Differenzierungsmerkmalen
Standardfunktionen sollten in einer Bewertungsmatrix nicht übergewichtet werden. Dass eine Privacy-Management-Lösung ein Verzeichnis von Verarbeitungstätigkeiten abbilden kann, stellt regelmäßig eine Grundvoraussetzung dar. Vergleichbares gilt für die Anlage von Nutzern oder die Ausgabe einfacher PDF-Berichte.
Wer solche Must-haves mit hohen Punktwerten versieht, erhöht die Wahrscheinlichkeit rechnerischer Gleichstände, ohne die tatsächlichen Unterschiede zwischen den Lösungen hinreichend abzubilden.
Differenzierungsmerkmale zeigen sich vielmehr bei Fragen wie:
- In welchem Umfang lässt sich das Datenmodell anpassen?
- Können Fachbereiche auf die Informationen beschränkt werden, die sie für ihre Aufgaben benötigen?
- Lassen sich Prozesse ohne Softwareentwicklung verändern?
- Können mehrere Governance-Bereiche gemeinsame Objekte nutzen?
- Wie werden Beziehungen zwischen Verarbeitungstätigkeiten, Risiken, Dienstleistern, Systemen und Maßnahmen abgebildet?
- Sind Freigaben mit Bedingungen und Wiedervorlagen möglich?
- Können Eskalationen anhand von Fristen oder Risiken ausgelöst werden?
- Ist der Entscheidungspfad vollständig nachvollziehbar?
- Wie schnell lassen sich neue regulatorische Anforderungen abbilden?
- Können interne Teams die Lösung später selbst weiterentwickeln?
Diese Fragen betreffen weniger das Vorhandensein einzelner Funktionen als die Plattform- und Betriebsfähigkeit der Lösung.
Nachweise als Bestandteil der Bewertung
Die bloße Angabe, eine Funktion sei vorhanden, sollte bei kritischen Anforderungen nicht ausreichen. Vielmehr ist regelmäßig ein konkreter Nachweis zu verlangen.
Gibt ein Anbieter beispielsweise an, über ein flexibles Rollenmodell zu verfügen, sollte dies anhand eines realistischen Anwendungsszenarios überprüft werden. Ein solcher Fall könnte vorsehen, dass ein Fachbereich ausschließlich seine eigenen Verarbeitungstätigkeiten bearbeiten darf, während der Datenschutzbeauftragte alle relevanten Vorgänge prüfen kann. Ein regionaler Ansprechpartner erhält nur Zugriff auf die ihm zugeordnete Gesellschaft. Legal kann Vertragsprüfungen einsehen, ohne automatisch Zugriff auf sämtliche Beschäftigtendaten zu erhalten. Das Management sieht Statusinformationen und Risiken, jedoch nicht zwingend jedes operative Detail.
Im Rahmen der Bewertung ist dann zu prüfen,
- ob der Anbieter dieses Szenario tatsächlich konfigurieren kann,
- wie Rechte vererbt werden,
- wie Änderungen dokumentiert werden und
- ob der Kunde entsprechende Anpassungen später selbst vornehmen kann.
Erst durch einen solchen Nachweis wird aus einer allgemeinen Funktionsaussage eine belastbare Bewertungsgrundlage.
| Allgemeine Feature-Frage | Belastbarere RFP-Frage | Erwarteter Nachweis |
|---|---|---|
| Gibt es Workflows? | Können Prozesse mit Rollen, Fristen, Bedingungen, Freigaben, Wiedervorlagen und Eskalationen konfiguriert werden? | Live-Demonstration eines vollständigen Freigabeprozesses. |
| Gibt es ein Rollenmodell? | Können Zugriffe objekt-, rollen-, gesellschafts- und prozessbezogen gesteuert werden? | Konfiguration eines realistischen Berechtigungsszenarios. |
| Gibt es Reporting? | Können Management, Audit und Fachbereiche unterschiedliche Berichte aus denselben strukturierten Daten erhalten? | Drei zielgruppenspezifische Reports aus einem Vorgang. |
| Gibt es einen Audit Trail? | Werden Änderungen, Entscheidungen, Rollen, Zeitpunkte und frühere Werte nachvollziehbar dokumentiert? | Anzeige einer vollständigen Änderungshistorie. |
| Gibt es Exporte? | Können Kunden ihre Daten vollständig, strukturiert und ohne vermeidbare Herstellerabhängigkeit exportieren? | Beispiel eines vollständigen Datenexports. |
| Gibt es APIs? | Welche Objekte, Aktionen und Ereignisse sind über dokumentierte Schnittstellen verfügbar? | API-Dokumentation und konkreter Integrationsfall. |
| Ist das System konfigurierbar? | Welche Änderungen kann der Kunde selbst durchführen, ohne Herstellerentwicklung zu beauftragen? | Live-Anpassung eines Objekts und eines Workflows. |
| Unterstützt die Lösung RoPA? | Wie werden Verarbeitungstätigkeiten, Systeme, Dienstleister, Risiken, TOMs, Rechtsgrundlagen und Freigaben miteinander verbunden? | Darstellung eines zusammenhängenden Governance-Modells. |
| Gibt es Aufgaben? | Können Aufgaben automatisch ausgelöst, zugewiesen, eskaliert und nachverfolgt werden? | Prozess mit Fristüberschreitung und Eskalation. |
| Unterstützt die Lösung Mehrsprachigkeit? | Sind Oberfläche, Inhalte, Datenfelder und Berichte mehrsprachig nutzbar? | Darstellung desselben Vorgangs in mehreren Sprachen. |
Die Beantwortung solcher Fragen ist für Anbieter aufwendiger. Sie ermöglicht jedoch eine belastbarere Beurteilung der jeweiligen Lösung.
Einheitliche Skripte für Produktdemonstrationen
Eine freie Produktdemonstration ist für die Auswahl nur eingeschränkt geeignet. Anbieter werden regelmäßig diejenigen Funktionen zeigen, in denen ihre jeweilige Lösung besonders leistungsfähig ist. Dies kann ein Dashboard, eine Nutzeroberfläche oder ein bestimmtes Berichtssystem sein.
Für die Vergleichbarkeit ist damit nur begrenzt etwas gewonnen, da nicht alle Anbieter denselben Anwendungsfall bearbeiten.
Eine RFP-Demonstration sollte deshalb auf einem einheitlichen Skript beruhen. Ein solches Szenario kann beispielsweise folgende Schritte enthalten:
- Ein Fachbereich meldet eine neue Verarbeitungstätigkeit an.
- Pflichtinformationen fehlen.
- Der Vorgang wird an den zuständigen Owner zurückgegeben.
- Aufgrund bestimmter Antworten wird eine Datenschutzprüfung ausgelöst.
- Ein Dienstleister wird zugeordnet.
- Ein Risiko wird bewertet.
- Eine Maßnahme wird angelegt.
- Die Freigabe erfolgt unter Bedingungen.
- Nach sechs Monaten wird eine Wiedervorlage ausgelöst.
- Ein Auditor fordert den vollständigen Entscheidungspfad an.
Jeder Anbieter sollte denselben Fall vollständig darstellen. Dabei ist nicht nur das Ergebnis zu bewerten. Zu berücksichtigen sind insbesondere folgende Fragen:
- Wie viele manuelle Schritte sind erforderlich?
- An welchen Stellen entstehen Medienbrüche?
- Welche Informationen müssen mehrfach gepflegt werden?
- Wie nachvollziehbar ist der jeweilige Bearbeitungsstatus?
- Wie lassen sich Abweichungen konfigurieren?
- Welche Anpassungen erfordern Unterstützung durch den Hersteller?
- Welche Nachweise entstehen automatisiert?
Durch ein solches Vorgehen wird die Produktdemonstration zu einem Bestandteil der fachlichen und betrieblichen Prüfung.
Anpassungsabhängigkeit als Kostenfaktor
Der in einer Ausschreibung ausgewiesene Lizenzpreis bildet die tatsächlichen Kosten einer Governance-Lösung regelmäßig nur teilweise ab.
Weitere Aufwände können insbesondere entstehen durch:
- kundenspezifische Entwicklung,
- technische Anpassungen,
- Beratung,
- Datenmigration,
- Integrationen,
- Berichte,
- Schulungen,
- Release-Anpassungen,
- Tests,
- Support und
- einen späteren Anbieterwechsel.
Von besonderer Bedeutung ist deshalb die Frage, in welchem Umfang die Organisation die Lösung selbst anpassen kann.
Regulatorische und organisatorische Prozesse bleiben nicht unverändert. Unternehmen reorganisieren Zuständigkeiten, nehmen neue Gesellschaften auf oder verändern interne Prüf- und Freigabewege. Hinzu kommen neue Felder, Berichte und fachliche Anforderungen.
Muss jede Anpassung als Entwicklungsprojekt beauftragt werden, wirkt sich dies regelmäßig auf Kosten, Dauer und Herstellerabhängigkeit aus. Konfigurierbarkeit ist deshalb nicht lediglich als Komfortfunktion zu bewerten, sondern als wirtschaftlich relevantes Merkmal des Betriebsmodells.
Bewertung der Plattformfähigkeit
Eine spezialisierte RoPA-Anwendung kann ein Verzeichnis von Verarbeitungstätigkeiten fachlich umfassend abbilden. Große Unternehmen haben jedoch regelmäßig weitere Governance-Anforderungen.
Hierzu können gehören:
- Datenschutz-Folgenabschätzungen,
- Dienstleisterprüfungen,
- Transferbewertungen,
- Risiken und Maßnahmen,
- Betroffenenanfragen,
- Incident Management,
- AI Governance,
- Informationssicherheitsmanagement,
- Richtlinien,
- Freigaben und
- Audit Management.
Werden diese Prozesse jeweils in getrennten Anwendungen betrieben, können neue Datensilos und Mehrfachpflege entstehen. Systeme, Dienstleister, Risiken und Verantwortliche müssen dann gegebenenfalls in mehreren Lösungen unabhängig voneinander erfasst werden.
Plattformfähigkeit zeigt sich deshalb insbesondere darin, ob gemeinsame Governance-Objekte bereichsübergreifend genutzt werden können. Ein Dienstleister sollte nicht zwingend für Datenschutz, AI Governance und Informationssicherheit mehrfach erfasst werden müssen. Risiken sollten mit den jeweils betroffenen Prozessen, Maßnahmen und Kontrollen verknüpft werden können. Ein KI-Anwendungsfall kann mit Verarbeitungstätigkeit, Anbieter, Modell, Datenschutzprüfung, Security Review und Freigabe verbunden werden.
In dieser Verknüpfung liegt der Unterschied zwischen einer isolierten Fachanwendung und einer Governance-Plattform.
Aufbau einer Bewertungsmatrix
Eine belastbare Bewertungsmatrix sollte vier Ebenen miteinander verknüpfen:
Funktion – Nachweis – Betriebsrisiko – Managementnutzen
1. Funktion
Zunächst ist zu bestimmen, welche technische oder fachliche Fähigkeit benötigt wird.
Beispiel: konfigurierbare Freigabeworkflows.
2. Nachweis
Anschließend ist festzulegen, wie der Anbieter das tatsächliche Vorhandensein dieser Fähigkeit nachweist.
Beispiel: Live-Konfiguration eines Freigabeprozesses mit zwei Reviewer-Rollen, Bedingungen und Eskalation.
3. Betriebsrisiko
Weiter ist zu bewerten, welches Risiko entsteht, wenn die Fähigkeit fehlt oder nur eingeschränkt vorhanden ist.
Beispiel: Entscheidungen verbleiben in E-Mails, Fristen werden übersehen und Freigaben sind später nicht vollständig nachvollziehbar.
4. Managementnutzen
Schließlich sollte berücksichtigt werden, welchen operativen oder strategischen Nutzen die Fähigkeit für die Organisation hat.
Beispiel: kürzere Durchlaufzeiten, geringerer manueller Abstimmungsaufwand, bessere Auditfähigkeit und geringere Abhängigkeit vom Hersteller.
Erst die Verbindung dieser vier Ebenen ermöglicht eine Bewertung, die über die bloße Erfassung einzelner Funktionen hinausgeht.
| Bewertungskriterium | Nachweis | Betriebsrisiko bei Schwäche | Managementnutzen | Gewichtung |
|---|---|---|---|---|
| Rollen und Berechtigungen | Realistisches Berechtigungsszenario | Unzulässige Zugriffe, fehlende Trennung, hoher Administrationsaufwand | Sichere Delegation und skalierbarer Betrieb | 10 % |
| Workflow-Konfiguration | Live-Prozess mit Bedingungen und Eskalation | E-Mail-Prozesse, Fristversäumnisse, manuelle Nachverfolgung | Kürzere Durchlaufzeiten und eindeutige Verantwortlichkeiten | 12 % |
| Datenmodell und Beziehungen | Verknüpfung von Verarbeitungstätigkeit, System, Dienstleister und Risiko | Doppelte Pflege und fehlender fachlicher Kontext | Einheitliche Governance-Sicht | 10 % |
| Audit Trail | Vollständige Änderungshistorie | Entscheidungen sind nicht hinreichend nachvollziehbar | Auditfähigkeit und Rechenschaft | 8 % |
| Reporting und Exporte | Management-, Audit- und operativer Bericht | Manuelle Berichterstellung | Schnellere Steuerung und belastbare Nachweise | 8 % |
| Konfigurierbarkeit | Anpassung durch das Kundenteam | Herstellerabhängigkeit und hohe Folgekosten | Schnellere Anpassung und geringere Betriebskosten | 12 % |
| Integration und API | Konkreter Integrationsfall | Medienbrüche und doppelte Datenpflege | Automatisierung und höhere Datenqualität | 8 % |
| Datenmigration | Mapping-, Test- und Validierungskonzept | Datenverlust, Verzögerungen und geringe Akzeptanz | Strukturierter Projektstart | 8 % |
| Informationssicherheit | Technische und organisatorische Nachweise | Sicherheits- und Compliance-Risiken | Vertrauenswürdiger Betrieb | KO / 10 % |
| Betriebsmodell und Support | SLA, Supportstruktur und Releaseprozess | Verzögerte Problemlösung und Projektabhängigkeit | Planbarkeit und Betriebssicherheit | 7 % |
| Plattformfähigkeit | Nutzung gemeinsamer Objekte über mehrere Lösungen | Entstehung zusätzlicher Governance-Silos | Erweiterbarkeit und Investitionsschutz | 7 % |
Die konkrete Gewichtung ist an den Anforderungen des jeweiligen Unternehmens auszurichten. Maßgeblich ist, dass sie die tatsächliche betriebliche Relevanz der Kriterien abbildet.
Steuerbarkeit als Bestandteil des wirtschaftlichen Nutzens
Der Return on Investment von Governance-Software wird häufig auf die Zeitersparnis bei einzelnen Dokumentationsaufgaben reduziert. Beispielsweise wird danach gefragt, wie viele Arbeitsstunden sich bei der Erstellung eines RoPA-Berichts einsparen lassen.
Diese Betrachtung ist sinnvoll, bildet den wirtschaftlichen Nutzen jedoch nicht vollständig ab. Ein wesentlicher Teil des Nutzens kann in der verbesserten Steuerbarkeit der zugrunde liegenden Prozesse liegen.
Dies betrifft insbesondere folgende Aspekte:
- Fachbereiche wissen, welche Informationen und Tätigkeiten von ihnen erwartet werden.
- Verantwortlichkeiten bleiben sichtbar.
- Prüfungen werden zu den vorgesehenen Zeitpunkten ausgelöst.
- Fristen und Maßnahmen können nachverfolgt werden.
- Entscheidungen bleiben dokumentiert.
- Das Management erhält einen belastbaren Überblick.
- Auditnachweise entstehen bereits während des laufenden Prozesses.
- Neue regulatorische Anforderungen lassen sich schneller abbilden.
- Wissen verbleibt im System und nicht ausschließlich in den Postfächern einzelner Personen.
Dieser Nutzen ist regelmäßig schwieriger in einer einzelnen Kennzahl auszudrücken als die reine Zeitersparnis. Für die Organisation kann er dennoch wirtschaftlich bedeutsamer sein.
Eine Lösung, die lediglich Berichte schneller erzeugt, verbessert zunächst eine administrative Aufgabe. Eine Lösung, die Rollen, Risiken, Entscheidungen und Nachweise miteinander verbindet, kann darüber hinaus die Governance-Fähigkeit der Organisation unterstützen.
Prüfpunkte für Procurement
Procurement berücksichtigt regelmäßig Preis, Vertrag, Leistungsbeschreibung und Leistungsfähigkeit des Anbieters. Bei Governance-Plattformen sollten zusätzlich einige betriebliche Fragen geprüft werden:
- Welche Leistungen sind im Standardumfang enthalten?
- Welche Funktionen erfordern Zusatzmodule?
- Welche Anpassungen gelten als Konfiguration und welche als Entwicklung?
- Wer ist berechtigt, Konfigurationen vorzunehmen?
- Welche Kosten entstehen für Herstellerunterstützung?
- Wie sind Release- und Updateprozesse ausgestaltet?
- Bleiben kundenspezifische Konfigurationen bei Updates erhalten?
- Welche Exportmöglichkeiten bestehen?
- Wie ist ein späterer Exit geregelt?
- Welche Kosten entstehen bei zusätzlichem Datenvolumen, weiteren Nutzern, Gesellschaften oder Modulen?
- Welche Leistungen hängen von einem Implementierungspartner ab?
- Welche Roadmap-Zusagen sind vertraglich verbindlich und welche stellen lediglich Absichtserklärungen dar?
Der niedrigste Lizenzpreis stellt nicht zwingend das wirtschaftlichste Angebot dar. Die langfristigen Kosten werden in erheblichem Umfang durch das Betriebsmodell und die Anpassungsfähigkeit der Lösung bestimmt.
Prüfpunkte für Legal und Datenschutz
Legal und Datenschutz sollten nicht ausschließlich die Verträge oder die fachlichen Inhalte einzelner Module bewerten. Zu prüfen ist auch, ob die Plattform die erforderliche Nachweisfähigkeit unterstützt.
Hierzu gehören insbesondere:
- eindeutige Verantwortlichkeiten,
- dokumentierte Freigaben,
- rechtzeitige Einbindung relevanter Rollen,
- Versionierung,
- definierte Geltungsbereiche,
- nachvollziehbare Änderungen,
- Berücksichtigung fachlicher Empfehlungen,
- dokumentierte Risikoakzeptanzen,
- offene Maßnahmen,
- Wiedervorlagen und
- Datenportabilität.
Eine Governance-Lösung sollte nicht nur einzelne Aussagen oder Ergebnisse speichern. Sie sollte auch nachvollziehbar abbilden können, wie eine Entscheidung zustande gekommen ist.
Prüfpunkte für CIO und IT
Für CIO und IT stehen regelmäßig technische und betriebliche Anforderungen im Vordergrund. Zu prüfen sind insbesondere folgende Punkte:
- Passt die Architektur in die bestehende Unternehmenslandschaft?
- Wie flexibel ist das Integrationsmodell?
- Wie werden Identitäten und Rollen angebunden?
- Welche APIs und Ereignisse stehen zur Verfügung?
- Wie werden Konfigurationen transportiert und getestet?
- Wie ist die Mandanten- oder Gesellschaftstrennung ausgestaltet?
- Wie werden Releases betrieben?
- Welche Datenbanken und Technologien sind relevant?
- Wie werden Monitoring, Logging und Verfügbarkeit sichergestellt?
- In welchem Umfang besteht eine Abhängigkeit vom Hersteller oder vom Implementierungspartner?
Eine Plattform kann einen großen Funktionsumfang aufweisen und dennoch mit erheblichem Betriebsaufwand verbunden sein. Die technische Bewertung sollte deshalb nicht auf die Anzahl der Funktionen beschränkt werden.
Einordnung von Ailance
Ailance sollte im Rahmen einer Ausschreibung nicht danach bewertet werden, wie viele allgemeine Feature-Haken in einer Liste gesetzt werden können. Maßgeblich ist vielmehr, ob die Plattform die Governance-Logik und das Betriebsmodell des jeweiligen Kunden abbilden kann.
Ailance verbindet nach dem hier beschriebenen Plattformansatz:
- konfigurierbare Governance-Objekte,
- Beziehungen zwischen Daten,
- Rollen und Berechtigungen,
- Workflows,
- Prüfungen und Freigaben,
- Risiken und Maßnahmen,
- Berichte und Dashboards,
- Audit Trails sowie
- APIs und Integrationen.
Dieser Ansatz kann insbesondere für Unternehmen relevant sein, die mehrere Governance-Bereiche auf einer gemeinsamen Grundlage abbilden möchten.
Ailance RoPA beschränkt sich nicht auf die Dokumentation von Verarbeitungstätigkeiten. Verarbeitungstätigkeiten können mit Systemen, Dienstleistern, Risiken, technischen und organisatorischen Maßnahmen, Rechtsgrundlagen, Freigaben, offenen Maßnahmen und Einschätzungen des Datenschutzbeauftragten verbunden werden.
Für die Bewertung ist deshalb zu prüfen, ob aus diesen Verknüpfungen ein steuerbarer Governance-Prozess entsteht und ob dieser den organisatorischen Anforderungen des jeweiligen Unternehmens entspricht.
Überprüfung der eigenen RFP-Matrix
Unternehmen sollten bestehende Bewertungsmatrizen insbesondere bei allgemein formulierten Anforderungen überprüfen.
Bei einer Zeile wie „Workflow vorhanden“ ist beispielsweise festzulegen, welche konkrete Leistung ein Anbieter erbringen muss, um die volle Punktzahl zu erhalten. Zu klären ist, ob eine allgemeine Funktionsbestätigung ausreicht oder ob der Anbieter zeigen muss, wie Rollen, Fristen, Bedingungen, Eskalationen, Freigaben und Nachweise zusammenwirken.
Ist dies aus der Bewertungsmatrix nicht eindeutig erkennbar, werden möglicherweise eher Begriffe als tatsächlich nachgewiesene Fähigkeiten bewertet.
Fazit
Bei der Auswahl von Governance-Software reicht eine Bewertung anhand allgemeiner Feature-Listen regelmäßig nicht aus.
Eine belastbare RFP-Logik sollte zunächst KO-Kriterien bestimmen und anschließend zwischen Grundvoraussetzungen und tatsächlichen Differenzierungsmerkmalen unterscheiden. Kritische Anforderungen sollten durch konkrete Nachweise belegt werden. Darüber hinaus sind Betriebsrisiken, Folgekosten, Anpassungsabhängigkeiten und das zugrunde liegende Betriebsmodell zu berücksichtigen.
Die maßgebliche Frage lautet deshalb nicht allein, ob eine Software einen Workflow bereitstellt. Zu prüfen ist vielmehr, ob die Organisation mit diesem Workflow Rollen, Entscheidungen, Risiken, Eskalationen und Nachweise dauerhaft und nachvollziehbar steuern kann.
Ein Feature-Haken dokumentiert zunächst nur, dass ein Anbieter eine Anforderung formal bestätigt hat. Ob die zugrunde liegende organisatorische Aufgabe damit im späteren Betrieb erfüllt werden kann, bedarf einer weitergehenden Prüfung.
Fragen und Antworten
Wie bewertet man Privacy-IRM-Software in einer RFP-Ausschreibung?
Die Bewertung sollte KO-Kriterien, fachliche Fähigkeiten, technische Voraussetzungen, konkrete Nachweise, Betriebsrisiken und den Nutzen für die Unternehmenssteuerung miteinander verbinden. Allgemeine Feature-Haken reichen hierfür regelmäßig nicht aus.
Welche KO-Kriterien sind bei Privacy-IRM-Software wichtig?
Als KO-Kriterien kommen insbesondere Informationssicherheit, Datenstandort, Rollen- und Berechtigungsmodell, Audit Trail, Datenportabilität, Integrationsfähigkeit, Skalierbarkeit, Support und vertragliche Mindestanforderungen in Betracht.
Warum sind Feature-Listen nicht ausreichend?
Anbieter verwenden dieselben Begriffe teilweise für sehr unterschiedliche Funktionsumfänge. Ein Workflow kann beispielsweise eine einfache Benachrichtigung oder einen umfassend konfigurierbaren Governance-Prozess bezeichnen.
Wie sollten Produktdemonstrationen im RFP-Verfahren durchgeführt werden?
Alle Anbieter sollten ein einheitlich vorgegebenes Szenario bearbeiten. Dadurch lassen sich Prozessqualität, Bedienbarkeit, Konfigurierbarkeit, Medienbrüche und Nachweisfähigkeit besser vergleichen.
Was ist der Unterschied zwischen Must-have und Differenzierungsmerkmal?
Ein Must-have ist eine Grundvoraussetzung, etwa die Erfassung von Verarbeitungstätigkeiten. Ein Differenzierungsmerkmal zeigt, wie flexibel, skalierbar und steuerbar die Lösung im laufenden Betrieb eingesetzt werden kann.
Warum ist Konfigurierbarkeit relevant?
Governance-Prozesse verändern sich regelmäßig. Erfordert jede Anpassung eine Herstellerentwicklung, können Kosten, Dauer und Abhängigkeit steigen. Konfigurierbarkeit kann diese Risiken verringern.
Was bedeutet Plattformfähigkeit bei Governance-Software?
Plattformfähigkeit bedeutet, dass mehrere Governance-Prozesse gemeinsame Objekte, Rollen und Daten nutzen können. Dadurch lassen sich zusätzliche Datensilos und mehrfache Datenpflege vermeiden.
Welche Nachweise sollte ein Anbieter im RFP-Verfahren erbringen?
Kritische Anforderungen sollten anhand konkreter Szenarien demonstriert werden. Dies betrifft beispielsweise Rollenmodelle, Freigabeworkflows, Eskalationen, Audit Trails, Datenexporte, Integrationen und Konfigurationsänderungen.
Wie lässt sich der ROI einer Governance-Plattform bewerten?
Neben der Zeitersparnis sollten geringere Abstimmungsaufwände, schnellere Entscheidungen, bessere Auditfähigkeit, geringere Herstellerabhängigkeit, höhere Datenqualität und eine verbesserte Managementsteuerung berücksichtigt werden.
Welche Bedeutung hat das Betriebsmodell?
Das Betriebsmodell bestimmt, wie eine Lösung administriert, angepasst, integriert, unterstützt und weiterentwickelt wird. Es kann die langfristigen Kosten stärker beeinflussen als der reine Lizenzpreis.
Wie kann Ailance RoPA die Steuerbarkeit unterstützen?
Ailance RoPA verbindet Verarbeitungstätigkeiten mit Systemen, Dienstleistern, Risiken, technischen und organisatorischen Maßnahmen, Rechtsgrundlagen, offenen Maßnahmen, Verantwortlichen, Freigaben und Nachweisen. Damit kann die Lösung über die Funktion eines rein elektronischen Verzeichnisses hinausgehen.
Welche Frage sollte in einer RFP besonders berücksichtigt werden?
Von besonderer Bedeutung ist die Frage, welche Änderungen das Unternehmen später selbst vornehmen kann, ohne hierfür ein zusätzliches Entwicklungs- oder Beratungsprojekt beauftragen zu müssen.
German 
English 
Italian 
French