Definition
Eine Multi-Tenant-Architektur — auf Deutsch Mandantenfähigkeit — erlaubt es, mehrere voneinander getrennte Organisationen in einer einzigen Installation zu betreiben. Jeder Mandant sieht ausschließlich seine eigenen Daten, hat eigene Stammdaten und eigene Berechtigungen; gemeinsam sind nur Programmcode und Betrieb.
Der Nutzen liegt im Betrieb: eine Installation statt zehn, ein Updatelauf statt zehn, ein Sicherungskonzept statt zehn. Die Schwierigkeit liegt in der Trennung — und genau dort entscheidet sich, ob eine Anwendung mandantenfähig ist oder nur ein Feld „Firma“ in einer gemeinsamen Tabelle führt.
Drei Stufen der Trennung
| Stufe | Umsetzung | Trennung | Betriebsaufwand |
|---|---|---|---|
| Geteiltes Schema | eine Tabelle, Mandantenspalte je Datensatz | allein durch Anwendungslogik | am geringsten |
| Getrennte Schemata | ein Datenbankschema je Mandant | durch die Datenbank erzwungen | gering bis mittel |
| Getrennte Datenbanken | eine Datenbank je Mandant | vollständig; Sicherung je Mandant | mittel |
Die erste Stufe ist die verbreitetste und die anfälligste: Jede Abfrage, die den Mandantenfilter vergisst, liefert fremde Daten. Solche Fehler fallen im Test selten auf, weil Testsysteme meist nur einen Mandanten führen.
Die dritte Stufe schließt übergreifende Abfragen technisch aus und erlaubt es, einen Mandanten einzeln zu sichern, zurückzusichern oder herauszulösen — der praktisch wichtigste Punkt, wenn eine Tochtergesellschaft verkauft wird oder eine Kommune den Verbund verlässt. Der Preis dafür ist ein etwas höherer Betriebsaufwand und der Umstand, dass übergreifende Auswertungen eigens gebaut werden müssen.
Mandant oder Standort?
Diese Unterscheidung wird bei der Einführung getroffen und lässt sich später kaum korrigieren.
Ein Standort ist eine Gliederung innerhalb einer Organisation. Stammdaten, Rollen und Nummernkreise sind gemeinsam; unterschiedlich ist nur, wer was sehen darf. Auswertungen über alle Standorte sind selbstverständlich möglich — sie sind sogar der Zweck.
Ein Mandant ist eine eigene Organisation. Eigene Stammdaten, eigene Berechtigungen, in der Regel eine eigene Verantwortlichkeit im Sinne der DSGVO. Auswertungen über Mandanten hinweg sind die Ausnahme und brauchen eine eigene Rechtsgrundlage.
Die Faustregel: Wer gemeinsam auswerten will und dieselben Regeln anwendet, braucht Standorte. Wer getrennte Verantwortung, getrennte Daten und die Möglichkeit zur sauberen Trennung braucht, braucht Mandanten. Typische Anwendungsfälle für Mandanten sind ein Konzern mit rechtlich selbstständigen Tochtergesellschaften, ein kommunales Rechenzentrum, das für mehrere Kommunen betreibt, ein Dienstleister mit Endkunden und eine Behörde mit eigenständigen Dienststellen.
Was der Datenschutz verlangt
Art. 32 Abs. 1 lit. b DSGVO verlangt Maßnahmen, die „die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme“ auf Dauer sicherstellen. Bei mehreren Mandanten folgt daraus die Trennung der Daten unterschiedlicher Verantwortlicher — dokumentiert, nicht nur behauptet. Prüfbar wird das über vier Fragen: Wie ist getrennt? Wer hat administrativen Zugriff über Mandanten hinweg? Wird dieser Zugriff protokolliert? Und lässt sich ein einzelner Mandant sichern und löschen, ohne andere zu berühren?
Betreibt eine Stelle die Installation für andere — das kommunale Rechenzentrum für die Kommunen, die Konzernmutter für die Töchter —, liegt in der Regel eine Auftragsverarbeitung nach Art. 28 DSGVO vor. Dann sind die Verantwortlichkeiten vertraglich zu regeln, einschließlich Weisungsrechten, Unterauftragnehmern und Löschung bei Vertragsende.
Dieselben Anforderungen an Zugriffskontrolle und Protokollierung ergeben sich aus § 30 BSIG für Einrichtungen, die unter NIS2 fallen — wer beides getrennt dokumentiert, schreibt zweimal dasselbe.
In der Praxis
Beim Betrieb On-Premise ist Mandantenfähigkeit oft der eigentliche Grund für die Auswahl: Sie ist die Alternative dazu, je Einheit eine eigene Installation zu betreiben. Der Unterschied wird ab der dritten Einheit spürbar und ab der fünften entscheidend — Updates, Zertifikate und Sicherungen vervielfachen sich sonst.
Bei der Auswahl einer Fuhrparksoftware lohnen sich vier konkrete Fragen: Welche Trennungsstufe ist umgesetzt? Lassen sich Stammdaten wie Fahrzeugarten oder Kostenstellen je Mandant getrennt pflegen — oder sind sie global? Gibt es eine übergreifende Auswertung, und wie wird sie berechtigt? Und wie wird ein Mandant herausgelöst, wenn er den Verbund verlässt?
Die letzte Frage wird fast nie gestellt und ist die teuerste. Sie gehört in den Vertrag, nicht in das erste Betriebsjahr.
Beim Zuschnitt der Mandanten lohnt ein Blick auf die Auswertung, bevor die Struktur steht. Wer eine Gesamtsicht über alle Fahrzeuge braucht — für die Beschaffung, für CO₂-Berichte, für Versicherungsverhandlungen —, sollte prüfen, wie die Anwendung diese Sicht erzeugt: durch eine berechtigte übergreifende Auswertung, durch einen Export je Mandant oder gar nicht. Bei getrennten Datenbanken ist das eine bewusste Zusatzfunktion, keine Selbstverständlichkeit.
Beim Rollenkonzept kommt zur Mandantengrenze eine zweite Dimension hinzu: die Sichtbarkeit innerhalb eines Mandanten nach Standort oder Organisationseinheit. Beide wirken zusammen — eine Person kann in einem Mandanten alle Standorte sehen und in einem anderen nur einen. Wer das erst nach dem Produktivstart nachzieht, verteilt Berechtigungen ein zweites Mal von Hand.
Auch bekannt als: Mandantenfähigkeit, Multi-Mandanten-Architektur, Mandantenfähige Software, Multi-Tenancy, Mandantentrennung, mehrere Mandanten in einer Installation, Multi-Client-Architektur
Häufige Fragen
Eine Software ist mandantenfähig, wenn sie mehrere voneinander getrennte Organisationen in einer Installation führen kann, ohne dass Daten des einen Mandanten im anderen sichtbar werden. Getrennt sind dabei nicht nur die Datensätze, sondern auch Stammdaten, Berechtigungen, Nummernkreise und Auswertungen. Ein bloßes Filterfeld „Firma“ in einer gemeinsamen Tabelle erfüllt das nicht.
Ein Standort ist eine Gliederung innerhalb einer Organisation: Dieselben Stammdaten, dieselben Rollen, unterschiedliche Sichtbarkeit. Ein Mandant ist eine eigene Organisation mit eigener Datenhaltung, eigenen Stammdaten und in der Regel eigener Verantwortlichkeit im Sinne der DSGVO. Die Verwechslung ist teuer: Wer Tochtergesellschaften als Standorte anlegt, kann sie später nicht ohne Migration trennen — und wer Abteilungen als Mandanten anlegt, kann nicht mehr übergreifend auswerten.
Drei sind verbreitet. Geteiltes Schema mit Mandantenspalte: günstig im Betrieb, die Trennung hängt vollständig an der Anwendungslogik. Eigenes Schema je Mandant: klarere Grenze, gemeinsame Datenbankinstanz. Eigene Datenbank je Mandant: stärkste Trennung, getrennte Sicherung und Wiederherstellung je Mandant, etwas höherer Betriebsaufwand. Die Wahl ist eine Risikoentscheidung, keine reine Technikfrage.
Ja, und häufig gerade dort. Kommunale Rechenzentren betreiben eine Installation für mehrere Kommunen, Konzerne eine für mehrere Gesellschaften, Behörden eine für mehrere Dienststellen. Die Alternative — je Einheit eine eigene Installation — vervielfacht Updates, Backups und Betriebsaufwand und macht übergreifende Auswertungen unmöglich.
Art. 32 Abs. 1 lit. b DSGVO verlangt Maßnahmen, die Vertraulichkeit und Integrität dauerhaft sicherstellen; daraus folgt die Trennung von Daten unterschiedlicher Verantwortlicher. Praktisch heißt das: dokumentierte Trennung, getrennte Berechtigungen, protokollierte administrative Zugriffe und eine klare Aussage, wer für welchen Mandanten Verantwortlicher ist. Betreibt eine Stelle die Installation für andere, entsteht in der Regel eine Auftragsverarbeitung nach Art. 28 DSGVO.