Ein Compliance-Tool kann mehrere Gesellschaften in einer Oberfläche anzeigen und trotzdem keine ausreichende Trennung ihrer Daten, Aufgaben und Exporte bieten. Für den Einkauf zählt deshalb nicht allein die Aussage „mandantenfähig“. Das Auswahlteam braucht eine Zugriffs- und Abnahmematrix, in der es normale Mitarbeitende, gruppenweite Prüfer, lokale Verantwortliche und privilegierte Administratoren mit konkreten Datensätzen und Exporten testet. Der DSMS-Softwareüberblick ordnet Produktkategorien ein; diese Anleitung prüft einen einzigen, kaufentscheidenden Sachverhalt anhand beobachtbarer Szenarien.
Die NIST SP 800-53A beschreibt Methoden zur Prüfung von Sicherheits- und Datenschutzkontrollen. Die Microsoft-Dokumentation zu Zugriffsreviews zeigt beispielhaft, dass Reviewer, Eigentümer und Administratoren unterschiedliche Aufgaben haben. Beide Quellen helfen beim Prüfdesign. Sie legen weder eine universelle Konzernrollenmatrix fest noch belegen sie eine Funktion des eingekauften Compliance-Produkts. Die Abnahme muss in dessen konkreter Konfiguration und mit den eigenen Gesellschaften erfolgen.
Zuerst die Trennungsgrenzen festlegen
Erfassen Sie die rechtlichen Einheiten, Geschäftsbereiche und gegebenenfalls gemeinsamen Dienste. Welche Gesellschaft ist für einen Vorgang verantwortlich? Wer darf Daten nur für eine Gesellschaft sehen? Wer muss gruppenweite Ergebnisse prüfen? Welche Dokumente werden gemeinsam genutzt, und welche bleiben lokal? Ein zentraler Datenschutzbeauftragter kann einen übergreifenden Auftrag haben, während ein lokaler Sachbearbeiter nur Beschwerden seiner Gesellschaft bearbeiten soll. Diese Unterschiede lassen sich nicht aus der Zahl der Mandanten im Angebot ableiten.
Definieren Sie die Objekte, die getrennt werden müssen: Vorgänge, Risiken, Kontrollen, Nachweise, personenbezogene Daten, Kommentare, Aufgaben, Anhänge, Auditprotokolle und Exporte. Ein System kann den Hauptdatensatz filtern, aber einen Dateinamen in einer Suche anzeigen oder eine Benachrichtigung an falsche Empfänger senden. Prüfen Sie jede relevante Oberfläche und jeden Nebenkanal. Die Software für Konzerne behandelt den breiteren Auswahlkontext; die hier geforderte Matrix bindet einzelne Objekte an konkrete Rollen und negative Testfälle.
Beschreiben Sie die gewünschte Freigabe im eigenen Betrieb, nicht als bloße Herstellerfunktion. Dürfen gruppenweite Prüfer alle Nachweise lesen, aber nicht ändern? Darf die zentrale Administration Benutzerrechte vergeben und Inhalte lesen, oder soll sie technisch administrieren, ohne fachliche Dokumente einzusehen? Eine Antwort kann von der Organisationsstruktur abhängen. Wenn eine Rolle aus praktischen Gründen mehr Rechte benötigt, dokumentieren Sie Zweck, Genehmigung, Protokollierung und regelmäßige Überprüfung.
Rollen und Objekte in einer Matrix verbinden
Eine Matrix sollte für jede Kombination aus Rolle, Gesellschaft, Objekt und Handlung ein erwartetes Ergebnis enthalten. „Zugriff: ja“ ist zu grob. Lesen, erstellen, bearbeiten, genehmigen, löschen, delegieren und exportieren sind verschiedene Rechte. Für personenbezogene Daten kann sogar die Metadatenanzeige eine Offenlegung sein. Legen Sie Testkonten mit nachvollziehbaren Identitäten an und verwenden Sie fiktive, eindeutig markierte Datensätze, damit die Prüfung keine realen vertraulichen Informationen verbreitet.
| Testrolle | Gesellschaft A | Gesellschaft B | Gruppenansicht | Negativer Test |
|---|---|---|---|---|
| Lokaler Bearbeiter A | Vorgang lesen und bearbeiten | Kein Fachzugriff | Nur eigene Aufgaben | Direkte B-URL aufrufen |
| Lokale Freigabe B | Kein Fachzugriff | B-Vorgang genehmigen | Keine A-Anhänge | A-Datei über Suche finden |
| Gruppenprüfer | A und B lesen | A und B lesen | Bericht erstellen | Fachobjekt bearbeiten versuchen |
| Technischer Admin | Konten verwalten | Konten verwalten | Rollenzuordnung prüfen | Datenexport ohne Auftrag versuchen |
| Externer Prüfer A | Freigegebene A-Nachweise lesen | Kein Zugriff | Kein Gesamtbericht | API- und CSV-Abfrage für B |
Die Matrix ist ein Beispiel, keine Vorlage mit zwingenden Rollen. Sie muss an Aufträge, Verträge und interne Regeln angepasst werden. Wichtig ist der negative Test: Eine zulässige A-Aktion beweist nicht, dass B-Daten geschützt sind. Notieren Sie erwartetes Ergebnis, tatsächlich beobachtetes Ergebnis, Datum, Produktversion und verwendetes Testkonto. Die Kostenbetrachtung von Audit-Software kann die Prüf- und Betriebskosten ergänzen; sie ersetzt keine Trennungsprüfung.
Mit realistischen Abnahmeszenarien arbeiten
Szenario eins: Ein lokaler Bearbeiter erstellt einen Vorgang für Gesellschaft A mit Anhang und Kommentar. Ein Bearbeiter B sucht nach einem einzigartigen Stichwort, ruft die direkte Objektadresse auf und versucht den Download über eine bekannte Dateireferenz. Erwartet wird, dass weder Inhalt noch sensible Metadaten erscheinen. Prüfen Sie, ob eine Fehlermeldung nur „kein Zugriff“ meldet oder bereits den Titel des fremden Dokuments verrät. Wiederholen Sie den Vorgang nach einem Rollenwechsel und nach Deaktivierung des Kontos.
Szenario zwei: Ein Gruppenprüfer erhält einen lesenden Gesamtüberblick. Er kann die Ergebnisse verschiedener Gesellschaften vergleichen, aber eine lokale Genehmigung nicht überschreiben. Lassen Sie ihn einen Bericht exportieren und prüfen Sie dessen Umfang. Enthält der Bericht Anhänge, Kommentare oder nur aggregierte Werte? Werden Gesellschaftsnamen korrekt zugeordnet? Ein Dashboard mit sauberem Filter kann im CSV-Export dennoch sämtliche Rohdaten ausgeben. Deshalb gehört der Export als eigener Prüfschritt in die Abnahme.
Szenario drei: Die technische Administration erstellt einen Nutzer und weist ihm versehentlich eine zu breite Rolle zu. Kann ein unabhängiger Verantwortlicher diese Zuordnung erkennen und korrigieren? Bleibt die Änderung im Auditprotokoll erhalten? Greift die Entziehung der Rolle sofort für bestehende Sitzungen, oder erst nach erneutem Login? Die Antwort muss im Produktversuch festgestellt werden. Eine Rollenliste in einer Angebotsfolie zeigt nur, was konfigurierbar sein könnte, nicht wie Berechtigungen wirksam werden.
Szenario vier: Ein externer Prüfer erhält für drei Wochen Zugang zu freigegebenen Nachweisen der Gesellschaft A. Nach Fristablauf versucht er dieselben Links, eine Suche und einen alten Export. Die Zugriffsbeendigung sollte getestet werden; bereits heruntergeladene Kopien können dadurch nicht zurückgerufen werden. Legen Sie daher fest, welche Exporte überhaupt erlaubt sind, wie sie gekennzeichnet werden und welche Pflichten für den Empfänger gelten. Die Datenschutz-Auditmethodik hilft beim Prüfauftrag, während die Szenarien die technische Grenze untersuchen.
Versteckte Pfade der Datenfreigabe prüfen
Viele Lecks entstehen über Funktionen, die nicht „Berechtigung“ heißen: globale Suche, Benachrichtigungs-E-Mails, Aufgabenübersichten, Vorlagenbibliotheken, verlinkte Nachweise oder Kommentare mit Erwähnungen. Fügen Sie Testdaten mit eindeutigen Begriffen und Dateinamen ein. Suchen Sie aus jeder Rolle danach und prüfen Sie Vorschauen, Trefferzahlen und Betreffzeilen. Ein Trefferzähler kann bereits die Existenz eines fremden Vorgangs verraten, auch wenn der eigentliche Inhalt gesperrt bleibt. Bewerten Sie, ob das für Ihren Schutzbedarf relevant ist.
Prüfen Sie Schnittstellen getrennt von der Weboberfläche. Ein API-Token kann andere Rechte haben als der eingeloggte Nutzer. Ein nächtlicher Bericht kann unter einem technischen Konto mit Zugriff auf alle Gesellschaften laufen. Fragen Sie, wie dessen Berechtigungen begrenzt und protokolliert werden. Führen Sie einen Testexport für A aus und prüfen Sie, ob darin B-Datensätze, IDs oder Anhänge erscheinen. Die Ausgabe muss anschließend außerhalb der Oberfläche mit einem einfachen Leser kontrolliert werden.
Auch gemeinsam genutzte Kontrollen sind anspruchsvoll. Ein Konzernstandard kann für A und B gelten, während die Evidenz für A aus einer anderen Umgebung stammt. Das Tool darf eine gemeinsame Kontrollbeschreibung anzeigen, aber die lokale Wirksamkeitsprüfung nicht automatisch auf B übertragen. Fragen Sie, ob die Beziehung zwischen zentraler Regel und lokaler Ausführung sichtbar bleibt. Die Wirksamkeitsprüfung von Sicherheitskontrollen erläutert, warum eine Kontrolldeklaration und ein beobachtetes Ergebnis getrennt werden müssen.
Ein Beispiel mit zwei Gesellschaften und einem Prüfer
Ein fiktiver Konzern hat eine Gesundheitsgesellschaft A und einen technischen Dienstleister B. Beide nutzen dasselbe Compliance-Tool. A dokumentiert einen Vorfall mit vertraulichen Patientendaten; B verwaltet einen internen Sicherheitsnachweis. Die zentrale Prüfperson braucht eine Übersicht über offene Maßnahmen in beiden Einheiten, aber nicht automatisch alle Anhänge des Vorfalls. Das Auswahlteam legt hierfür getrennte Testobjekte an und prüft die Matrix mit fünf Konten.
In der Demonstration funktioniert die Webansicht wie erwartet. Beim Berichtsexport erscheint jedoch der Titel des A-Vorfalls im B-Bericht, weil eine gemeinsame Maßnahme falsch zugeordnet ist. Das ist kein Beweis für einen generellen Produktfehler in jeder Installation; es zeigt, dass Datenmodell und Konfiguration im konkreten Fall geklärt werden müssen. Der Anbieter korrigiert die Zuordnung, und das Team wiederholt Export, Suche und Direktlink. Es dokumentiert die Ursache, das Ergebnis und eine Regel, die künftige gemeinsame Maßnahmen prüft.
Der technische Administrator kann anschließend die Rolle des Gruppenprüfers erweitern. Die Änderung wird protokolliert, aber es gibt im Test keine zweite Freigabe. Der Konzern entscheidet, die Rolle nur über ein internes Vier-Augen-Verfahren zu vergeben und die Protokolle regelmäßig auszuwerten. Diese organisatorische Maßnahme kann eine Produktlücke teilweise abfedern, erfordert aber laufende Arbeit. Der Einkauf nimmt sie in Kosten und Betriebskonzept auf, statt „Mandantentrennung bestanden“ ohne Vorbehalt zu schreiben.
Exporte als Abnahmegegenstand und Ausstiegspfad
Ein Konzern braucht Exporte nicht nur für Berichte, sondern auch für Prüfungen, Aufbewahrung und späteren Anbieterwechsel. Testen Sie, ob der Export Rollenbeschränkungen respektiert und zugleich Beziehungen zwischen Gesellschaft, Vorgang, Kontrolle, Nachweis und Entscheidung erhält. Ein Dateipaket mit Dokumenten ohne Zuordnung kann technisch vollständig aussehen und fachlich unbrauchbar sein. Vergeben Sie Test-IDs und vergleichen Sie die Anzahl und Beziehungen vor und nach dem Export.
Fragen Sie nach maschinenlesbaren Formaten, Anhängen, Versionen, Löschmarkierungen und Protokollen. Prüfen Sie, ob ein gruppenweiter Export nur mit besonderer Berechtigung möglich ist und wer ihn genehmigt. Legen Sie fest, wo die exportierten Daten gespeichert und wann sie gelöscht werden. Eine Berechtigungsgrenze endet nicht an der Download-Schaltfläche. Bei einem späteren Wechsel muss die Zielumgebung die Trennung mindestens ebenso verständlich abbilden; planen Sie den Abgleich früh.
Wenn ein Datenexport für jeden Mandanten einzeln erfolgen muss, rechnen Sie den Aufwand nach der tatsächlichen Zahl der Einheiten und Objekte. Wenn nur ein globaler Export möglich ist, kann eine nachträgliche Trennung zusätzliche Risiken und Kosten erzeugen. Beides ist in der Kaufentscheidung relevant. Eine API-Zusage ersetzt keinen Probelauf mit konkreten Objekten und einem Zielsystem, das die Beziehungen lesen kann.
Rechtliche und organisatorische Grenzen nicht vermischen
Die Matrix beschreibt technische und organisatorische Erwartungen. Ob zwischen Gesellschaften gemeinsame oder getrennte Verantwortlichkeiten für personenbezogene Daten bestehen, muss für die konkrete Verarbeitung rechtlich geprüft werden. Eine Software-Mandantengrenze entscheidet diese Frage nicht selbst. Ebenso kann eine rechtlich zulässige gruppenweite Einsicht technisch zu weit umgesetzt sein. Der Kaufprozess sollte Datenschutz, Informationssicherheit und fachliche Verantwortliche an den Stellen einbeziehen, an denen die jeweilige Entscheidung entsteht.
Prüfen Sie das Rollenmodell auch nach Umstrukturierungen. Eine Gesellschaft kann verkauft, ein Bereich aufgeteilt oder eine zentrale Funktion neu zugeordnet werden. Können Daten und Rollen ohne manuelles Suchen aller Einzelobjekte getrennt werden? Bleiben alte Entscheidungen nachvollziehbar? Ein kurzfristig funktionierender Filter kann bei einer späteren Ausgliederung zum Hindernis werden. Der Vergleich von DSGVO-Compliance-Software bietet den weiteren Marktüberblick; die Abnahmematrix macht diese Zukunftsfrage messbar.
Am Ende steht ein Protokoll mit Matrix, Testkonten, Datensätzen, erwarteten und beobachteten Ergebnissen, offenen Lücken, verantwortlichen Personen und einer Entscheidung über die Abnahme. „Ja, mehrere Mandanten“ ist dafür zu wenig. Ein kaufbares System muss die tatsächlich erforderlichen Gesellschaftsgrenzen im Alltag, bei privilegierten Änderungen und im Export nachweisbar halten. Falls ein Teil nur durch interne Verfahren abgesichert werden kann, muss das Verfahren konkret, zugewiesen und im Betrieb überprüfbar sein.
Berechtigungsänderungen als Lebenszyklus prüfen
Eine Matrix ist nur zum Zeitpunkt der Abnahme richtig. Im Betrieb wechseln Personen Abteilungen, übernehmen Vertretungen oder verlassen eine Gesellschaft. Testen Sie daher einen vollständigen Rollenwechsel: Ein Bearbeiter von A wird für einen Monat gruppenweit eingesetzt und kehrt dann zu A zurück. Wer beantragt und genehmigt die Erweiterung? Sind alte lokale Rechte weiterhin nötig? Wann wird die Zusatzrolle entfernt? Prüfen Sie nach Entziehung sowohl die normale Oberfläche als auch eine bestehende Sitzung, einen gespeicherten Link und einen geplanten Bericht.
Ein regelmäßiger Zugriffsreview kann diese Veränderungen entdecken, wenn die verantwortlichen Personen die Berechtigungen im fachlichen Kontext bewerten. Eine bloße Liste mit Ja/Nein-Antworten reicht nicht, wenn unklar ist, welche Mandanten und Datenobjekte hinter einer Rolle stehen. Geben Sie dem Reviewer die Gesellschaft, Zweck, letzte Nutzung und besonderen Exportrechte. Die Microsoft-Dokumentation illustriert Rollen und Review-Zyklen für ihre Identitätsplattform; übernehmen Sie daraus nicht ungeprüft einen bestimmten Takt für das hier gekaufte Produkt.
Prüfen Sie auch Notfallrollen. Ein technisch privilegierter Zugriff kann erforderlich sein, wenn normale Freigaben ausfallen. Er sollte eng begrenzt, geschützt, protokolliert und nach Nutzung untersucht werden. Die Abnahme muss zeigen, ob ein Notfallzugriff die Mandantengrenzen bewusst überbrückt und wer darüber informiert wird. „Administrator“ ist kein Freibrief für ungeprüfte Fachzugriffe. Wenn der Anbieter Wartungszugriff erhält, gehören dessen Rechte, Zeitfenster und Protokolle ebenfalls in die Matrix.
Negative Ergebnisse in eine Kaufentscheidung übersetzen
Nicht jeder fehlgeschlagene Test hat dieselbe Bedeutung. Wenn ein Suchtreffer den Namen eines fremden Projekts verrät, ist zu klären, ob dies für den Schutzbedarf der Gesellschaften tolerierbar ist. Wenn ein lokaler Bearbeiter fremde Anhänge herunterladen kann, betrifft der Fehler den Kern der Trennung. Wenn ein Export nur mit einem sehr mächtigen globalen Konto funktioniert, muss geprüft werden, ob eine unabhängige Freigabe und ein geschützter Ausgabepfad das Risiko vertretbar reduzieren können.
Schreiben Sie für jede Lücke eine nachvollziehbare Entscheidung: Fehler im Produkt, Konfigurationsmangel, fehlendes Verständnis des Datenmodells oder bewusste fachliche Regel? Weisen Sie Eigentümer und Retest zu. Eine zugesagte Korrektur des Herstellers ist noch kein bestandenes Ergebnis. Wenn die Kaufentscheidung vorher getroffen werden muss, kann sie an eine überprüfbare Abnahmebedingung geknüpft werden. Der Preis einer zusätzlichen Konfiguration oder eines manuellen Vier-Augen-Verfahrens gehört in die Gesamtkosten.
Verlangen Sie am Ende einen Export des Abnahmeprotokolls selbst. Enthält er Test-ID, Rolle, Mandant, Objekt, erwartetes und tatsächliches Resultat, Datum sowie offene Maßnahmen? Falls die Dokumentation außerhalb des Produkts entsteht, legen Sie fest, wo sie gepflegt wird. Die Abnahme sollte wiederholt werden, wenn ein großes Update Berechtigungen, Suche oder Export verändert. Eine einmalig bestandene Demo ist keine dauerhafte Garantie.
Datenübernahme mit denselben Trennungsregeln
Die Migration vorhandener Vorgänge ist ein eigener Risikomoment. Ein Importskript mit globalen Rechten kann versehentlich Objekte der falschen Gesellschaft zuordnen. Definieren Sie vor dem Import einen Testbestand mit eindeutigen IDs und erwarteter Gesellschaft. Vergleichen Sie nach der Übernahme Anzahl, Zuordnung, Anhänge und Verknüpfungen. Lassen Sie anschließend die Testrollen aus A und B genau diesen Bestand abfragen. Eine korrekte Benutzeroberfläche mit falsch migrierten Eigentümerfeldern bietet keine verlässliche Trennung.
Planen Sie die Behandlung unbekannter oder mehrdeutiger Eigentümer. Sie sollten nicht stillschweigend dem globalen Mandanten zugeordnet werden, nur damit der Import ohne Fehlermeldung endet. Eine Ausnahmeliste mit verantwortlicher Entscheidung und Nachkontrolle ist besser. Prüfen Sie auch, ob historische Kommentare oder Dateinamen sensible Informationen enthalten, die von einer gemeinsam genutzten Suchfunktion indexiert werden. Der Datenschutz beim Import ist nicht auf die offensichtlichen Datensätze beschränkt.
Nach dem Import ziehen Sie einen Bericht je Gesellschaft und einen gruppenweiten Bericht, jeweils mit unterschiedlichen Rollen. Stimmen Sie die Ergebnisse mit dem Quellsystem ab und untersuchen Sie Abweichungen. Die Matrix wird damit zum Abnahmewerkzeug für den Übergang und später für den Betrieb. Das ist aussagekräftiger als die bloße Meldung, dass alle Zeilen ohne technischen Fehler eingelesen wurden.