ISMS für MSPs: Warum Self-Hosted pro Kunde die bessere Architektur ist

Das Multi-Tenancy-Problem bei ISMS-Plattformen

Wenn du als MSP ISMS-as-a-Service anbietest, verwaltest du die sensibelsten Daten deiner Kunden: Risikobewertungen, dokumentierte Schwachstellen, Audit-Ergebnisse, Maßnahmenpläne. Diese Daten sind eine Landkarte der Verwundbarkeiten jedes einzelnen Kundenunternehmens. Wo und wie du diese Daten speicherst, ist keine technische Nebensache. Es ist eine architektonische Grundsatzentscheidung.

Die meisten ISMS-SaaS-Plattformen am Markt nutzen Multi-Tenant-Architekturen. Das bedeutet: Alle Kunden teilen sich dieselbe Infrastruktur, dieselbe Datenbank, oft dieselbe Applikationsinstanz. Die Trennung erfolgt auf Softwareebene, typischerweise durch eine tenant_id in der Datenbank, die sicherstellt, dass Kunde A nur seine eigenen Datensätze sieht. Das ist technisch üblich, bei CRM-Systemen oder Projektmanagement-Tools auch völlig vertretbar. Bei ISMS-Daten ist die Ausgangslage eine andere.

Warum Multi-Tenancy bei ISMS-Daten riskanter ist

Ein ISMS-Tool enthält nicht einfach Geschäftsdaten. Es enthält eine systematische Dokumentation aller bekannten Sicherheitslücken, aller identifizierten Risiken und aller noch nicht umgesetzten Maßnahmen eines Unternehmens. Für einen Angreifer sind das genau die Informationen, die er braucht, um gezielt anzugreifen. Die Schutzbedarfsfeststellung für diese Daten ergibt fast immer die höchste Vertraulichkeitsstufe.

In einer Multi-Tenant-Architektur genügt ein einziger Fehler in der Mandantentrennung, um diese Daten offenzulegen. Und das ist kein hypothetisches Szenario. Die Liste realer Multi-Tenancy-Breaches der letzten Jahre ist lang:

IDOR-Schwachstellen (Insecure Direct Object References): Ein Angreifer ändert eine ID in der URL oder im API-Request und erhält Zugriff auf Daten eines anderen Mandanten. Diese Schwachstellenklasse taucht regelmäßig in Bug-Bounty-Programmen auf und betrifft auch etablierte SaaS-Plattformen.

SQL-Injection mit Tenant-Escape: Wenn die Mandantentrennung auf Datenbankebene durch WHERE-Klauseln erfolgt, kann eine SQL-Injection diese Filter umgehen und auf alle Mandanten zugreifen. Selbst bei parametrisierten Queries kann ein Fehler im ORM-Layer oder in einer Custom Query die Isolation brechen.

Shared-Infrastructure-Kompromittierung: Wenn die zugrundeliegende Infrastruktur kompromittiert wird, ob durch eine Schwachstelle im Hypervisor, im Container-Runtime oder im Cloud-Provider, sind potenziell alle Mandanten betroffen. Die Supply-Chain-Angriffe der letzten Jahre haben gezeigt, wie ein einziger Angriffsvektor tausende Endkunden treffen kann.

Backup- und Log-Leaks: In Multi-Tenant-Systemen enthalten Backups die Daten aller Kunden. Ein kompromittiertes Backup bedeutet ein Datenleck für jeden einzelnen Mandanten. Dasselbe gilt für Log-Dateien, die bei unzureichender Filterung Daten mehrerer Mandanten enthalten können.

Das Kernproblem ist die Blast Radius. Wenn bei einer Self-Hosted-Einzelinstanz etwas schiefgeht, ist genau ein Kunde betroffen. Bei einer Multi-Tenant-Plattform sind es potenziell alle. Für einen MSP mit 50 Kunden bedeutet ein Multi-Tenant-Breach nicht eine Krisenkommunikation, sondern 50 gleichzeitig.

