Funktion: Mehrmandantenfähigkeit
Mehrmandantenfähig: Jede Schule mit eigener Datenisolation.
Saubere Trennung zwischen Schulen. DSGVO + revidiertes Datenschutzgesetz. EU-Hosting (Frankfurt), Schweizer Hosting in Vorbereitung.
Mehrmandantenfähigkeit ist keine Funktion, die man ein- oder ausschaltet — sie ist eine Entscheidung in der Datenarchitektur. Kompetenzmonitor wurde von Anfang an so gebaut, dass jede Schule (jeder "Mandant") in einer eigenen logischen Datenebene lebt. Keine Schule sieht die Daten einer anderen. Auch Kompetenzmonitor-Administrator:innen haben kein Default-Zugriffsrecht auf Schul-Daten. Was das konkret bedeutet: selbst wenn ein technischer Fehler in der Anwendung auftreten würde, kann er nicht zu einer Datenvermischung zwischen Schulen führen — weil die Trennung auf Datenbankebene verankert ist, nicht in der Anwendungslogik.
Was es ist
Datenisolation auf Datenbankebene — nicht per Zugriffsrecht
Ein Mandant ist in der Softwarearchitektur ein einzelner unabhängiger Nutzer eines Systems — hier: eine Schule oder ein Schulverbund. Mehrmandantenfähigkeit (englisch: multi-tenancy) bedeutet, dass ein System mehrere solcher Mandanten gleichzeitig betreiben kann, ohne dass deren Daten sich vermischen.
Die einfachste Form der Mandantentrennung — eine Spalte "Schule-ID" in jeder Datenbanktabelle — ist weit verbreitet, aber schwach: Die Trennung existiert nur in der Anwendungslogik. Wird eine Abfrage falsch gebaut oder enthält die Anwendung einen Bug, kann sie trotzdem Daten einer fremden Schule zurückliefern. Kompetenzmonitor geht einen Schritt weiter: separates Datenbankschema pro Schule. Jede Schule erhält ihr eigenes Schema in der Datenbank. Queries, die im Kontext von Schule A laufen, kommen Schule B physisch nicht zu sehen — nicht weil eine Regel das verhindert, sondern weil die Daten schlicht in verschiedenen Schemata liegen.
Das unterscheidet sich grundlegend von rollenbasierter Zugriffskontrolle (RBAC). Bei RBAC können technische Fehler auf Anwendungsebene immer noch zu Datenverletzungen führen — ein vergessenes WHERE-Klausel in einer SQL-Abfrage, ein fehlerhafter Filter oder eine unvorhergesehene Interaktion zwischen Features. Die Isolation bleibt dann nur ein Konzept, das von korrektem Code abhängt. Mit Schema-Level-Isolation wird diese ganze Fehlerklasse eliminiert: Die Datenbankebene selbst macht Cross-Mandant-Zugriff unmöglich. Es gibt keinen Code-Fehler, der Schule A plötzlich in das Schema von Schule B schauen lässt.
Jeder Aufruf an die Anwendung trägt den Mandanten-Kontext mit. Der Datenbank-Router leitet alle Queries automatisch an das korrekte Schema weiter. Es gibt keinen manuellen Schritt, bei dem eine Lehrperson oder ein Admin die "falsche Schule" auswählen und dadurch Daten sehen könnte.
Pädagogisch-technischer Hintergrund: Wie Kompetenzmonitor Datensicherheit umsetzt
Wie es im Betrieb aussieht
Was Mehrmandantenfähigkeit für den Schulalltag bedeutet
Wenn eine neue Schule Kompetenzmonitor startet, wird ein eigener Mandant angelegt: ein dediziertes Datenbankschema, eine eindeutige Mandanten-ID, eine separate Benutzer-Hierarchie. Dieser Onboarding-Schritt passiert technisch, nicht administrativ — die Schul-Admin-Person erhält Zugang zu einem leeren, sauberen System, das ausschliesslich für ihre Schule existiert.
Die Schul-Administratorin verwaltet Lehrpersonen, Schüler:innen und Klassen innerhalb des eigenen Mandanten. Sie sieht keine Daten anderer Schulen — nicht zufällig, sondern architektonisch sichergestellt. Wenn zwei Schulleitungen befreundeter Schulen beide Kompetenzmonitor nutzen, existieren ihre Schulen trotzdem vollständig getrennt voneinander.
Kompetenzmonitor produziert keine kantonalen Vergleiche aus Mandanten-Daten. Aggregierte oder anonymisierte Statistiken werden nicht zwischen Mandanten geteilt. Jede Schule bleibt in ihrer eigenen Datenebene — die Plattform gibt keine schulübergreifenden Auswertungen heraus, auch nicht an die Schulleitung anderer Mandanten.
Im Sicherheitsfall — etwa eine kompromittierte Lehrperson-Identität durch einen Phishing-Angriff — ist der potenzielle Datenschaden auf einen einzigen Mandanten begrenzt. Andere Schulen auf Kompetenzmonitor sind durch die Architektur geschützt, nicht durch eine Konfiguration, die jemand vergessen könnte anzupassen.
Wenn ein Kompetenzmonitor-Mitarbeitender für einen Support-Fall einen Schul-Mandanten betritt, wird das im Audit-Log dokumentiert: Wer hat Zugriff genommen, wann, auf welchen Mandanten, und in welchem Support-Fall. Die Schule sieht dieses Log in ihrer Admin-Übersicht. So bleibt jeder externe Zugriff nachvollziehbar und transparent. Die Verantwortlichen auf beiden Seiten — Schule und Betreiber — können das Geschehen lückenlos prüfen.
Wer davon profitiert
Was es löst — und für wen
Für die Schulleitung: Datenschutz-Argumente, die standhalten
Bei kantonalen Audits oder internen Datenschutz-Folgeabschätzungen ist die Mandantentrennung auf Schemaebene ein starkes Argument: Die Isolation ist architektonisch garantiert, nicht abhängig von Benutzerrollen oder Zugriffsrechten, die jemand vergessen könnte zu pflegen. Das vereinfacht die Dokumentation erheblich — statt eine Liste von Benutzer-Berechtigungen vorzulegen, reicht eine technische Beschreibung der Datenbankarchitektur. Datenschutzbeauftragte auf Schulebene oder Kantonsebene können das verifizieren lassen. Ein konkretes Beispiel: In einer RBAC-Umgebung müsste ein Auditor prüfen, ob alle Datenbankrollen und Permissions wirklich korrekt gesetzt sind und ob Code-Changes niemals eine Spalte vergessen haben. Bei Schema-Level-Isolation reicht die Überprüfung, dass das technische Design der Datenbankebene saubere Grenzen zieht — einfacher, transparenter, überzeugender.
Für IT-Verantwortliche und Datenschutzbeauftragte: begrenzte Schadensfläche
Für IT-Beauftragte an Schulen bedeutet Mandantentrennung: Im Fall eines Sicherheitsvorfalls bleibt der Schaden mandanten-lokal. Eine kompromittierte Identität öffnet maximal den eigenen Mandanten — nicht alle anderen Schulen auf der Plattform. Incident-Response-Pläne werden einfacher, weil der Perimeter klar ist. Und die Frage "Wie stellen wir sicher, dass Schüler:innen-Daten unserer Schule nicht mit anderen Schulen geteilt werden?" hat eine technisch präzise Antwort. Konkret: Wenn ein Angreifer den Zugang eines Lehrers kompromittiert, ist der Zugriff auf das Schema dieser einen Schule beschränkt. Der Datenbankserver selbst erlaubt dem kompromittierten Account nicht, andere Schulen zu durchsuchen. Der Vorfall bleibt isoliert.
Häufige Fragen
Wer kann unsere Daten sehen?
Innerhalb Ihrer Schule: nur Personen mit explizitem Zugriff — Lehrpersonen in ihren Klassen, der Schul-Admin, Schüler:innen für ihre eigenen Daten, Eltern für ihre Kinder. Ausserhalb Ihrer Schule: niemand. Auch keine andere Schule, die Kompetenzmonitor nutzt. Kompetenzmonitor-Mitarbeitende greifen auf Schul-Daten ausschliesslich mit dokumentierter Schul-Einwilligung im Support-Fall zu — kein routinemässiger Datenzugang durch den Betreiber.
Was passiert bei einem Hack?
Bei einem Sicherheitsvorfall ist der Datenschaden auf den betroffenen Mandanten begrenzt, weil jede Schule auf Datenbankebene physisch isoliert ist. Ein kompromittierter Account einer Schule führt nicht zu einem Datenleck einer anderen Schule. Incident-Response: 24-Stunden-Notification an alle betroffenen Schul-Admins, parallel an die kantonale Datenschutzaufsicht falls gesetzlich vorgeschrieben.
Sind die Daten verschlüsselt?
Ja, auf zwei Ebenen: Transport-Verschlüsselung (TLS 1.3) zwischen Browser und Server, sowie At-Rest-Verschlüsselung der Datenbank-Volumes. Schlüssel werden im Cloud-KMS verwaltet und rotieren periodisch. Backups sind ebenfalls verschlüsselt — dieselbe Schlüssel-Hierarchie gilt für alle gespeicherten Daten, nicht nur für Live-Daten.
Wo werden Backups gelagert?
Backups laufen täglich, werden verschlüsselt in der EU-Region (Frankfurt) aufbewahrt und sind 30 Tage rückwirkend wiederherstellbar. Geo-Redundanz: Backups werden zusätzlich in einem zweiten EU-Datacenter gespiegelt. Sobald das Schweizer Hosting in Vorbereitung produktiv ist, werden Backups in der Schweiz gehalten.
Wie unterscheidet sich Mehrmandantenfähigkeit von einer reinen Datenbank-Trennung?
Reine Datenbank-Trennung — also eine Schule-ID-Spalte pro Tabelle — ist die schwächste Form der Isolation: Ein Bug in der Anwendung kann trotzdem zu Cross-Schul-Sichtbarkeit führen. Mehrmandantenfähigkeit auf Schema-Ebene, wie Kompetenzmonitor sie umsetzt, macht das auf SQL-Ebene unmöglich: Die Queries einer Schule haben physisch keinen Zugang zu den Daten einer anderen Schule. Das ist nicht nur sicherer — es ist bei Datenschutz-Audits leichter dokumentierbar, weil die Trennung in der Architektur verankert ist, nicht in Anwendungslogik.
Verwandte Seiten
Das gehört zusammen
Mehrmandantenfähigkeit ist ein Baustein der Datensicherheits-Architektur. Hier sind die Seiten, die den vollständigen Kontext liefern.
Sicherheit: Datenschutz, Hosting, Audit-Trails
Die vollständige Übersicht über Datenschutz und Sicherheit bei Kompetenzmonitor.
Für Schulleitungen: Was sich für Sie ändert
Wie sich Mehrmandantenfähigkeit aus der Schulleitungs-Perspektive auswirkt.
Glossar: Kompetenzorientierte Beurteilung
Der pädagogische Rahmen, den Mehrmandantenfähigkeit schützt.
Verwandte Funktionen
Diese Funktionen arbeiten mit Mehrmandantenfähigkeit zusammen
Erfassen: Kompetenz-Beobachtungen
Wie Lehrpersonen Kompetenzen pro Schüler und Niveau dokumentieren.
Niveaus 1–3: Stufen der Kompetenz
Die drei Erreichungsstufen, auf denen jede Schule ihre Daten strukturiert.
Zeugnis-Umrechnung: Von Niveaus zu Noten
Wie Kompetenzmonitor Niveau-Dokumentation mit Schulnoten verbindet.
Datenschutz, der nicht konfiguriert werden muss.
Kompetenzmonitor trennt Schul-Daten auf Datenbankebene — von Anfang an. Testen Sie 30 Tage lang, oder sehen Sie in einer Demo, wie die Architektur in der Praxis funktioniert.