Bert Kondruss, KonBriefing Research, Deutschland
Besonders große Organisationen profitieren, wenn eine GRC-Software mandantenfähig ist. Jedoch müssen verschiedene Ziele und Konzepte unterschiedenen werden, um sowohl Effizienz als auch Compliance sicherzustellen. Wir zeigen hier die verschiedenen Ausprägungen auf.
Begriffe
Mandantenfähigkeit
Jeder arbeitet komplett unabhängig
Mehrere organisatorisch getrennte Einheiten (Mandanten) können innerhalb einer Software-Instanz unabhängig voneinander arbeiten. Jeder Mandant hat seine eigenen Daten, Benutzer und Berechtigungen.
Diese Art der Mandantisierung wird oft von IT-Dienstleistern genutzt, die den Dienst für ihre Kunden betreiben und bereitstellen. Weil diese Kunden in der Regel rechtlich eigenständige Einheiten sind, ist eine strikte Isolation der Daten notwendig.
Übergreifend sind oft nur technische Funktionen, die den Betrieb mehrerer Mandanten effizient ermöglichen. Mandanten-übergreifende fachliche Daten oder Abläufe sind in der Regel nicht vorgesehen.
Konzernfähigkeit
Zentrale Steuerung durch den Konzern, die Tochtergesellschaften arbeiten operativ selbstständig
Sie ermöglicht die Abbildung komplexer Organisationsstrukturen, z.B. Konzerngesellschaften, Tochterunternehmen, Geschäftsbereiche. Dabei wird die harte Mandantentrennung aufgeweicht, so dass bestimmte Informationen mandantenübergreifend geteilt oder aggregiert werden können. Es können auch mandantenübergreifende Abläufe möglich sein, um in einzelnen Fällen die Zusammenarbeit von sonst getrennten Organisationseinheiten zu ermöglichen.
Andere Begriffe sind Multi-Organisation-Support, Multi-Entity Support, Group Management.
Eigenschaften
In der nachfolgenden Tabelle haben wir wichtige Merkmale von Mandantenfähigkeit und Konzernfähigkeit zusammengestellt.
| Kriterium | Mandantenfähigkeit (Mulit-Tenancy) | Konzernfähigkeit (Multi-Organisation) |
|---|---|---|
| Zielgruppe | Verschiedene Kunden, externe Organisationen, Dienstleister | Unternehmensgruppen, Konzerne, interne Organisationseinheiten |
| Beziehung der Organisationseinheiten | Unabhängige, voneinander fremde Mandanten | Zugehörige Organisationseinheiten eines Konzerns / einer Gruppe |
| Datenisolation | Sehr strikt: vollständige Isolation der Daten zwischen Mandanten | Teilweise Isolation, aber oft zentrale Übersichten möglich |
| Berechtigungsmodell | Keine gemeinsamen Benutzer oder Rollen über Mandanten hinweg | Übergreifende Rollen und Reporting oft vorgesehen |
| Customizing pro Einheit | Vollständig getrennte Konfiguration möglich (z.B. Logos, Workflows, eigene Prozesse) | Teilweise Vereinheitlichung durch zentrale Vorgaben |
| Wiederverwendbarkeit von Policies / Prozessen | Meist nicht vorhanden, jeder Mandant wird selbstständig verwaltet | Zentrale Policies, Prozesse und Templates für alle Organisationen nutzbar |
| Zentrale Konzern-Verantwortliche, z.B. Konzern-ISB | Hat keinen Zugriff auf andere Mandanten | Hat in der Regel Steuerungs- und Reportingrechte für alle Einheiten |
| Technische Trennung | Häufig separate Datenbanken oder dedizierte Instanzen (hohe Isolation) | Häufig gemeinsame Plattform mit logischer Trennung |
| Beispiele für Nutzung | SaaS-ISMS-Anbieter für viele unterschiedliche Unternehmen | Konzern mit mehreren Tochtergesellschaften und zentralem ISMS |
| Relevanz bei GRC- und ISMS-Software | Für ISMS-as-a-Service-Anbieter, Berater, IT-Dienstleister | Für große Unternehmensgruppen, Holdingstrukturen, verteilte Organisationen |
| Beispielhafte Frage im Auswahlprozess | Kann die Software komplett getrennte Mandanten verwalten? | Kann die Software Organisationseinheiten zentral steuern, aber dezentral arbeiten lassen? |
Architektur
Die unterschiedlichen Anforderungen an die Mandantenfähigkeit lassen sich über verschiedene Architekturprinzipien umsetzen.
Eine Instanz, ein Schema mit logischer Trennung
●
Beschreibung:
Eine Software-Instanz, eine gemeinsame Datenbank, Mandantentrennung über IDs (z.B. Mandanten-ID) und Berechtigungen
Eine Software-Instanz, eine gemeinsame Datenbank, Mandantentrennung über IDs (z.B. Mandanten-ID) und Berechtigungen
●
Typische Einsatzszenarien:
Interne Organisationen
Interne Organisationen
●
Vorteile:
Einfache Architektur, einfacher Betrieb und einfache Wartung, Zusammenarbeit und Aggregation leicht umsetzbar
Einfache Architektur, einfacher Betrieb und einfache Wartung, Zusammenarbeit und Aggregation leicht umsetzbar
●
Nachteile:
Schwache Isolation, Risiko bei Fehlkonfiguration, eingeschränkte Möglichkeiten zur individuellen Anpassung je Organisationseinheit, ungeeignet für hochregulierte Bereiche
Schwache Isolation, Risiko bei Fehlkonfiguration, eingeschränkte Möglichkeiten zur individuellen Anpassung je Organisationseinheit, ungeeignet für hochregulierte Bereiche
Eine Instanz, getrennte Schemas
●
Beschreibung:
Eine Software-Instanz, für jeden Mandanten ein eigenes Datenbank-Schema mit eigenen Tabellen
Eine Software-Instanz, für jeden Mandanten ein eigenes Datenbank-Schema mit eigenen Tabellen
●
Typische Einsatzszenarien:
SaaS-Plattformen, IT-Service-Provider
SaaS-Plattformen, IT-Service-Provider
●
Vorteile:
Bessere Isolation der Daten, zentraler Betrieb ist möglich
Bessere Isolation der Daten, zentraler Betrieb ist möglich
●
Nachteile:
Komplexere Datenbank-Verwaltung, Schema-Änderungen aufwändiger, Abhängigkeit zu allen Organisationseinheiten bei Upgrades und anderen Wartungsarbeiten
Komplexere Datenbank-Verwaltung, Schema-Änderungen aufwändiger, Abhängigkeit zu allen Organisationseinheiten bei Upgrades und anderen Wartungsarbeiten
Eine Instanz, jeder Mandant mit eigener Datenbank
●
Beschreibung:
Eine Software-Instanz, für jeden Mandanten eine eigene Datenbank mit eigenen Tabellen
Eine Software-Instanz, für jeden Mandanten eine eigene Datenbank mit eigenen Tabellen
●
Typische Einsatzszenarien:
Regulierte Branchen, z.B. Finanzdienstleister, Gesundheitswesen
Regulierte Branchen, z.B. Finanzdienstleister, Gesundheitswesen
●
Vorteile:
Hohe Isolation der Daten, verbesserte Compliance, verbesserter Datenschutz
Hohe Isolation der Daten, verbesserte Compliance, verbesserter Datenschutz
●
Nachteile:
Höhere Betriebsaufwände, komplexes Deployment, Abhängigkeit zu allen Organisationseinheiten bei Upgrades und anderen Wartungsarbeiten.
Höhere Betriebsaufwände, komplexes Deployment, Abhängigkeit zu allen Organisationseinheiten bei Upgrades und anderen Wartungsarbeiten.
Jeder Mandant mit eigener Instanz und eigener Datenbank
●
Beschreibung:
Für jeden Mandanten eine eigene Software-Instanz und eine eigene Datenbank-Instanz
Für jeden Mandanten eine eigene Software-Instanz und eine eigene Datenbank-Instanz
●
Typische Einsatzszenarien:
Hochregulierte Branchen, kritische Infrastruktur
Hochregulierte Branchen, kritische Infrastruktur
●
Vorteile:
Maximale Isolation der Daten
Maximale Isolation der Daten
●
Nachteile:
Hohe Betriebskosten, aufwändige Wartung
Hohe Betriebskosten, aufwändige Wartung
Darüber hinaus sind Mischformen möglich.
Bei einer Standard-Software kann man die Architektur nicht frei wählen, sondern es hängt von den Möglichkeiten der Software und des Anbieters ab. Es ist aber wichtig, die Prinzipien und deren jeweilige Auswirkungen zu verstehen.
Welche Art der Mandantenfähigkeit?
Welche Kriterien sind relevant, um die Art der Mandantenfähigkeit einer GRC- bzw. ISMS-Software zu identifizieren, die am besten auf eine gegebene Situation passt?
●
Art der Mandanten (extern / intern)
●
Grad der Autonomie der Organisationseinheiten
●
Anzahl der Organisationseinheiten
●
Anforderungen an Isolation der Daten, Sicherheit und Datenschutz
●
Anpassungsbedarf je Organisationseinheit
●
Anforderungen an übergreifende Zusammenarbeit und Aggregation von Informationen
●
Notwendigkeit für zentrale fachliche Vorgaben, z.B. übergreifende Policies
●
Anforderungen an eine zentrale Steuerung des Betriebs
●
Betriebskosten
●
Skalierbarkeit und Erweiterbarkeit um neue Organisationseinheiten
Mandantenfähigkeit in Ausschreibungen für ISMS- und GRC-Tools
Die Fähigkeit der GRC-Software zur Mandantisierung sollte frühzeitig im Ausschreibungs- und Auswahlprozess detailliert berücksichtigt werden. Zunächst sollte klar definiert werden, ob es um echte Mandantenfähigkeit mit komplett getrennten Mandanten oder um Konzernfähigkeit geht. Im Lastenheft sollten konkrete Anforderungen an Datenisolation, Benutzer- und Rollenverwaltung, zentrale Steuerungsmöglichkeiten, Wiederverwendbarkeit von Policies und Reportingaggregation formuliert werden.
In welche Anforderungen muss die Mandantisierung einfließen? Hier eine Liste beispielhafter Anforderungen.
Passen Sie diese an Ihre Anforderungen an.
Nehmen Sie nur solche Anforderungen auf, die für Ihre Situation relevant sind.
Beschränken Sie die Muss-Kriterien auf das notwendige Mindestmaß.
Passen Sie diese an Ihre Anforderungen an.
Nehmen Sie nur solche Anforderungen auf, die für Ihre Situation relevant sind.
Beschränken Sie die Muss-Kriterien auf das notwendige Mindestmaß.
Allgemein:
●
Beschreibung der Mengengerüste: Anzahl der aktuell geplanten Mandanten, Anzahl der Mandanten, die später hinzukommen können.
Mandantisierung:
●
Die Software soll | muss mehrere Mandanten vollständig voneinander trennen können.
●
Jeder Mandant verwaltet seine Daten unabhängig (z. B. Risiken, Maßnahmen, Assets, Dokumente, Benutzer, Workflows).
●
Daten eines Mandanten dürfen ohne explizite Berechtigung nicht für andere Mandanten sichtbar oder zugänglich sein.
●
Es darf keine systemseitige Möglichkeit für Benutzer geben, mehrere Mandanten gleichzeitig einzusehen (sofern nicht ausdrücklich für administrative Rollen definiert).
●
Die Mandantentrennung muss auf technischer Ebene nachvollziehbar dokumentiert sein. Es muss transparent werden, wie die Mandantentrennung technisch realisiert ist, insbesondere auf welcher Ebene (Applikation, Datenbank, Infrastruktur) die Isolation erfolgt.
●
Die Architektur muss dokumentieren, wie Datenlecks zwischen Mandanten ausgeschlossen werden.
●
Trennung muss revisionssicher und nachprüfbar realisiert sein (z.B. für Datenschutzprüfungen)
●
Benutzer und Rollen müssen mandantenspezifisch verwaltet werden.
●
Es darf keine globalen Benutzerkonten ohne Mandantenzugehörigkeit geben (Ausnahme: dedizierte Administrationsrollen).
●
Jeder Mandant kann sein eigenes Rollen- und Berechtigungskonzept definieren.
●
Es soll | muss einen mandantenübergreifenden Administrator geben
●
Für jeden Mandanten soll | muss es einen mandantenspezifischen Administrator geben, der nur Zugriff auf diesen Mandanten hat und Verwaltungsaufgaben durchführen kann, z.B. das Anlegen von Benutzern.
●
Es soll | muss pro Mandant eine eigene Benutzerverwaltung geben.
●
Es soll | muss jeder Mandant an einen eigenen Verzeichnisdienst / Active Directory angebunden werden können.
●
Jeder Mandant soll | muss eigene Objekte wie Policies, Workflows, Formulare, Risikokataloge, Maßnahmenkataloge und Reporting-Layouts definieren können
●
Corporate Identity (z.B. Logos, Farbschema) sollen | müssen pro Mandant individuell konfiguriert werden können
●
Die Software muss eine zentrale Verwaltung für die Erstellung, Konfiguration und Löschung von Mandanten bieten.
●
Mandanten sollen flexibel angelegt, angepasst oder deaktiviert werden können.
●
Mandantenwechsel von Benutzern (z. B. für Beraterrollen) muss sicher und transparent umgesetzt sein.
●
Ressourcen bei On-premises-Installation: Der Anbieter berücksichtigt bei der Dimensionierung der Infrastruktur auch die Zahl der Mandanten.
●
Die Architektur muss auf beliebig viele Mandanten skalierbar sein.
●
Performance und Antwortzeiten dürfen bei steigender Anzahl Mandanten nicht signifikant sinken.
●
Schnittstellenzugriffe müssen mandantenspezifisch abgesichert und konfigurierbar sein.
●
Integrationen in externe Systeme (z. B. Schwachstellen-Scanner, AD, HR-Systeme) müssen mandantengetrennt konfigurierbar sein.
●
Es muss nachvollziehbar dokumentiert sein, welche technischen und organisatorischen Maßnahmen zur Mandantentrennung ergriffen werden.
●
Die Lösung muss Datenschutzanforderungen (z. B. DSGVO, BDSG, ISO 27001 Annex A.9 und A.18) für mandantenfähige Systeme erfüllen.
●
Es sollen | müssen pro Mandant unterschiedliche Service Level Agreements (SLAs), Vertragstypen und Supportoptionen hinterlegt werden können.
●
Lizenzmodelle sollen mandantenspezifisch zuweisbar sein.
Konzernfähigkeit / Multi-Organisation-Support
●
Die Software muss eine hierarchische Abbildung von Organisationseinheiten (z. B. Konzern, Tochtergesellschaften, Geschäftsbereiche, Standorte) ermöglichen.
●
Es soll | muss möglich sein, beliebig viele Organisationseinheiten anzulegen, zu verwalten und bei Bedarf neu zu strukturieren, auch nachträglich.
●
Die Organisationsstruktur soll idealerweise per Schnittstelle (z.B. HR-System, Active Directory, ERP) automatisiert gepflegt werden können.
●
Daten (Risiken, Maßnahmen, Assets, Dokumente etc.) müssen je Organisationseinheit getrennt verwaltet werden.
●
Benutzer dürfen nur auf Daten der ihnen zugewiesenen Organisationseinheit(en) zugreifen können.
●
Daten dürfen standardmäßig nicht organisationsübergreifend sichtbar sein (außer explizit berechtigt).
●
Zentrale Organisationseinheiten (z. B. Konzern-ISB) sollen | müssen organisationsübergreifende Vorgaben (z. B. Policies, Maßnahmenkataloge, Risiko-Kategorien) erstellen und verwalten können.
●
Änderungen an zentralen Vorgaben sollen | müssen an untergeordnete Organisationseinheiten verteilt werden können.
●
Das System muss rollenbasierte Berechtigungen je Organisationseinheit unterstützen.
●
Benutzer können mehreren Organisationseinheiten gleichzeitig zugeordnet werden.
●
Es sollen | müssen zentrale Rollen für konzernweite Steuerung definiert werden können.
●
Zentrale Instanzen (z. B. Konzernleitung, zentrale Compliance) sollen | müssen organisationsübergreifende Auswertungen und konsolidierte Reports erstellen können.
●
Aggregation von Risiko- und Compliance-Status über alle Organisationseinheiten soll | muss möglich sein.
●
Es muss nachvollziehbar dokumentiert sein, welcher Benutzer auf welche Organisationseinheit Zugriff hat.
●
Die Software muss sicherstellen, dass keine unbefugte organisationsübergreifende Einsichtnahme auf Daten möglich ist.
●
Innerhalb jeder Organisationseinheit soll | muss eine unabhängige Steuerung der eigenen Risiken, Maßnahmen und Kontrollen möglich sein.
●
Verantwortlichkeiten sollen | müssen flexibel an Organisationseinheiten gebunden werden können.
●
Historische Daten und Verantwortlichkeiten sollen | müssen bei Organisationsänderungen nachvollziehbar erhalten bleiben.
●
Benutzer sollen | müssen bei Anmeldung eindeutig erkennen, für welche Organisationseinheit(en) sie tätig sind.
●
Organisationseinheiten sollen | müssen eindeutig identifizierbar sein (z. B. Name, Kürzel, rechtliche Einheit).
Zusammenfassung
Bei der Auswahl von ISMS- oder GRC-Software gehören Mandantisierung (Multitenancy) und Multi-Organisation-Support zu den entscheidenden Architektur- und Funktionsmerkmalen. Es sollte frühzeitig definiert werden, welches Mandantenmodell benötigt wird. Wichtig sind präzise Anforderungen an Datenisolation, Berechtigungsmanagement, Skalierbarkeit, zentrale Vorgabensteuerung, individuelle Customizing-Möglichkeiten sowie Datenschutz und Compliance. Fehlerhafte oder unvollständige Spezifikationen können später zu massiven Nachbesserungen, erhöhtem Betriebsaufwand oder sogar zu Migrationsnotwendigkeiten führen. Bei der Tool-Auswahl ist es wichtig, die organisatorischen Anforderungen gemeinsam mit der technischen Umsetzung zu betrachten, um eine Lösung zu wählen, die sowohl den heutigen Bedarf als auch künftige Unternehmensentwicklungen optimal unterstützt.