Die Perspektive des Kunden

Betrachte die Situation aus Sicht deines Kunden. Er beauftragt dich, sein ISMS zu betreiben, seine Risiken zu dokumentieren, seine Schwachstellen zu verwalten. Jetzt stellst du dir vor, du erklärst ihm im Erstgespräch: "Ihre Risikoanalysen und Schwachstellendaten liegen in derselben Datenbank wie die Daten aller unserer anderen Kunden. Die Trennung erfolgt über Software."

Vergleiche das mit: "Ihre ISMS-Daten laufen auf einer dedizierten Instanz, auf einem Server, den nur Sie und wir nutzen. Ihre Daten sind physisch getrennt von denen aller anderen Kunden."

Welche Aussage schafft mehr Vertrauen? Welche ist im Audit einfacher zu erklären? Welche reduziert dein eigenes Haftungsrisiko als MSP?

Eine Instanz pro Kunde: Das Isolationsprinzip

Die Alternative zu Multi-Tenancy ist konzeptionell einfach: Jeder Kunde bekommt seine eigene ISMS-Instanz. Eigener Server oder Container, eigene Datenbank, eigene Konfiguration, eigene Backups. Keine geteilte Infrastruktur, keine Softwaretrennung, die versagen kann. Physische Isolation statt logischer Trennung.

Was physische Isolation konkret bedeutet

Wenn du für jeden Kunden eine eigene Instanz betreibst, ergeben sich mehrere Eigenschaften, die bei Multi-Tenancy nicht gegeben sind:

Datenisolation. Die Datenbank von Kunde A und die Datenbank von Kunde B liegen auf verschiedenen Systemen. Es gibt keinen technischen Weg, über den ein Fehler in der Software von Instanz A zu einem Zugriff auf Daten in Instanz B führen kann. Eine SQL-Injection in Instanz A betrifft ausschließlich die Daten von Kunde A.

Unabhängige Updates. Du kannst Instanzen unabhängig voneinander aktualisieren. Wenn ein Update ein Problem verursacht, rollst du die betroffene Instanz zurück, ohne dass andere Kunden davon betroffen sind. Bei Multi-Tenancy-Plattformen betrifft ein fehlerhaftes Update alle Mandanten gleichzeitig.

Individuelle Konfiguration. Jeder Kunde kann seine eigene Sicherheitskonfiguration haben: eigene Passwort-Richtlinien, eigene Session-Timeouts, eigene Backup-Frequenzen. Bei Multi-Tenancy sind diese Einstellungen entweder global oder erfordern zusätzliche Komplexität im Code.

Unabhängige Backups. Jede Instanz hat ihr eigenes Backup. Wenn du ein Backup von Kunde A wiederherstellen musst, berührt das die Daten von Kunde B nicht. Bei Multi-Tenancy muss ein Restore sorgfältig gefiltert werden, um nicht versehentlich Daten anderer Mandanten zu überschreiben.

Individuelle Performance. Wenn Kunde A eine ressourcenintensive Auswertung startet, verlangsamt das nicht die Instanz von Kunde B. Bei Multi-Tenancy kann ein "Noisy Neighbor" die Performance für alle Mandanten beeinträchtigen.

Der Einwand: "Das skaliert doch nicht"

Der häufigste Einwand gegen Einzelinstanzen ist die Skalierung. 50 Kunden bedeuten 50 Server, 50 Datenbanken, 50 Update-Prozesse. Das klingt nach einem Albtraum für den Betrieb.

In der Praxis ist das Gegenteil der Fall, wenn du die richtigen Werkzeuge einsetzt. Containerisierung mit Docker hat das Betreiben vieler isolierter Instanzen trivial gemacht. Ein ISMS-Tool wie ISMS Lite hat keine extremen Ressourcenanforderungen. Die typische Instanz braucht 512 MB RAM und minimale CPU-Leistung. Auf einem einzelnen Server mit 32 GB RAM kannst du problemlos 30-40 Kundeninstanzen betreiben. Für 50+ Kunden brauchst du zwei Server.

