Short Answer
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.
Limited Informativeness of General Feature Lists
RFPs for data protection, Compliance- and integrated risk management software often include extensive feature sets. For example, users may inquire about whether the software offers workflows, reporting functions, dashboards, role models, export options, APIs, multilingual support, or Audit Trails are available.
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.
This is evident, for example, in the term „workflow.“ It can refer to anything from a simple email notification to a configurable process with roles, conditions, deadlines, escalations, follow-ups, decision points, and Audit Trail. If both variants are simply recorded in an evaluation matrix as „workflow in place,“ this creates a basis for comparison that does not adequately reflect the actual scope of services.
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,
- whether there are required fields and
- whether reports can be exported.
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,
- at what point the data protection officer should be involved,
- wer die fachliche Verantwortung trägt,
- welche Änderungen eine erneute Prüfung auslösen,
- wie offene Maßnahmen nachverfolgt werden,
- how approvals are documented,
- welche Version zu welchem Zeitpunkt maßgeblich war,
- which company or region is allowed to access which information,
- as proof of a Audit is produced and
- 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.
Importance of Elimination Criteria
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.
If, for example, a solution cannot adequately segregate clients, companies, or sensitive data, an additional dashboard is unlikely to compensate for this shortcoming. The same applies to incomplete Audit Trails, insufficient export capabilities, or a lack of data portability. The question of whether core processes can only be customized through client-specific development also directly affects future costs, response times, and dependence on the vendor.
RFPs sollten deshalb zunächst solche Anforderungen bestimmen, deren Nichterfüllung zu einem Ausschluss führt.
The following are considered elimination criteria in particular:
- Information security and hosting requirements,
- Data location,
- Role and Permission Model,
- Client or corporate separation,
- Audit Trail,
- Exportierbarkeit und Datenportabilität,
- Integrationsfähigkeit,
- documentation required by regulations,
- Scalability,
- Availability and support,
- minimum contractual requirements, as well as
- definierte Exit-Möglichkeiten.
Erst wenn diese Mindestanforderungen erfüllt sind, sollte eine weitergehende differenzierte Punktebewertung erfolgen.
Distinguishing Between Must-Haves and Differentiating Features
Standardfunktionen sollten in einer Bewertungsmatrix nicht übergewichtet werden. Dass eine Privacy-Management-Lösung ein Record of Processing Activities 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.
Instead, distinguishing features become apparent in questions such as:
- 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?
- How quickly can new regulatory requirements be implemented?
- 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.
Supporting Documentation as Part of the Evaluation
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 to receive. Management sees status information and risks, but not necessarily every operational detail.
Im Rahmen der Bewertung ist dann zu prüfen,
- ob der Anbieter dieses Szenario tatsächlich konfigurieren kann,
- how rights are inherited,
- wie Änderungen dokumentiert werden und
- ob der Kunde entsprechende Anpassungen später selbst vornehmen kann.
Only through such evidence can a general statement about functionality become a reliable basis for evaluation.
| General Feature Question | A More Robust RFP Question | Expected Evidence |
|---|---|---|
| Are there any workflows? | Können Prozesse mit Rollen, Fristen, Bedingungen, Freigaben, Wiedervorlagen und Eskalationen konfiguriert werden? | Live-Demonstration eines vollständigen Freigabeprozesses. |
| Is there a role model? | Können Zugriffe objekt-, rollen-, gesellschafts- und prozessbezogen gesteuert werden? | Configuring a realistic authorization scenario. |
| Is there a reporting feature? | Can management, Audit and can different departments receive different reports based on the same structured data? | Three reports tailored to specific target groups from a single process. |
| Is there a Audit Trail? | Werden Änderungen, Entscheidungen, Rollen, Zeitpunkte und frühere Werte nachvollziehbar dokumentiert? | Anzeige einer vollständigen Änderungshistorie. |
| Are there any exports? | Können Kunden ihre Daten vollständig, strukturiert und ohne vermeidbare Herstellerabhängigkeit exportieren? | Beispiel eines vollständigen Datenexports. |
| Are there any APIs? | Welche Objekte, Aktionen und Ereignisse sind über dokumentierte Schnittstellen verfügbar? | API-Documentation and a specific case of integration. |
| Is the system configurable? | Welche Änderungen kann der Kunde selbst durchführen, ohne Herstellerentwicklung zu beauftragen? | Live customization of an object and a workflow. |
| Unterstützt die Lösung RoPA? | Wie werden Verarbeitungstätigkeiten, Systeme, Dienstleister, Risiken, TOMs, Legal basis and shares are linked to each other? | Darstellung eines zusammenhängenden Governance-Modells. |
| Are there any assignments? | 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? | Presentation of the same process in multiple languages. |
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.
An RFP demonstration should therefore be based on a standardized script. Such a scenario might include the following steps, for example:
- Ein Fachbereich meldet eine neue Verarbeitungstätigkeit an.
- Required information is missing.
- Der Vorgang wird an den zuständigen Owner zurückgegeben.
- Aufgrund bestimmter Antworten wird eine Datenschutzprüfung ausgelöst.
- A service provider is assigned.
- A risk is being assessed.
- Eine Maßnahme wird angelegt.
- The approval is subject to certain conditions.
- 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:
- How many manual steps are required?
- An welchen Stellen entstehen Medienbrüche?
- Welche Informationen müssen mehrfach gepflegt werden?
- How easy is it to understand the current processing status?
- How can deviations be configured?
- Welche Anpassungen erfordern Unterstützung durch den Hersteller?
- Which documents are generated automatically?
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:
- custom development,
- technical adjustments,
- Consulting,
- Data migration,
- Integrations,
- Reports,
- Training courses,
- Release adjustments,
- Tests,
- Support and
- 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
A specialized RoPA application can be a Record of Processing Activities fachlich umfassend abbilden. Große Unternehmen haben jedoch regelmäßig weitere Governance-Anforderungen.
Hierzu können gehören:
- Datenschutz-Folgenabschätzungen,
- Dienstleisterprüfungen,
- Transfer valuations,
- Risiken und Maßnahmen,
- Inquiries from affected individuals,
- Incident Management,
- AI Governance,
- Information Security Management,
- Guidelines,
- Approvals and
- Audit Management.
Werden diese Prozesse jeweils in getrennten Anwendungen betrieben, können neue Datensilos und Mehrfachpflege entstehen. Systeme, Dienstleister, Risiken und Responsible persons 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 Data protection, 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.
Creating an Evaluation Matrix
Eine belastbare Bewertungsmatrix sollte vier Ebenen miteinander verknüpfen:
Funktion – Nachweis – Betriebsrisiko – Managementnutzen
1. Function
Zunächst ist zu bestimmen, welche technische oder fachliche Fähigkeit benötigt wird.
Example: Configurable approval workflows.
2. Proof
Anschließend ist festzulegen, wie der Anbieter das tatsächliche Vorhandensein dieser Fähigkeit nachweist.
Example: Live configuration of an approval process with two reviewer roles, conditions, and escalation.
3. Operational Risk
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. Management Benefits
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.
| Evaluation criterion | Proof | Betriebsrisiko bei Schwäche | Management Benefits | Weighting |
|---|---|---|---|---|
| Roles and Permissions | Realistic Authorization Scenario | Unzulässige Zugriffe, fehlende Trennung, hoher Administrationsaufwand | Secure Delegation and Scalable Operations | 10 % |
| Workflow Configuration | Live Process with Conditions and Escalation | E-Mail-Prozesse, Fristversäumnisse, manuelle Nachverfolgung | Kürzere Durchlaufzeiten und eindeutige Verantwortlichkeiten | 12 % |
| Data Model and Relationships | Verknüpfung von Verarbeitungstätigkeit, System, Dienstleister und Risiko | Duplicate Care and a Lack of Professional Context | Unified Governance View | 10 % |
| Audit Trail | Vollständige Änderungshistorie | Decisions are not sufficiently transparent | Auditfähigkeit und Rechenschaft | 8 % |
| Reporting and Exports | Management, Audit- and operational report | Manual Report Generation | Faster control and reliable documentation | 8 % |
| Configurability | Adjustment by the customer service team | Herstellerabhängigkeit und hohe Folgekosten | Faster adaptation and lower operating costs | 12 % |
| Integration and API | Specific Case of Integration | Medienbrüche und doppelte Datenpflege | Automatisierung und höhere Datenqualität | 8 % |
| Data Migration | Mapping, Testing, and Validation Concept | Datenverlust, Verzögerungen und geringe Akzeptanz | Structured Project Launch | 8 % |
| Information Security | Technical and Organizational Evidence | Safety and Compliance-Risks | Vertrauenswürdiger Betrieb | KO / 10 % |
| Operating Model and Support | SLA, Support Structure, and Release Process | Verzögerte Problemlösung und Projektabhängigkeit | Predictability and Operational Reliability | 7 % |
| Plattformfähigkeit | Nutzung gemeinsamer Objekte über mehrere Lösungen | Entstehung zusätzlicher Governance-Silos | Scalability and Protection of Investment | 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.
Controllability as a Component of Economic Benefit
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.
This applies in particular to the following aspects:
- Fachbereiche wissen, welche Informationen und Tätigkeiten von ihnen erwartet werden.
- Responsibilities remain clear.
- Prüfungen werden zu den vorgesehenen Zeitpunkten ausgelöst.
- Fristen und Maßnahmen können nachverfolgt werden.
- Decisions are documented.
- Das Management erhält einen belastbaren Überblick.
- Auditnachweise entstehen bereits während des laufenden Prozesses.
- New regulatory requirements can be implemented more quickly.
- 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:
- What services are included in the standard package?
- Which features require add-on modules?
- Which modifications are considered configuration, and which are considered development?
- Who is authorized to make configurations?
- Welche Kosten entstehen für Herstellerunterstützung?
- How are release and update processes structured?
- Are custom configurations preserved during updates?
- 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:
- clear responsibilities,
- documented approvals,
- involving relevant roles at the appropriate time,
- Versioning,
- defined scopes,
- nachvollziehbare Änderungen,
- Berücksichtigung fachlicher Empfehlungen,
- documented risk acceptances,
- offene Maßnahmen,
- Follow-ups and
- 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:
- Does the architecture fit into the existing corporate landscape?
- How flexible is the integration model?
- Wie werden Identitäten und Rollen angebunden?
- Welche APIs und Ereignisse stehen zur Verfügung?
- How are configurations deployed and tested?
- How is client or corporate segregation structured?
- How are releases managed?
- Which databases and technologies are relevant?
- How are monitoring, logging, and Availability Ensured?
- 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.
Classification of 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 connects using the platform approach described here:
- configurable governance objects,
- Relationships between data,
- Roles and Permissions,
- Workflows,
- Prüfungen und Freigaben,
- Risiken und Maßnahmen,
- Reports and dashboards,
- Audit Trails and
- APIs and Integrations.
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 Documentation von Verarbeitungstätigkeiten. Verarbeitungstätigkeiten können mit Systemen, Dienstleistern, Risiken, technischen und organisatorischen Maßnahmen, Legal basis, 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.
Conclusion
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.
Questions and Answers
How do you evaluate privacy IRM software in an RFP?
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.
What are the key criteria to look for in privacy IRM software?
The key elimination criteria include, in particular, information security, data location, and the role and authorization model, Audit Trail, data portability, integration capabilities, scalability, support, and minimum contractual requirements.
Why aren't feature lists enough?
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.
What is the difference between a "must-have" and a "differentiating feature"?
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.
Why is configurability important?
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.
What documentation should a vendor provide during the RFP process?
Critical requirements should be demonstrated using specific scenarios. This applies, for example, to role models, approval workflows, escalations, Audit Trails, data exports, integrations, and configuration changes.
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.
What is the significance of the operating model?
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, Legal basis, 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