Die eigentliche Frage ist nicht ob Einzelinstanzen skalieren, sondern wie du das Deployment und Management automatisierst. Und genau das ist mit modernen DevOps-Werkzeugen ein gelöstes Problem.

Deployment-Automatisierung: Docker Compose pro Kunde in 5 Minuten

Schauen wir uns an, wie das Deployment einer neuen Kundeninstanz in der Praxis aussieht. Das Ziel: Ein neuer Kunde meldet sich an, und innerhalb von 5 Minuten läuft seine eigene ISMS-Instanz.

Die Architektur

Jede Kundeninstanz besteht aus einem minimalen Stack:

Der Reverse Proxy (Nginx, Traefik oder Caddy) ist die einzige geteilte Komponente. Er nimmt die HTTPS-Verbindungen entgegen und leitet sie an die richtige Kundeninstanz weiter. Traefik eignet sich besonders gut, weil er Docker-Container automatisch erkennt und das TLS-Zertifikat per Let's Encrypt ausstellt.

Der Deployment-Prozess

Im Kern ist das Deployment einer neuen Instanz ein einziger Befehl. Du kopierst eine Vorlage, passt die Konfiguration an und startest die Container. Das gesamte Verfahren lässt sich in ein Shell-Script fassen, das drei Parameter entgegennimmt: Kundenname, Subdomain und Admin-E-Mail.

Schritt 1: Konfiguration generieren. Das Script erstellt eine Docker-Compose-Datei aus einer Vorlage, setzt die kundenspezifischen Variablen (Domain, Datenbankpasswort, Admin-Credentials) und legt die Verzeichnisstruktur für persistente Daten an.

Schritt 2: Container starten. Ein docker compose up -d startet die Instanz. Traefik erkennt den neuen Container automatisch über Labels und routet den Traffic. Das Let's-Encrypt-Zertifikat wird innerhalb von Sekunden ausgestellt.

Schritt 3: Initialisierung. Die Applikation führt beim ersten Start automatisch das Setup durch: Datenbank-Migration, Admin-Account anlegen, Standardkonfiguration setzen.

Schritt 4: Verifizierung. Das Script prüft, ob die Instanz erreichbar ist und der Login funktioniert. Dann sendet es eine Willkommens-E-Mail an den Kundenadministrator.

Von Schritt 1 bis zum fertigen Login vergehen unter 5 Minuten. Bei einem gut eingespielten Prozess oft weniger als 3.

Skalierung auf 50+ Kunden

Wenn du mehr als eine Handvoll Kunden betreust, willst du das Management nicht für jede Instanz einzeln machen. Hier sind die Werkzeuge, die den Betrieb vieler Instanzen handhabbar machen:

Portainer oder Rancher für die Container-Verwaltung: Eine zentrale Oberfläche, über die du alle Kundeninstanzen sehen, starten, stoppen und überwachen kannst. Portainer läuft selbst als Container und braucht minimale Ressourcen.

Watchtower oder eigene CI/CD-Pipeline für Updates: Watchtower prüft regelmäßig, ob ein neues Image vorliegt, und aktualisiert die Container automatisch. Für mehr Kontrolle setzt du eine CI/CD-Pipeline auf, die Updates rollierend ausrollt, erst auf einer Testinstanz, dann auf wenigen Kunden, dann auf allen.

Uptime Kuma oder Grafana für Monitoring: Ein zentrales Monitoring, das die Erreichbarkeit und Performance aller Instanzen überwacht. Uptime Kuma ist besonders für MSPs geeignet, weil es leichtgewichtig ist und Status-Pages pro Kunde erzeugen kann.

Restic oder BorgBackup für Backups: Automatisierte, verschlüsselte Backups aller Kundeninstanzen auf einen zentralen Backup-Server oder S3-kompatiblen Storage. Jede Instanz wird unabhängig gesichert, sodass ein Restore einzelner Kunden möglich ist, ohne andere zu berühren. Die Backup-Verschlüsselung ist dabei nicht optional, sondern Pflicht.

Beispiel: Ressourcenplanung für 50 Kunden

Wie sieht der tatsächliche Infrastrukturbedarf aus? Rechnen wir konservativ:

Das entspricht zwei dedizierten Servern mit je 32 GB RAM und 8 Cores. Bei Hetzner, Netcup oder einem vergleichbaren deutschen Hoster kostet das zwischen 80 und 150 Euro pro Monat. Für 50 Kunden-ISMS-Instanzen.

Vergleiche das mit den typischen SaaS-Kosten: Eine Multi-Tenant-ISMS-Plattform berechnet pro Mandant und Nutzer. Bei 50 Kunden mit durchschnittlich 5 Nutzern und 30 Euro pro Nutzer pro Monat landest du bei 7.500 Euro monatlich. Die Self-Hosted-Variante kostet dich circa 150 Euro monatlich für die Infrastruktur plus die einmalige Lizenz.

Preismodell: ISMS Lite MSP-Paket

Die meisten ISMS-Tools am Markt sind auf den Einzelkunden ausgelegt. Sie verkaufen Seat-Lizenzen, und jeder weitere Nutzer kostet extra. Für einen MSP, der 50 Kunden mit jeweils 3-10 Nutzern betreut, summiert sich das schnell auf fünfstellige monatliche Beträge.

ISMS Lite bietet ein MSP-Paket, das auf die Bedürfnisse von IT-Dienstleistern zugeschnitten ist:

10.000 Euro einmalig. Unbegrenzte Instanzen. Keine Seat-Lizenzen.

Das bedeutet: Du zahlst einmal und kannst so viele Kundeninstanzen deployen, wie du brauchst. Ob 10 oder 200. Keine laufenden Lizenzkosten pro Kunde, keine Gebühr pro Nutzer. Die einzigen laufenden Kosten sind deine Infrastruktur (Server, Hosting) und dein Personal.

Wirtschaftlichkeitsrechnung für einen MSP

Nehmen wir einen MSP mit 30 ISMS-Kunden als Rechenbeispiel:

Einmalige Kosten:

Laufende Kosten pro Monat:

Umsatz pro Monat:

Wenn du den ISMS-Service im Basis-Paket für 1.000 Euro pro Monat pro Kunde anbietest (was am unteren Ende der üblichen Pricing-Modelle für ISMS-Services liegt), generierst du mit 30 Kunden 30.000 Euro Recurring Revenue. Deine Tool- und Infrastrukturkosten liegen bei 200 Euro pro Monat. Die ISMS-Lite-Lizenz hat sich nach dem ersten halben Kundenabruf amortisiert.

Die eigentlichen Kosten liegen im Personal, nicht im Tooling. Du brauchst ISMS-Berater, die die Kunden betreuen. Aber genau das ist dein Geschäftsmodell als MSP: Expertise verkaufen, nicht Software weiterverkaufen.

Vergleich mit SaaS-Alternativen

Kundendaten nie vermischt: Warum das mehr als ein technisches Detail ist

Die physische Trennung von Kundendaten ist nicht nur eine technische Architekturentscheidung. Sie hat konkrete Auswirkungen auf Verträge, Haftung und Kundenbeziehungen.

Vertragliche Vereinfachung

Wenn du deinen Kunden erklären musst, wie die Mandantentrennung in einer Multi-Tenant-Plattform funktioniert, wird der Auftragsverarbeitungsvertrag komplex. Du musst technische Maßnahmen zur Mandantentrennung dokumentieren, Subauftragsverarbeiter des SaaS-Anbieters auflisten und erklären, warum die logische Trennung ausreichend ist.

Bei einer dedizierten Instanz ist die Erklärung einfach: "Ihre Daten laufen auf einem eigenen Server. Kein anderer Kunde hat Zugriff auf diesen Server. Punkt." Der AVV wird kürzer, die Risikobeurteilung einfacher, die Genehmigung durch den Datenschutzbeauftragten des Kunden schneller.

Haftungsreduktion

Als MSP trägst du Verantwortung für die Sicherheit der Kundendaten, die du im Rahmen des ISMS-Services verarbeitest. Wenn ein Sicherheitsvorfall bei einem Multi-Tenant-System alle Mandanten betrifft, hast du gleichzeitig 30 oder 50 Datenschutzverletzungen. Jeder einzelne Kunde kann Ansprüche geltend machen. Die NIS2-Bußgelder multiplizieren sich nicht, aber der Reputationsschaden und die Aufarbeitungskosten tun es.

Bei isolierten Instanzen ist der Worst Case auf einen Kunden begrenzt. Das ist immer noch schlecht, aber es ist ein beherrschbarer Vorfall statt einer Katastrophe.

Kundenkommunikation

In regulierten Branchen ist die Frage "Wo liegen meine Daten?" eine Standardfrage im Beschaffungsprozess. Kunden in der kritischen Infrastruktur, im Gesundheitswesen oder in der Verteidigungsindustrie haben oft explizite Anforderungen an die Datenisolation. Mit einer dedizierten Instanz erfüllst du diese Anforderung per Design, ohne Diskussion.

Und auch Kunden ohne explizite Anforderungen reagieren positiv, wenn du ihnen erklärst, dass ihre ISMS-Daten auf einer eigenen Instanz laufen. Es signalisiert Professionalität und zeigt, dass du die Sensibilität der Daten verstanden hast.

Der Audit-Vorteil: Jeder Kunde hat seinen eigenen Server

Wenn deine Kunden auditiert werden, ob intern, durch einen ISO-27001-Auditor oder durch eine Aufsichtsbehörde im Rahmen von NIS2, wird die Frage nach der Sicherheit der eingesetzten Tools gestellt. Und bei einem ISMS-Tool wird besonders genau hingeschaut, weil es die Kerndokumentation des Sicherheitsmanagements enthält.

Was Auditoren fragen

Ein typischer Fragenkatalog zum ISMS-Tooling umfasst:

• Wo werden die Daten gespeichert?
• Wer hat Zugriff auf die Daten?
• Wie ist die Mandantentrennung umgesetzt?
• Wie sind die Daten verschlüsselt (at rest und in transit)?
• Wie sieht das Backup-Konzept aus?
• Welche Subauftragsverarbeiter sind beteiligt?
• Was passiert bei einem Sicherheitsvorfall beim Toolanbieter?

Bei einer Multi-Tenant-SaaS-Lösung musst du für jede dieser Fragen auf die Dokumentation des SaaS-Anbieters verweisen. Du bist darauf angewiesen, dass der Anbieter aktuelle und vollständige Nachweise liefert. Wenn er eine ISO-27001-Zertifizierung hat, ist das hilfreich, aber der Auditor kann trotzdem Detailfragen stellen, die der Anbieter nicht oder nicht zeitnah beantwortet.

Der Vorteil dedizierter Instanzen

Bei einer Self-Hosted-Instanz kannst du jede dieser Fragen direkt beantworten:

Diese Antworten sind konkret, nachprüfbar und erzeugen kein "Da müssen wir beim Anbieter nachfragen". Der Auditor bekommt klare Aussagen und du sparst dir Rückfragen und Wartezeiten.

Audit-Dokumentation pro Kunde

Ein weiterer praktischer Vorteil: Du kannst für jeden Kunden eine individuelle Sicherheitsdokumentation seiner ISMS-Instanz erstellen. Diese Dokumentation enthält die spezifische Serverkonfiguration, die Zugriffsrechte, das Backup-Konzept und die Verschlüsselungsparameter für genau seine Instanz. In ISMS Lite lässt sich diese technische Dokumentation direkt als Nachweis für das interne Audit verknüpfen, sodass der Auditor Konfiguration und Compliance-Status an einer Stelle findet.

Bei einem Multi-Tenant-System ist diese Dokumentation generisch, weil alle Kunden dieselbe Infrastruktur nutzen. Das ist nicht falsch, aber es wirkt weniger überzeugend als ein Dokument, das sagt: "Ihr Server heißt isms-kunde-a.msp-domain.de, läuft auf Hetzner in Falkenstein, hat IP-Adresse X und wurde am Y zuletzt gepatcht."

Häufige Einwände und ehrliche Antworten

"Wir haben nicht die Kapazität, 50 Server zu administrieren"

Verständlicher Einwand, aber er basiert auf dem Bild klassischer Serververwaltung: Jeder Server einzeln konfigurieren, einzeln updaten, einzeln überwachen. Mit Container-Orchestrierung sieht die Realität anders aus. Ein docker compose pull && docker compose up -d aktualisiert eine Instanz. Ein Bash-Script, das diesen Befehl für alle Instanzen ausführt, aktualisiert 50 Instanzen in einer Schleife. Ein zentrales Monitoring zeigt dir alle 50 Instanzen auf einem Dashboard. Der Mehraufwand gegenüber einer einzelnen Multi-Tenant-Instanz ist real, aber er liegt bei Stunden pro Monat, nicht bei Tagen.

"Was wenn ein Sicherheitspatch sofort auf alle Instanzen muss?"

Genau dafür hast du die Automatisierung. Ein Rolling Update, das nacheinander jede Instanz aktualisiert und kurz prüft, ob sie noch funktioniert, ist in wenigen Minuten über alle Kunden ausgerollt. Und du hast die Option, die kritischsten Kunden zuerst zu patchen und bei Problemen zu stoppen, bevor alle betroffen sind. Bei Multi-Tenancy hast du diese Granularität nicht: Es wird für alle gleichzeitig aktualisiert, oder für niemanden.

"Unsere Kunden wollen eine zentrale Plattform, nicht einzelne Instanzen"

Deine Kunden wollen kein Architekturkonzept. Sie wollen ein funktionierendes ISMS, das sicher ist und im Audit besteht. Ob dahinter eine oder fünfzig Instanzen laufen, ist für den Kunden transparent. Er loggt sich auf seiner URL ein, sieht seine Daten und arbeitet damit. Dass im Hintergrund eine dedizierte Instanz läuft, ist für ihn ein Qualitätsmerkmal, kein Nachteil.

Für dich als MSP brauchst du eine zentrale Übersicht über alle Kundeninstanzen. Das löst du über ein Dashboard oder ein Monitoring-Tool, nicht über eine gemeinsame Datenbank.

"Multi-Tenancy ist doch Industriestandard"

Ja, bei Office-Software, CRM und Projektmanagement. Also überall dort, wo ein Datenleck ärgerlich, aber nicht existenzbedrohend ist. Bei Sicherheitssoftware gelten andere Maßstäbe. Dein Penetrationstest-Anbieter speichert die Ergebnisse auch nicht in einer geteilten Datenbank mit den Ergebnissen aller anderen Kunden. Warum sollte dein ISMS-Tool das tun?

Checkliste: Self-Hosted ISMS für MSPs

Wenn du den Schritt zu Self-Hosted-Einzelinstanzen gehen willst, brauchst du folgende Bausteine:

• Infrastruktur: Mindestens zwei dedizierte Server bei einem deutschen Hoster (Redundanz)
• Reverse Proxy: Traefik oder Caddy mit automatischer Let's-Encrypt-Zertifizierung
• Deployment-Script: Automatisiertes Onboarding neuer Kunden in unter 5 Minuten
• Update-Prozess: Rolling-Update-Script für alle Instanzen mit Health-Check
• Monitoring: Zentrale Überwachung aller Instanzen (Uptime, Performance, Disk Usage)
• Backup: Automatisierte, verschlüsselte Backups aller Instanzen auf separaten Storage
• Dokumentation: Pro-Kunde-Sicherheitsdokumentation (Serverkonfiguration, Zugriffsrechte, Backup-Konzept)
• AVV: Auftragsverarbeitungsvertrag pro Kunde, angepasst an das Self-Hosted-Modell
• Incident-Response: Prozess für Sicherheitsvorfälle, der die Isolation einzelner Instanzen berücksichtigt
• ISMS-Lizenz: ISMS Lite MSP-Paket (10.000 € einmalig, unbegrenzte Instanzen)

Häufige Fehler bei der Umsetzung

Alle Instanzen auf einem Server ohne Redundanz. Wenn der eine Server ausfällt, sind alle Kunden offline. Verteile die Instanzen auf mindestens zwei Server und plane einen Failover-Mechanismus.

Backups nicht verschlüsseln. Jedes Backup muss verschlüsselt sein, mit einem Schlüssel, der nicht auf demselben Server liegt. Unverschlüsselte Backups machen die gesamte Isolation wertlos, wenn ein Angreifer an den Backup-Storage kommt.

Updates aufschieben. Nur weil du jetzt 50 einzelne Instanzen betreibst, heißt das nicht, dass du Updates aussitzen kannst. Automatisiere den Update-Prozess und führe Sicherheitsupdates zeitnah aus. Ein Patch-Management-Prozess ist auch für deine eigene Infrastruktur Pflicht.

Zugriffsrechte nicht dokumentieren. Wer aus deinem Team hat SSH-Zugriff auf welche Kundeninstanzen? Dokumentiere das und prüfe regelmäßig, ob die Rechte noch aktuell sind. Ein ausgeschiedener Mitarbeiter, der noch Zugriff auf 50 Kundeninstanzen hat, ist ein erhebliches Risiko.

Kein zentrales Logging. Auch bei isolierten Instanzen brauchst du ein zentrales Log-Management, um Anomalien über alle Kunden hinweg erkennen zu können. Ein Angreifer, der systematisch Instanzen testet, fällt nur auf, wenn du die Logs aller Instanzen korrelierst.

Fazit: Isolation ist kein Luxus, sondern die richtige Architektur für ISMS-Daten

Multi-Tenancy hat seine Berechtigung. Bei einem Projektmanagement-Tool, einem CRM oder einem Ticketsystem ist die geteilte Infrastruktur ein vernünftiger Kompromiss zwischen Effizienz und Sicherheit. Bei einem ISMS-Tool, das die dokumentierten Schwachstellen, Risiken und Sicherheitslücken deiner Kunden enthält, verschiebt sich dieses Gleichgewicht.

Für MSPs, die ISMS als Service anbieten, ist die Einzelinstanz pro Kunde nicht der aufwändigere Weg. Sie ist der professionellere. Der Mehraufwand im Betrieb ist mit moderner Container-Technologie überschaubar. Die Vorteile bei Sicherheit, Audit-Fähigkeit, Vertragsgestaltung und Kundenvertrauen sind erheblich. Und die Kosten liegen mit dem ISMS Lite MSP-Paket deutlich unter jeder vergleichbaren SaaS-Alternative.

Der nächste Schritt: Evaluiere deine aktuelle Infrastruktur, plane das Deployment-Setup und sprich mit deinen Kunden über die Vorteile dedizierter Instanzen. Die meisten werden nicht fragen, warum du das machst. Sie werden fragen, warum du es nicht schon vorher so gemacht hast.

Weiterführende Artikel

• NIS2 für IT-Dienstleister und MSPs: Doppelrolle als Betroffener und Berater
• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• Verschlüsselung im Unternehmen: Was, wo und wie verschlüsseln
• Lieferantenbewertung mit Sicherheitsfragebogen: Vorlage und Vorgehen
• Container-Sicherheit: Docker und Kubernetes im Mittelstand absichern