Warum stehen MSP-Backups plötzlich unter so großem Druck?
Managed Service Provider stehen unter neuem Druck, da Kunden, Aufsichtsbehörden und Angreifer Backups von Protokollen und Konfigurationen mittlerweile als wichtigen Nachweis für die Zuverlässigkeit betrachten. Von Ihnen wird erwartet, dass Sie nachweisen, dass diese Datensätze geschützt, wiederherstellbar und vertrauenswürdig sind, wann immer etwas schiefgeht – und nicht nur, dass die Server wieder online sind.
Gute Backup-Geschichten sind letztendlich Geschichten über Vertrauen, nicht über Datenspeicherung.
Dieser Artikel bietet allgemeine Informationen zur Backup-Governance für Managed Service Provider (MSPs). Er stellt keine Rechts-, Regulierungs- oder Versicherungsberatung dar. Sie sollten sich daher vor wichtigen Entscheidungen fachkundig beraten lassen.
In den letzten Jahren haben mehrere Vorfälle bei Serviceprovidern ein ähnliches Muster offenbart: Ein Kunde erleidet einen Ausfall oder eine Sicherheitslücke, der Managed Service Provider (MSP) stellt die Kernserver zügig wieder her, doch die Protokolle und Konfigurationsdaten, die zur Analyse, zum Nachweis und zur vollständigen Wiederherstellung des Vorfalls erforderlich sind, wurden entweder gar nicht gesichert oder befanden sich auf demselben Speichermedium, das ausgefallen ist. Unabhängige Fallstudien zu MSP-Vorfällen belegen dieses Muster immer wieder und zeigen, wie fehlende oder zerstörte Protokolle und Konfigurationen behebbare Fehler in langwierige Vertrauenskrisen verwandeln. So wird aus einem technischen Problem ein Vertrauensproblem. Vorstände und Sicherheitsverantwortliche Ihrer Kunden fragen daher explizit: „Wenn etwas schiefgeht, können Sie uns den Hergang aufzeigen und uns in einen bekannten, einwandfreien Zustand zurückversetzen?“
Die Erwartungen sind parallel gestiegen. Kunden gehen oft davon aus, dass alle relevanten Informationen – Sicherheitsprotokolle, SaaS-Audit-Trails, Firewall-Regeln, Identitätskonfigurationen und Infrastruktur-als-Code – gesichert, aufbewahrt und getestet werden. Viele Managed Service Provider (MSPs) behandeln Protokolle und Konfigurationen hingegen weiterhin als „flüchtig“ oder „wiederbringlich“ und konzentrieren ihre formalen Backup-Strategien auf Dateiserver und Datenbanken. Branchenumfragen zu den Backup-Praktiken von MSPs und den Kundenerwartungen, wie beispielsweise Studien zu den Backup-Erwartungen an MSPs, zeigen eine deutliche Diskrepanz zwischen dem, was Kunden als geschützt ansehen, und dem, was Anbieter tatsächlich sichern. Genau diese Diskrepanz führt zu Audit-Befunden, angespannten Quartalsberichten und verlorenen Aufträgen.
Angreifer haben gelernt, Backup-Plattformen und Protokollspeicher direkt anzugreifen. Ransomware-Gruppen versuchen, Backup-Aufträge zu deaktivieren oder zu beschädigen, Snapshots zu löschen und Sicherheitsprotokolle zu manipulieren. Bedrohungsberichte zum Missbrauch von Backup-Plattformen, darunter Analysen wie Ransomware-Angriffe auf Backup-Systeme, beschreiben, wie Angreifer sich in Konsolen einloggen, Aufbewahrungsaufträge löschen und Archive beschädigen, bevor sie die Verschlüsselung auslösen. Ein „grüner“ Status in einer Backup-Konsole ist wenig wert, wenn er gefälscht werden kann oder wenn Protokoll- und Konfigurations-Backups im selben Gefahrenbereich liegen – also im selben Bereich von Systemen, die von einem Ausfall oder Angriff betroffen sind – wie die Produktionssysteme. Kunden und Auditoren lassen sich nicht mehr allein auf Herstellerangaben verlassen und fordern Nachweise dafür, dass Backups unter Berücksichtigung dieser Bedrohungen konzipiert und betrieben werden.
Aufsichtsbehörden und Versicherer erhöhen den Druck. Viele branchenspezifische Vorschriften und Meldesysteme für Vorfälle setzen mittlerweile voraus, dass Unternehmen einen Ereignisablauf anhand von Protokollen rekonstruieren und Dienste mithilfe gespeicherter Konfigurationen wiederherstellen können. Regulatorische Leitlinien zur Protokollaufbewahrung und zum Umgang mit Vorfällen, wie beispielsweise die Erwartungen an die Reaktion auf Vorfälle mit Protokolldaten, betrachten die Möglichkeit, Ereignisse aus Protokollen wiederzugeben und Dienste anhand gespeicherter Konfigurationen wiederherzustellen, zunehmend als grundlegende Voraussetzung. Wenn Ihre Kunden ihre Geschäftsprozesse an Sie auslagern, verlassen sie sich darauf, dass Ihre Datensicherungsstrategie diese Verpflichtungen erfüllt. Ihre internen Risikoregister führen Datensicherungen von Drittanbietern immer häufiger als eigenständigen Punkt auf, und Lieferantenrisikobewertungen untersuchen eingehend, wie Sie Protokolle, Konfigurationen und Wiederherstellungstests handhaben.
In der ISMS.online-Umfrage 2025 nannten rund 41 % der Unternehmen die Bewältigung von Drittparteirisiken und die Überwachung der Lieferantenkonformität als eine ihrer größten Sicherheitsherausforderungen.
All das bedeutet, dass Datensicherung kein stilles, technisches Nischenthema mehr ist. Sie beeinflusst maßgeblich, wie Kunden Ihre Zuverlässigkeit beurteilen, wie Auditoren die Reife Ihrer Kontrollsysteme bewerten und wie Ihr eigener Vorstand Ihr Risiko einschätzt. Die ISO 27001:2022-Kontrolle A.8.13 – „Datensicherung“ – ist zu einem der wichtigsten Kriterien geworden. Kommentare zu A.8.13 für Service Provider, wie beispielsweise serviceorientierte Interpretationen der Kontrolle, weisen ausdrücklich darauf hin, dass Kunden, Auditoren und Versicherer diese Kontrolle nun nutzen, um zu beurteilen, wie gut Managed Service Provider (MSPs) die für Wiederherstellung und Untersuchung benötigten Informationen sichern. In den folgenden Abschnitten erfahren Sie, was diese Kontrolle konkret von Ihnen als MSP verlangt und wie Sie diese Anforderungen in einen klaren, nachvollziehbaren Backup-Standard für Kundenprotokolle, Konfigurationen und Betriebssysteme umsetzen können.
Wie haben sich Backups von einer einfachen Verwaltungsaufgabe zu einem strategischen Anliegen von Managed Service Providern entwickelt?
Datensicherungen haben sich von einer routinemäßigen Hintergrundaufgabe zu einem strategischen Anliegen von Managed Service Providern (MSPs) entwickelt, da komplexe IT-Systeme, öffentliche Vorfälle und anspruchsvollere Kunden deutlich gemacht haben, wie sehr Wiederherstellung und Untersuchungen von mehr als nur Dateiservern abhängen. Was früher eine unauffällige, nächtliche Aufgabe war, ist heute eine plattformübergreifende Disziplin mit direkten geschäftlichen Auswirkungen.
Früher war die Datensicherung ein unkomplizierter Vorgang: nächtliche Backups durchführen, Datenträger rotieren, Kopien extern speichern und gelegentlich die Wiederherstellung testen. Der Umfang war meist klar – Dateiserver, Anwendungsdatenbanken, eventuell einige virtuelle Maschinen – und Kunden stellten selten detaillierte Fragen. Die Umgebung war einfacher, und damit auch die Erwartungen.
Heutzutage umfasst Ihre IT-Landschaft wahrscheinlich lokale Infrastruktur, mehrere Public Clouds, SaaS-Plattformen, moderne Identitätssysteme, Sicherheitstools und eine Vielzahl von Edge-Geräten. Protokolle und Konfigurationsdaten befinden sich an vielen Orten: in SIEM-Indizes, Firewalls und VPN-Geräten, Administrationsportalen, Konfigurationsmanagementsystemen und Code-Repositories. Viele dieser Systeme sind mittlerweile geschäftskritisch. Der Verlust ihrer Historie oder ihrer Basiswerte kann genauso gravierend sein wie der Verlust einer Dateifreigabe.
Gleichzeitig sind die Kunden besser informiert. Sie bringen ihre eigenen Wirtschaftsprüfer, Fragebögen zur Cyberversicherung und interne Standards mit. Wenn sie fragen: „Sichern Sie alles?“, meinen sie selten: „Sichern Sie den Dateiserver?“ Sie meinen vielmehr: „Können Sie unsere Betriebsfähigkeit wiederherstellen und den Hergang eines Fehlers nachweisen?“ Das ist eine wesentlich umfassendere und anspruchsvollere Frage, und genau darüber regt A.8.13 zum Nachdenken an.
Die Umstellung ist nicht nur technischer Natur. Sie verändert auch die Art und Weise, wie Kunden und Wirtschaftsprüfer Sie bewerten. Entscheidungen bezüglich Backups beeinflussen nun Vertragsverlängerungen, Lieferantenrisikobewertungen und Ihre Wettbewerbsfähigkeit im Kampf um größere, stärker regulierte Kunden.
Warum spielen Protokolle und Konfigurationen bei Ausfällen und Untersuchungen eine so große Rolle?
Protokolle und Konfigurationen sind bei Ausfällen und Untersuchungen so wichtig, weil sie nach einem Vorfall zwei Kernfragen beantworten: Was ist passiert und wie gelangt man sicher zurück zum vorherigen Zustand? Ohne sie wird die Wiederherstellung zum Ratespiel und das Vertrauen lässt sich nur schwer wiederherstellen.
Wenn etwas Ernstes passiert – ein Ransomware-Angriff, eine kritische Fehlkonfiguration, ein Cloud-Ausfall – stehen für Ihre Kunden und deren Stakeholder zwei Fragen im Vordergrund:
- Wie schnell können wir wieder zu einem sicheren, funktionierenden Zustand zurückkehren?
- Woher wissen wir, was tatsächlich geschehen ist?
Protokolle sind Ihre wichtigste Quelle zur Beantwortung der zweiten Frage. Sie zeigen, welche Konten verwendet, welche IP-Adressen verbunden, welche Änderungen vorgenommen und welche Systeme manipuliert wurden. Fehlen wichtige Protokolle oder sind sie unvollständig, können Sie möglicherweise nie den Umfang eines Angriffs nachweisen, Ermittler oder die Geschäftsleitung eines Kunden zufriedenstellen oder belegen, dass Sie regulatorische Pflichten erfüllt haben.
Konfigurationen sind für die erste Frage von zentraler Bedeutung. Sie definieren, wie Firewalls den Datenverkehr filtern, wie Identitätssysteme den Zugriff kontrollieren, wie VPNs und SD-WAN-Geräte Daten weiterleiten, wie SaaS-Plattformen Sicherheitsrichtlinien durchsetzen und wie Backup-Aufträge selbst konfiguriert werden. Können diese Ausgangszustände nicht schnell von einem bekannten, funktionierenden Punkt wiederhergestellt werden, wird jede Wiederherstellung zu einem langsamen, manuellen Rekonstruktionsprozess voller Spekulationen und Risiken.
In vielen der schwerwiegendsten Vorfälle waren die Daten – Dateien, Datenbanken – ausreichend wiederherstellbar. Der eigentliche Schaden entstand durch fehlende oder inkonsistente Protokolle und Konfigurationen. Forensische Untersuchungen nach Vorfällen, einschließlich der Analyse von Firewall-Konfigurationsverlusten und SIEM-Protokolllücken, zeigen häufig, dass das Fehlen dieser Artefakte ansonsten beherrschbare Ereignisse in langwierige Krisen mit unklarem Ausmaß und verzögerter Wiederherstellung verwandelte. Für Managed Service Provider (MSPs) bedeutet A.8.13 unter anderem, sicherzustellen, dass dies Ihren Kunden nicht passiert und dass Sie dies im Falle einer Überprüfung nachweisen können.
Protokolle und Konfigurationen, die als erstklassige Sicherungsobjekte behandelt werden, werden daher zu einem Kernbestandteil Ihrer Incident-Response- und Qualitätssicherungsstrategie und nicht nur zu einem technischen Detail im Hintergrund.
KontaktWas genau verlangt ISO 27001 A.8.13 von Managed Service Providern (MSPs) in Bezug auf Protokolle und Konfigurationen?
ISO 27001 A.8.13 verlangt von Ihnen die Definition, den Betrieb und den Nachweis eines Backup-Systems, das Informationen, Software und Systeme gemäß einer vereinbarten Richtlinie abdeckt. Für Managed Service Provider (MSPs) umfasst dies neben herkömmlichen Daten wie Dateifreigaben und Datenbanken auch Client-Protokolle und -Konfigurationen, sofern diese für Wiederherstellung, Überwachung oder Compliance benötigt werden.
Der Bericht „State of Information Security 2025“ zeigt, dass Kunden zunehmend erwarten, dass ihre Lieferanten sich an formale Rahmenwerke wie ISO 27001, ISO 27701, DSGVO, Cyber Essentials und SOC 2 anpassen.
ISO 27001:2022 Anhang A, Abschnitt A.8.13, besagt im Wesentlichen, dass Sicherungskopien von Informationen, Software und Systemen gemäß einer vereinbarten Sicherungsrichtlinie gepflegt und regelmäßig getestet werden müssen, um nach Verlust oder Unterbrechung eine Wiederherstellung zu gewährleisten. MSP-spezifische Interpretationen des Standards, wie beispielsweise Kommentare von Serviceprovidern zu A.8.13, formulieren dies als Anforderung, Sicherungsmaßnahmen zu entwickeln und zu testen, die realistischen Ausfall- und Bedrohungsszenarien standhalten und nicht nur auf dem Papier existieren. Für einen MSP gilt diese Anforderung sowohl für die eigenen Informationen als auch für die Systeme und Daten, die er im Auftrag seiner Kunden verwaltet.
Konkret verlangt A.8.13 von Ihnen, festzulegen, zu dokumentieren und nachzuweisen, was Sie sichern, wie, wie oft, wie lange Sie die Daten aufbewahren, wie Sie sie schützen und wie Sie deren Wiederherstellbarkeit nachweisen. Clientprotokolle und Konfigurationsdaten fallen in diesen Geltungsbereich, sofern sie zur Erfüllung vereinbarter Wiederherstellungsziele, Sicherheitsüberwachungsanforderungen oder gesetzlicher und behördlicher Pflichten erforderlich sind.
Um das zu verdeutlichen, hilft es, die Kontrolle in vier Fragen zu unterteilen:
- Umfang: Welche Informationen, Software und Systeme werden gesichert und warum?
- Bedienung: Wie werden Datensicherungen durchgeführt, geschützt und überwacht?
- Testing: Wie lässt sich überprüfen, ob die Wiederherstellung funktioniert und die Wiederherstellungsziele erfüllt werden?
- Beweis: Wie beweist man Prüfern und Kunden, dass all dies tatsächlich der Fall ist?
Für Managed Service Provider (MSPs) müssen diese Fragen doppelt beantwortet werden: einmal für das eigene interne Informationssicherheitsmanagementsystem (ISMS) und einmal für die Dienstleistungen, die sie ihren Kunden anbieten. Viele der zugrunde liegenden Prozesse und Tools werden zwar geteilt, die Risiken, Pflichten und Erwartungen unterscheiden sich jedoch. Daher benötigen Sie eine MSP-spezifische Auslegung von A.8.13 und können sich nicht auf allgemeine Unternehmensrichtlinien verlassen.
Eine strukturierte ISMS-Plattform wie ISMS.online unterstützt Sie dabei, A.8.13-Richtlinien mit Assets, Risiken und Kontrollen zu verknüpfen. So sind Umfang und Verantwortlichkeiten für Protokolle und Konfigurationen für Ihre gesamte Kundenbasis klar definiert und nachvollziehbar. Wenn Sie diese Erwartungen zentral festlegen und die Nachweise einheitlich verwalten möchten, ist die Zentralisierung in einem solchen System oft die praktischste Lösung.
Wie ist A.8.13 im MSP-Kontext zu interpretieren?
Im MSP-Kontext sollten Sie alle Kundeninformationen, die für die Wiederherstellung, Erkennung oder die Erfüllung rechtlicher Pflichten erforderlich sind, als im Anwendungsbereich von A.8.13 liegend behandeln, die Datensicherung mit verwandten Kontrollen wie Protokollierung und Änderungsmanagement abstimmen und die geteilten Verantwortlichkeiten klar in Richtlinien und Verträgen dokumentieren.
Behandeln Sie zunächst alle Informationen, die Sie für Kunden verwalten und die zur Wiederherstellung von Diensten, zur Erkennung und Untersuchung von Vorfällen oder zur Erfüllung formeller Aufbewahrungspflichten erforderlich sind, als unter A.8.13 fallend. Dies umfasst in der Regel Folgendes:
- Sicherheitsprotokolle von Firewalls, VPNs, Endpunkten, Intrusion-Detection-Tools und SIEM-Plattformen.
- System- und Anwendungsprotokolle mit Beweis- oder Betriebswert für Vorfälle oder Audits.
- Konfigurationsdaten für Netzwerkgeräte, Sicherheitstools, Virtualisierungsplattformen, Identitätssysteme und kritische SaaS-Dienste.
- Vorlagen und Infrastruktur als Code, die Standard-Builds und Baselines definieren.
Zusammengenommen bilden diese Elemente die Grundlage Ihrer Fähigkeit, den Hergang des Geschehens zu beweisen und einen sicheren Wiederaufbau zu gewährleisten.
Zweitens ist zu beachten, dass A.8.13 nicht isoliert betrachtet werden kann. Es ist eng mit Kontrollmechanismen für Protokollierung, Änderungsmanagement, Zugriffskontrolle, Geschäftskontinuität und Lieferantenbeziehungen verknüpft. Zum Beispiel:
- Die Protokollierungskontrollen erfordern, dass Sie wichtige Protokolle aufbewahren; A.8.13 fragt, wie Sie diese nach Ausfällen wiederherstellen.
- Die Änderungsverwaltung verfolgt Konfigurationsänderungen; A.8.13 bewahrt bekannte, funktionierende Versionen auf.
- Die Maßnahmen zur Geschäftskontinuität definieren die Wiederherstellungsziele; A.8.13 ist eine Möglichkeit, diese Ziele zu erreichen.
Diese Abstimmung hilft Ihnen, doppelte Arbeit und widersprüchliche Erwartungen hinsichtlich Standards und Dienstleistungen zu vermeiden.
Drittens ist der Begriff „themenspezifische Backup-Richtlinie“ wichtig. Er bedeutet, dass Sie Backup-Anforderungen nicht in einer allgemeinen Informationssicherheitsrichtlinie verstecken sollten. Sie sollten eine dedizierte Backup-Richtlinie oder einen Standard haben, der Protokolle und Konfigurationen explizit referenziert, Verantwortlichkeiten beschreibt und festlegt, wie Anforderungen abgeleitet und angewendet werden.
Abschließend ist es wichtig, die geteilte Verantwortung klar zu definieren. In manchen Fällen sind Kunden weiterhin für die Datensicherung bestimmter SaaS-Anwendungen oder interner Systeme verantwortlich. In anderen Fällen verwalten Sie zwar die Plattform, die Entscheidungen über Aufbewahrung oder spezifische Protokollquellen liegen jedoch beim Kunden. A.8.13 verpflichtet Sie nicht zur Übernahme aller möglichen Backup-Aufgaben, erwartet aber, dass Sie die Zuständigkeiten explizit festlegen, diese Aufteilung in Verträgen und Richtlinien regeln und das Restrisiko managen. MSP-orientierte Auslegungen von A.8.13, einschließlich der Erläuterungen für Service Provider, betonen diese doppelte Verpflichtung sowohl für Ihr eigenes ISMS als auch für die von Ihnen verwalteten Umgebungen.
Welchen Stellenwert haben Client-Protokolle und -Konfigurationen im Rahmen der Datensicherung?
Clientprotokolle und -konfigurationen fallen in den Sicherungsumfang, wenn deren Verlust die Wiederherstellungsziele gefährden, die Sicherheitsüberwachung beeinträchtigen oder gegen rechtliche und regulatorische Vorgaben verstoßen würde. Dieser Umfang sollte in Ihrer Sicherungsrichtlinie explizit festgelegt und nicht vorausgesetzt oder einzelnen Technikern überlassen werden.
Viele Managed Service Provider (MSPs) haben Protokolle und Konfigurationen in der Vergangenheit getrennt von Backups behandelt:
- Protokolle wurden als etwas betrachtet, das in SIEM-Systemen oder Überwachungstools gespeichert war, nicht als Sicherungsobjekte.
- Es wurde davon ausgegangen, dass die Konfigurationen anhand von Dokumentationen oder Skripten reproduzierbar sind und nicht als primäre Daten behandelt werden, die einer Sicherung bedürfen.
Unter A.8.13 sind diese Annahmen nicht mehr haltbar. Wenn ein Protokollstrom oder eine Konfigurationsgruppe erforderlich ist, um Dienste wiederherzustellen, Vorfälle zu untersuchen, die Einhaltung von Vorschriften nachzuweisen oder vereinbarte RPO/RTO-Ziele zu erreichen, muss dies explizit in Ihrem Backup-System berücksichtigt werden.
Das bedeutet nicht, dass Sie jedes von jedem Gerät erzeugte Protokoll für denselben Zeitraum sichern müssen. Es bedeutet aber, dass Sie Folgendes tun sollten:
- Ermitteln Sie, welche Protokollquellen für Sicherheit, Betrieb und Compliance kritisch sind.
- Entscheiden Sie, welche dieser Daten eine unabhängige Datensicherung über das lokale Gerät oder den primären Protokollspeicher hinaus benötigen.
- Legen Sie Aufbewahrungsfristen auf der Grundlage von Risiko, Vorschriften und Kundenanforderungen fest.
- Beziehen Sie diese Entscheidungen in Ihre Backup-Richtlinien, Anlageninventare und Servicebeschreibungen ein.
Eine klare Zusammenfassung dieser Punkte in Ihren Standards vermeidet Annahmen und Überraschungen im Falle eines Vorfalls oder einer Prüfung.
Dasselbe gilt für Konfigurationen. Bestimmte Gerätetypen – Firewalls, VPN-Gateways, Core-Switches, Identitätssysteme und Backup-Plattformen selbst – sind die Eckpfeiler der Sicherheit und Kontinuität Ihrer Kunden. Ihre Konfigurationen müssen mit der gleichen Sorgfalt gesichert, versioniert, geschützt und regelmäßig testweise wiederhergestellt werden wie jede Datenbank.
ISO 27001 leicht gemacht
Ein Vorsprung von 81 % vom ersten Tag an
Wir haben die harte Arbeit für Sie erledigt und Ihnen vom Moment Ihrer Anmeldung an einen Vorsprung von 81 % verschafft. Sie müssen nur noch die Lücken ausfüllen.
Wie gelingt der Übergang von „Wir erstellen Backups“ zu einem umfassenden Backup-Standard?
Sie gehen von „Wir machen Backups“ zu einem übergeordneten Backup-Standard über, indem Sie eine MSP-weite Basislinie für Umfang, Häufigkeit, Aufbewahrung, Schutz, Tests und Nachweise definieren und diese dann konsequent auf alle Kunden anwenden, wobei kontrollierte Abweichungen für Stufen und Verträge berücksichtigt werden.
Rund zwei Drittel der Organisationen gaben in der ISMS.online-Umfrage 2025 an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Aufrechterhaltung der Compliance erschweren.
Um die Anforderungen von A.8.13 umfassend zu erfüllen und das Geschäftsrisiko zu reduzieren, müssen Sie von kundenspezifischen, unstrukturierten Backup-Praktiken zu einem einheitlichen Master-Backup-Standard für Ihren Managed Service Provider (MSP) übergehen. Dieser Standard legt die Mindestanforderungen für die Sicherung und Prüfung von Informationen, einschließlich Protokollen und Konfigurationen, für alle Kunden fest und definiert die Parameter, die je nach Service-Level oder Vertrag variieren können.
Ein zentraler Backup-Standard ist keine Marketingbroschüre, sondern ein Steuerungsinstrument. Er gibt Ihren Technikern vor, was sie tun müssen, Ihren Vertriebsteams, welche Versprechen sie abgeben dürfen, Ihrer Compliance-Abteilung, welche Nachweise sie erbringen müssen, und Ihren Kunden, was sie erwarten können.
Es sollte mindestens Folgendes umfassen:
- Gültigkeitsbereich und Datenklassen.
- Backup-Frequenz und -Methoden.
- Aufbewahrungsfristen und Vernichtungsregeln.
- Schutzmaßnahmen wie Verschlüsselung, Zugriffskontrolle, Trennung und Unveränderlichkeit.
- Überwachung und Ausnahmebehandlung.
- Wiederherstellungstests, einschließlich Stichproben von Protokollen und Konfigurationen.
- Anforderungen an Dokumentation und Nachweise.
Sobald dieser Standard definiert ist, kann er kundenspezifisch angepasst werden: gleiche Struktur, angepasste Werte. Die Nutzung einer Plattform wie ISMS.online, um diesen Standard als kontrolliertes Dokument zu verwalten und mit Risiken und Kontrollen zu verknüpfen, erleichtert die Synchronisierung von Richtlinien, Implementierung und Nachweisen. Wenn Ingenieure, Auditoren und Vertriebsteams an einem zentralen Ort auf dieselben Backup-Regeln zugreifen sollen, ist diese Art der Zentralisierung oft eine pragmatische Lösung.
Warum ist ein Master-Backup-Standard aus kommerzieller und betrieblicher Sicht wichtig?
Ein einheitlicher Backup-Standard ist wichtig, weil er Schwachstellen reduziert, eine wiederholbare Bereitstellung ermöglicht und Ihnen gegenüber Auditoren und Kunden eine nachvollziehbare Position verschafft. Ohne ihn wird jeder Kunde zu einem Einzelfall, was Risiko und Kosten erhöht.
Ohne einen einheitlichen Standard wird jeder Kunde individuell behandelt. Verschiedene Techniker konfigurieren Backups auf leicht unterschiedliche Weise. Vertriebsmitarbeiter machen Versprechungen basierend auf einzelnen Verträgen. Die Dokumentation beschränkt sich auf Tickets und die bloße Erinnerung daran. Bei einer Prüfung oder einem schwerwiegenden Vorfall stellt sich möglicherweise heraus, dass Backup-Abdeckung, Aufbewahrung und Tests zwischen den Kunden stark variieren – ohne erkennbare Begründung.
Diese Inkonsistenz birgt in mehrfacher Hinsicht Risiken:
- Dadurch erhöht sich die Wahrscheinlichkeit, dass eine wichtige Protokollquelle oder ein wichtiger Konfigurationssatz völlig übersehen wurde.
- Dadurch wird es schwieriger, gegenüber Wirtschaftsprüfern oder Versicherern nachzuweisen, dass man einen überlegten, risikobasierten Ansatz verfolgt.
- Es erhöht den operativen Aufwand, da jede Ausnahme manuell gemerkt und verwaltet werden muss.
- Sie setzen sich dem Vorwurf der unfairen Behandlung aus, wenn ein Mandant ohne dokumentierten Grund einen deutlich stärkeren Schutz erhält als ein anderer.
Ein übergeordneter Standard dient als Referenzpunkt. Er macht Ihren Servicekatalog übersichtlicher: Jeder Managed Service beinhaltet definierte Backup-Anforderungen. Er vereinfacht Vertragsverlängerungen und Quartalsberichte: Sie können Kunden aufzeigen, wie ihre Serviceebene den Backup-Funktionen entspricht. Zudem gibt er Ihrer Führungsebene mehr Sicherheit, dass Sie kein unbewusstes, ungleichmäßiges Risiko über Ihren Kundenstamm hinweg tragen.
Was gehört in einen realistischen MSP-Master-Backup-Standard?
Ein realistischer Master-Backup-Standard definiert für jede Datenklasse, warum Daten gesichert werden, wie die Sicherung erfolgt, wie lange die Daten aufbewahrt werden und wie die Wiederherstellung nachgewiesen wird. Er sollte so klar sein, dass Techniker und Auditoren ihn ohne Rätselraten anwenden können und gleichzeitig einfach zu pflegen sein.
Bei der Erstellung Ihres Standards sollten Sie auf Klarheit und Anwendbarkeit achten. Für jede Datenklasse – Sicherheitsprotokolle, Betriebsprotokolle, Konfigurationen, Systemabbilder, Datenbanken – sollten Sie Folgendes detailliert beschreiben:
- Ziel: Der Zweck der Sicherung dieser Datenklasse.
- Umfang: Typische Quellen, die standardmäßig einbezogen werden, und solche, bei denen eine ausdrückliche Zustimmung erforderlich ist.
- Frequenz: Wie häufig Backups oder Exporte durchgeführt werden, in einfachen Worten ausgedrückt.
- Aufbewahrung: Mindest- und Höchstzeiträume, gegebenenfalls in Verbindung mit Gesetzen oder Verträgen.
- Schutz: Verschlüsselung, Zugriffskontrolle, Segmentierung und alle Anforderungen an die Unveränderlichkeit.
- Testing: Wie häufig Wiederherstellungen getestet werden und woran man erkennt, wie erfolgreich sie sind.
- Beweis: Erwartete Artefakte bei einem Audit, wie z. B. Richtlinien, Stellenbeschreibungen und Beispielberichte.
Die Integration dieses Standards in ein ISMS wie ISMS.online erleichtert die Einhaltung der Vorgaben bei Unternehmenswachstum. Er lässt sich direkt mit Anhang A.8.13, zugehörigen Kontrollen und spezifischen Kundenservices verknüpfen, sodass Vertrieb, Lieferung und Qualitätssicherung auf derselben Basis erfolgen.
Ein gut strukturierter Standard dient auch als interne Checkliste für die Einführung neuer Dienste und Plattformen, wodurch es viel schwieriger wird, kritische Protokollquellen oder Konfigurationen zu übersehen.
Wie lässt sich RPO/RTO für Protokolle, Konfigurationen und Systeme realisieren?
RPO und RTO werden realisierbar, indem man Daten klassifiziert, eine kleine Anzahl realistischer Stufen definiert und testet, ob die Backup- und Wiederherstellungsprozesse diese Ziele für Protokolle, Konfigurationen und Systeme clientübergreifend tatsächlich erreichen.
Recovery Point Objective (RPO) und Recovery Time Objective (RTO) bilden das Fundament jeder ernstzunehmenden Backup-Strategie. Für Managed Service Provider (MSPs) besteht die Herausforderung darin, diese Konzepte von der Richtliniensprache in konkrete, testbare Verhaltensweisen für verschiedene Arten von Kundendaten – insbesondere Protokolle und Konfigurationen – zu übersetzen.
RPO (Recovery Point Objective) beschreibt, wie viele Daten Sie maximal verlieren können, ausgedrückt in Zeiteinheiten. RTO (Recovery Time Objective) beschreibt, wie lange Sie maximal ohne System auskommen können. Für viele Kunden variieren diese Werte je nach Anwendung, Umgebung und Datensatz. Ihre Aufgabe besteht darin, eine kleine Anzahl von Backup-Ebenen zu entwerfen, die diese unterschiedlichen Anforderungen realistisch erfüllen können, ohne an Komplexität zu scheitern.
Bei Protokollen und Konfigurationen bedeutet dies oft, dass man akzeptieren muss, nicht jede Quelle gleich zu behandeln. Manche Protokolle sind sicherheitskritisch und müssen nahezu in Echtzeit erfasst und lange aufbewahrt werden. Andere sind zwar nützlich, aber nicht unbedingt notwendig. Manche Konfigurationen ändern sich häufig und haben große Auswirkungen; andere sind relativ statisch. Ihre RPO- und RTO-Stufen sollten diese Unterschiede widerspiegeln, und Ihre Backup-Strategien sollten darauf abgestimmt sein.
Klare Zielvorgaben für Ausfall- und Wiederherstellungszeiten verhindern, dass RPO und RTO nur vage Versprechen auf dem Papier bleiben, sondern machen sie zu konkreten Zielen, an denen man arbeiten und die man testen kann.
Warum sollten Sie Daten klassifizieren, bevor Sie RPO und RTO festlegen?
Sie sollten Daten klassifizieren, bevor Sie RPO und RTO festlegen, denn die Klassifizierung ermöglicht es Ihnen, einige sinnvolle Ziele systemübergreifend anzuwenden, anstatt in Ausnahmen pro Quelle und unrealistischen Versprechen zu ertrinken.
Wenn Sie versuchen, RPO- und RTO-Werte direkt für jedes einzelne Quellsystem festzulegen, werden Sie in der Vielzahl der Möglichkeiten untergehen. Klassifizieren Sie die Daten stattdessen in einige wenige, geschäftsrelevante Klassen. Zum Beispiel:
- Klasse A: Kritische Sicherheits- und Compliance-Nachweise.
- Klasse B: Betriebsprotokolle und Konfigurationen, die für die Kontinuität erforderlich sind.
- Klasse C: Protokolle und Konfigurationen mit geringeren Auswirkungen, bei denen eine Reproduktion möglich ist oder die Auswirkungen begrenzt sind.
Sobald Sie Datenklassen definiert haben, können Sie jeder Klasse Standardwerte für RPO, RTO und Aufbewahrungsfristen zuweisen. Diese Ziele sollten auf den Anwendungsfällen Ihrer Kunden, regulatorischen Vorgaben und Ihren technischen Möglichkeiten basieren und nicht auf bloßen Annahmen. Bei triftigen Gründen können Sie die Vorgaben dann kundenspezifisch über einen formalisierten Ausnahmemechanismus anpassen.
Eine einfache Möglichkeit, dies zu veranschaulichen, besteht darin, eine Tabelle mit Klassen und Zielen zu erstellen:
| Datenklasse | Typische RPO/RTO-Ebene | Beispieltreiber |
|---|---|---|
| Klasse A | RPO ≤ 15 Minuten, RTO ≤ 4 Stunden | Sicherheitsuntersuchungen, Compliance-Protokolle |
| Class B | RPO ≤ 4 Stunden, RTO ≤ 24 Stunden | Kontinuität des Kernbetriebs |
| Klasse C | RPO ≤ 24 Stunden, RTO ≤ 72 Stunden | Fehlerbehebung, weniger ressourcenintensive Arbeitslasten |
Dieses Modell lässt sich in Kundengesprächen und internen Design-Sitzungen einsetzen. Es gibt den Ingenieuren ein klares Ziel für jede Klasse vor und bietet den Prüfern eine verständliche Grundlage für ihre Tests.
Wie stellt man sicher, dass RPO/RTO-Ziele realistisch und erreichbar bleiben?
Sie halten die RPO- und RTO-Ziele realistisch, indem Sie die Kapazität modellieren, den Vertrieb mit der Entwicklung abstimmen, die tatsächliche Leistung messen und realistische Wiederherstellungstests einbeziehen, die Protokolle und Konfigurationen abdecken und nicht nur einfache Arbeitslasten.
RPO- und RTO-Zahlen lassen sich leicht eingeben, aber schwer einhalten. Um überzogene Versprechungen zu vermeiden:
- Modellkapazität und Leistung: Schätzen Sie Datenvolumen pro Klasse, Clientanzahl, Backup-Fenster, Bandbreite und Speicherverhalten im Zuge Ihres Wachstums.
- Vertrieb und Entwicklung aufeinander abstimmen. Bieten Sie standardmäßig nur genehmigte RPO- und RTO-Bänder an und leiten Sie strengere Anfragen zur Überprüfung und Genehmigung weiter.
- Messen Sie die tatsächliche Leistung. Verfolgen Sie die erreichten RPO-Werte (Alter der letzten gültigen Kopie) und RTO-Werte (Zeit bis zur Wiederherstellung) pro Ebene und Kunde und beheben Sie Engpässe.
- Der Test stellt die Realität realistisch wieder her. Beziehen Sie Protokolle und Konfigurationen aus kritischen Umgebungen in Ihre Wiederherstellungsübungen ein und erfassen Sie die Gesamtzeiten.
Beispielsweise könnten Sie für Sicherheitsprotokolle der Klasse A und Firewall-Konfigurationen ein RPO von 15 Minuten und ein RTO von 4 Stunden definieren. Anschließend würden Sie die Protokollerfassung, Archivierungsaufträge und Konfigurationsexporte so konzipieren, dass diese Werte erreicht werden, und regelmäßig Tests durchführen, bei denen Sie eine Firewall-Konfiguration auf einem Testgerät wiederherstellen und die Protokolle eines Tages in ein Test-SIEM-System einspielen, um die Realisierbarkeit der Ziele zu bestätigen.
Erklären Sie Kunden RPO und RTO anhand von Szenarien statt nur anhand von Zahlen. Zum Beispiel: „Wenn diese Firewall um 10:00 Uhr falsch konfiguriert ist, ist unser Ziel, ihre Konfiguration aus einer maximal 15 Minuten alten, funktionierenden Kopie wiederherzustellen und sie bis 11:00 Uhr wieder betriebsbereit zu haben.“ Dadurch werden Verantwortlichkeiten und Abwägungen deutlich transparenter.
Sobald Sie über glaubwürdige RPO- und RTO-Bereiche verfügen, besteht der nächste Schritt darin, Backup-Architekturen zu entwerfen, die diese Werte konsistent über viele Mandanten hinweg liefern können, und nicht nur in einem einzelnen Laborszenario.
Befreien Sie sich von einem Berg an Tabellenkalkulationen
Integrieren, erweitern und skalieren Sie Ihre Compliance, ohne dass es zu Problemen kommt. IO gibt Ihnen die Widerstandsfähigkeit und das Vertrauen, um sicher zu wachsen.
Wie lassen sich mandantenfähige Backup-Architekturen für Protokolle und Konfigurationen entwerfen?
Sie entwerfen mandantenfähige Backup-Architekturen, indem Sie entscheiden, wo zentralisiert oder isoliert werden soll, wie Kundendaten getrennt werden, wie Konfigurationen erfasst werden und wie die Integrität der Protokollnachweise über alle Mandanten hinweg erhalten werden kann, indem Muster verwendet werden, die Sicherheit und Effizienz in Einklang bringen.
Als Managed Service Provider (MSP) betreiben Sie selten eine einzige, übersichtliche Umgebung für ein einzelnes Unternehmen. Sie verwalten eine Multi-Tenant-Landschaft: viele Kunden, viele Plattformen, viele Tools. A.8.13 beschreibt nicht, wie Backups in diesem Kontext zu gestalten sind, erwartet aber, dass Sie zuverlässige, sichere und testbare Backups für alle relevanten Mandanten bereitstellen und nachweisen.
Die zentralen architektonischen Fragen lauten:
- Wie trennen Sie Kundendaten, um eine Offenlegung zwischen Mandanten oder ein versehentliches Löschen zu vermeiden?
- Wo zentralisiert man aus Effizienzgründen und wo isoliert man aus Sicherheitsgründen?
- Wie erfasst, schützt und versioniert man Konfigurationsdaten?
- Wie stellt man sicher, dass Protokollsicherungen ihre Integrität und ihren Beweiswert behalten?
- Wie lässt sich der Gesundheitszustand und die Einsatzbereitschaft im gesamten Umfeld überwachen?
Sie müssen Ihre Tools nicht komplett überarbeiten, um diese Fragen zu beantworten, aber Sie benötigen ein durchdachtes Design, das gegenüber Prüfern und Kunden erklärt und verteidigt werden kann.
Welche Muster unterstützen eine sichere Trennung und einen effizienten Betrieb?
Sichere und effiziente Mandantenarchitekturen nutzen die mandantenspezifische Trennung von Daten und Schlüsseln zusätzlich zu gemeinsam genutzten Tools und Pipelines, sodass Sie Sicherheit und überschaubare Komplexität im täglichen Betrieb in Einklang bringen können.
Die meisten Organisationen, die an der ISMS.online-Umfrage 2025 teilnahmen, berichteten, im vergangenen Jahr von mindestens einem Sicherheitsvorfall bei einem Drittanbieter oder Lieferanten betroffen gewesen zu sein.
Trennung und Effizienz stehen tendenziell im Widerspruch zueinander. Starke Trennung führt zu mandantenspezifischen Instanzen und strikter Trennung von Speicher, Schlüsseln und Administratorrollen. Effizienz hingegen tendiert zu gemeinsam genutzter Infrastruktur, zentralisierten Pipelines und einheitlichen Tools. Die meisten Managed Service Provider (MSPs) entscheiden sich für einen hybriden Ansatz.
- Verwenden Sie mandantenspezifische Verschlüsselungsschlüssel und logisch getrennte Speicherorte, damit die Kompromittierung eines Clients die Backups eines anderen Clients nicht ohne Weiteres beeinträchtigen kann.
- Die Protokollerfassung sollte zentralisiert werden, wo dies sinnvoll ist. Archivierte Kopien sollten jedoch so gekennzeichnet und gespeichert werden, dass die Mandantengrenzen klar bleiben.
- Trennen Sie die Aufbewahrung von Betriebsprotokollen von der Aufbewahrung von Sicherheitsprotokollen, wenn Sie eine strengere Kontrolle über die Beweismittel benötigen.
- Minimieren und überprüfen Sie Konten mit hohen Berechtigungen, die Sicherungsaufträge verändern oder Archive löschen können.
Unabhängig davon, welche Muster Sie wählen, dokumentieren Sie diese in Architekturskizzen, Bedrohungsmodellen und Betriebshandbüchern. Diese Dokumentation ist Teil Ihrer Nachweise gemäß A.8.13 und untermauert Ihre Zusicherungen zur Datensicherung gegenüber Ihren Kunden.
Wie sollte man die Sicherung von Konfigurationen in einer vielfältigen, Cloud-lastigen Welt handhaben?
Sie sollten die Sicherung von Konfigurationen so handhaben, dass Sie Konfigurationen als primäre Sicherungsobjekte behandeln, Exporte automatisieren, sie sicher speichern und in Wiederherstellungstests einbeziehen, anstatt davon auszugehen, dass sie immer anhand von Skripten oder Dokumentationen wiederhergestellt werden können.
Die Sicherung der Konfiguration ist oft das schwächste Glied in der MSP-Wiederherstellung. Man geht leichtfertig davon aus, dass Cloud-Plattformen und verwaltete Geräte ihre eigenen Richtlinien speichern oder dass Skripte und Infrastructure-as-Code-Repositories als Dokumentation „ausreichend“ sind. In der Praxis sollten Sie Folgendes beachten:
- Automatisieren Sie regelmäßige Exporte oder Snapshots von Konfigurationen für kritische Systeme und Plattformen.
- Konfigurationsexporte sollten in einem versionskontrollierten, zugriffskontrollierten und idealerweise unveränderlichen Speicher abgelegt werden.
- Verknüpfen Sie Konfigurationsversionen mit Änderungsmanagement-Datensätzen, um Rückverfolgbarkeit und Rollback zu gewährleisten.
- Beziehen Sie neben der vollständigen Systemwiederherstellung auch die Wiederherstellung von Konfigurationen in Ihr Testprogramm ein.
Behandeln Sie Konfigurationsartefakte wie erstklassige Backup-Objekte mit Datenklassifizierung, RPO und RTO sowie Aufbewahrungsregeln wie bei jeder anderen Klasse. Dadurch können Sie bei komplexen Vorfällen über die manuelle Wiederherstellung hinausgehen und stattdessen sagen: „Wir können es auf diesen bekannten, funktionierenden Zustand von diesem Zeitpunkt zurücksetzen, und hier ist der Nachweis.“
Mit zunehmender Größe Ihrer Cloud-Infrastruktur schützt Sie diese Vorgehensweise auch vor versehentlichen Änderungen in den Konsolen der Anbieter und stellt sicher, dass Wissen nicht nur in den Köpfen einzelner Ingenieure verbleibt.
Wie lässt sich nachweisen, dass Backups funktionieren und wie erstellt man revisionssichere Protokolle?
Sie beweisen die Funktionsfähigkeit von Backups durch die Kombination von klaren Richtlinien, vollständigem Umfang, überwachten Vorgängen, aussagekräftigen Wiederherstellungstests und gut organisierten Nachweisen, damit Prüfer und Kunden sehen können, dass A.8.13 in der Praxis funktioniert und nicht nur auf dem Papier.
Nur etwa jede fünfte Organisation gab im Bericht „State of Information Security 2025“ an, im vergangenen Jahr einen Datenverlust vollständig vermieden zu haben.
Aus der Sicht eines Auditors geht es bei einer effektiven Datensicherung nicht nur darum, die entsprechenden Tools konfiguriert zu haben. Es geht darum, nachweisen zu können, dass:
- Ihre Richtlinien und Standards existieren und werden angewendet.
- Die richtigen Systeme und Daten sind relevant.
- Die Backups werden tatsächlich ausgeführt, überwacht und bei Fehlern repariert.
- Die Wiederherstellungen werden getestet, und die Tests erfüllen die festgelegten Erfolgskriterien.
- Die Beweislage ist vollständig, präzise und nachvollziehbar.
Für Managed Service Provider (MSPs) müssen diese Nachweise für verschiedene Audits, Kundengespräche und interne Prüfungen wiederverwendbar sein. Werden sie jedes Mal von Grund auf neu erstellt, führt dies zu Zeitaufwand und Inkonsistenzen. Ein strukturiertes Nachweispaket für A.8.13 hilft, dies zu vermeiden und zukünftige Prüfungen zu vereinfachen.
Was sollte ein A.8.13-Beweispaket für Protokolle, Konfigurationen und Systeme enthalten?
Ein A.8.13-Nachweispaket sollte die wichtigsten Dokumente und Aufzeichnungen enthalten, aus denen hervorgeht, was im Geltungsbereich liegt, wie Backups durchgeführt werden, wie Probleme behandelt werden und wie Wiederherstellungen getestet werden, wobei Protokolle und Konfigurationen dort explizit aufgeführt werden, wo sie am wichtigsten sind.
Ein praktisches Beweismaterialpaket enthält in der Regel Folgendes:
- Richtlinien und Standards: Ihre Master-Backup-Richtlinie und alle unterstützenden Standards, die explizit auf Protokolle und Konfigurationen verweisen.
- Anlageninventare: Listen von Systemen, Protokollquellen und Konfigurationsspeicherorten im Sicherungsbereich mit Datenklassen und zugewiesenen RPO-, RTO- und Aufbewahrungsstufen.
- Backup-Auftragsdefinitionen: Screenshots oder Exporte, die zeigen, wie Jobs für repräsentative Kunden konfiguriert sind – was enthalten ist, wo es hingehört und wie oft es ausgeführt wird.
- Überwachung und Berichterstattung: Beispiele für Backup-Berichte und Dashboards für ausgewählte Zeiträume, die Erfolgsquoten, Fehler und die Behandlung von Ausnahmen aufzeigen.
- Testdatensätze wiederherstellen: Protokolle und Berichte über Wiederherstellungsübungen, einschließlich der Information, welche Elemente wiederhergestellt wurden, wie lange dies dauerte und ob die Ziele erreicht wurden.
- Änderungsdatensätze: Nachweise dafür, dass Änderungen des Geltungsbereichs Backup-Aktualisierungen auslösen oder dass Ausnahmen erfasst und genehmigt werden.
Um dies zu verdeutlichen, stellen Sie sich einen typischen Kunden vor. Ihr Nachweispaket könnte den relevanten Abschnitt der Backup-Richtlinie, die Anlagenliste für die Firewalls und das SIEM-System dieses Kunden, die Auftragskonfiguration für den Export und die Archivierung dieser Protokolle und Konfigurationen, einen monatlichen Backup-Bericht mit Hervorhebung etwaiger Fehler und deren Behebung sowie ein aktuelles Wiederherstellungstestprotokoll enthalten, in dem eine Firewall-Konfiguration und die Protokolle eines Tages in einer Laborumgebung wiederhergestellt und validiert wurden.
Wenn Sie ISMS.online verwenden, können Sie diese Artefakte mit A.8.13 und den zugehörigen Kontrollen verknüpfen, sodass Sie alles schnell wiederfinden, wenn ein Prüfer oder ein anspruchsvoller Kunde einen Nachweis verlangt, anstatt die Geschichte jedes Mal von Grund auf neu aufzubauen.
Wie kann man Wiederherstellungstests sinnvoll gestalten, ohne die Ingenieure zu überlasten?
Sie gestalten Wiederherstellungstests sinnvoll, indem Sie sinnvolle Stichproben nehmen, einschließlich Protokollen und Konfigurationen, wo immer möglich automatisieren und die Ergebnisse in die Konstruktion einfließen lassen, sodass die Tests Ihr System stärken, anstatt zu einer bloßen Pflichterfüllung zu werden.
Die Wiederherstellungsprüfung ist der Punkt, an dem viele Backup-Systeme Schwächen aufweisen. Es ist einfacher nachzuweisen, dass die Backups ausgeführt wurden, als zu beweisen, dass die Wiederherstellung wie erwartet funktioniert. Um die Prüfung effektiv und nachhaltig zu gestalten:
- Legen Sie den Umfang Ihres Programms fest. Sie müssen nicht jeden Kunden und jedes System jeden Monat testen; wechseln Sie zwischen Klassen und Stufen.
- Fügen Sie Protokolle und Konfigurationen hinzu. Beschränken Sie die Tests nicht auf Serverabbilder oder Dateifreigaben; erfassen Sie alle relevanten Beweismittel.
- Automatisieren und gut protokollieren. Nutzen Sie Skripte und Orchestrierung, um temporäre Umgebungen zu erstellen und Zeitabläufe zu erfassen.
- Ergebnisse zurückgeben: Nutzen Sie die Testergebnisse, um die Architektur zu verbessern und die RPO- und RTO-Angaben gegebenenfalls anzupassen.
Beispielsweise könnten Sie einen vierteljährlichen Test durchführen, bei dem Sie die Firewall-Konfiguration eines wichtigen Kunden und die Sicherheitsprotokolle der letzten 24 Stunden in einer Testumgebung wiederherstellen, die Konfiguration mit Ihrer Baseline vergleichen und bestätigen, dass die Protokolle es einem Analysten ermöglichen, ein vordefiniertes Szenario zu rekonstruieren. Die Ergebnisse dieses Tests stärken sowohl Ihr Vertrauen in den Betrieb als auch Ihre Auditbereitschaft.
Mit der Zeit wird ein diszipliniertes, aber realistisches Testprogramm zu einer Ihrer stärksten Garantien gegenüber Kunden, Versicherern und Aufsichtsbehörden.
Verwalten Sie Ihre gesamte Compliance an einem Ort
ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.
Wie kann man eine Backup-Zusicherung ohne unbegrenzte Haftung anbieten?
Sie bieten zusätzliche Sicherheit, indem Sie den Umfang der Absicherung, die Schutz- und Testverfahren sowie die verbleibenden Restrisiken definieren, anstatt zu versprechen, jeden Schadenfall zu verhindern. Dieser Ansatz gibt Ihren Kunden Vertrauen, ohne dass Sie eine unbegrenzte Haftung übernehmen, die Sie nicht wirklich kontrollieren können.
Kunden fordern zunehmend „Backup-Zusicherungen“: die Gewissheit, dass ihre Daten, Protokolle und Konfigurationen innerhalb vereinbarter Grenzen wiederherstellbar sind, untermauert durch konkrete Nachweise. Leitfäden für Kunden zur Bewertung von MSP-Zusagen, wie beispielsweise Evaluierungsleitfäden für Backup-Zusicherungen, tragen diesem Trend Rechnung, indem sie Käufer dazu anhalten, auf dokumentierte Standards, Testprotokolle und klare RPO/RTO-Verpflichtungen statt auf vage Zusicherungen zu achten. Gleichzeitig ist es nicht vertretbar, eine uneingeschränkte Haftung für jedes mögliche Szenario oder jede Datenlücke zu übernehmen. Die Kunst besteht darin, Zusicherungen anhand von Design, Prozess und Nachweis zu definieren, anstatt absolute Garantien zu geben.
Eine sinnvolle Definition von Datensicherungssicherheit bedeutet, dass Sie Fragen wie die folgenden beantworten können:
- Was umfasst die Datensicherung für diesen Dienst und diesen Kunden, und warum?
- Welche RPO-, RTO- und Retention-Ziele gelten?
- Wie werden Backups konzipiert, geschützt und überwacht?
- Wie oft haben Sie Wiederherstellungen für vergleichbare Systeme getestet, und mit welchen Ergebnissen?
- Welche Restrisiken bleiben bestehen und wem gehören sie?
Es kann nicht ehrlich bedeuten: „Wir versprechen, niemals Protokolle oder Konfigurationen zu verlieren“, denn das wäre weder realistisch noch versicherungsfähig. Stattdessen positionieren Sie sich als Anbieter mit einem soliden, evidenzbasierten System und klaren Grenzen.
Wie formuliert man die Zusicherung von Datensicherungen in Kundengesprächen?
Sie gestalten die Backup-Zusicherung, indem Sie Kunden Ihre Standards, Datenklassen und Verantwortlichkeiten in praktischen Begriffen erläutern und dabei realistische Szenarien anstelle vager Garantien oder unbegrenzter Verpflichtungen verwenden.
Beginnen Sie damit, Ihren Master-Backup-Standard zu erläutern und dessen Anwendung auf den jeweiligen Kunden zu erklären. Zeigen Sie ihm, wie seine Dienste in Ihre Datenklassen und Backup-Ebenen passen, was dies in der Praxis bedeutet (zum Beispiel: „Kritische Firewall-Protokolle: Zentralisierung nahezu in Echtzeit, Aufbewahrung für mindestens neunzig Tage; Firewall-Konfigurationen: tägliche Exporte und monatliche Wiederherstellungstests“) und wo etwaige Abweichungen bestehen.
Machen Sie die gemeinsamen Verantwortlichkeiten deutlich. Zum Beispiel:
- Sie können zwar Kerninfrastrukturprotokolle und -konfigurationen sichern, aber der Kunde ist für den Export und die Sicherung bestimmter Anwendungsprotokolle aus SaaS-Systemen verantwortlich.
- Sie können die Aufbewahrung für bestimmte Log-Streams verwalten, aber der Kunde wählt die Aufbewahrungsdauer anhand seiner internen Anforderungen und akzeptiert die damit verbundenen Speicher- und Leistungskosten.
Verwenden Sie nach Möglichkeit reale, anonymisierte Beispiele. Schildern Sie beispielsweise einen hypothetischen Vorfall, bei dem ein kompromittiertes Konto Firewall-Regeln geändert und anschließend Daten exfiltriert hat. Erläutern Sie, welche Protokolle und Konfigurationen Ihr Backup-System sichern würde, wie schnell diese wiederhergestellt werden könnten und welche Möglichkeiten dies dem gemeinsamen Einsatzteam eröffnen würde.
Am wichtigsten ist es, vage Zusicherungen zu vermeiden. Statt „Wir sichern immer alles“ sagen Sie lieber: „Für diesen Dienst verpflichten wir uns, die folgenden Daten nach diesem Zeitplan und mit diesen Aufbewahrungsfristen zu sichern, sie auf diese Weise zu überwachen und in diesem Rhythmus zu testen.“ Das ist ehrlicher und überzeugender.
Wenn Sie möchten, dass diese Verpflichtungen und Szenarien durch einheitliche Richtlinien und Nachweise für Ihren gesamten Kundenstamm untermauert werden, kann Ihnen eine ISMS-Plattform wie ISMS.online die benötigte Struktur bieten.
Wie lassen sich Zusicherungen in Verträge und SLAs umsetzen?
Sie übersetzen Zusicherungen in Verträge, indem Sie Umfang, RPO, RTO und Verantwortlichkeiten präzise beschreiben, diese mit Ihrem Backup-Standard und Ihrer Architektur in Einklang bringen und Maßnahmen ergreifen, die widerspiegeln, was Sie glaubwürdig liefern und nachweisen können.
Ihre Geschäftsdokumente müssen die technischen Gegebenheiten widerspiegeln. Vage Formulierungen wie „branchenübliche Datensicherungen“ oder „nach besten Kräften“ bieten weder Ihnen noch Ihren Kunden ausreichenden Schutz. Stattdessen:
- Den Umfang genau beschreiben. Nennen Sie die Systeme, Umgebungen, Protokollquellen und Konfigurationstypen, die einbezogen werden. Machen Sie deutlich, was ausgeschlossen ist oder explizit einbezogen werden muss.
- Siehe RPO, RTO und Aufbewahrung. Verwenden Sie die Werte Ihrer Backup-Ebenen und verknüpfen Sie diese mit den erworbenen Diensten.
- Verantwortlichkeiten definieren. Legen Sie genau fest, wer die Datensicherung konfiguriert, überwacht und wartet; wer über Änderungen informieren muss; und wer über die Aufbewahrungsrichtlinien entscheidet.
- Realistische Lösungsansätze festlegen. Vermeiden Sie unbestimmte Haftungsklauseln für Folgeschäden im Zusammenhang mit Backup-Ausfällen. Konzentrieren Sie sich stattdessen auf Gutschriften, erneute Leistungserbringung und die Zusammenarbeit bei der Reaktion auf Vorfälle.
- An den Richtlinien ausrichten. Stellen Sie sicher, dass Ihre Verträge nicht mehr versprechen, als Ihre Backup-Richtlinie und -Architektur leisten können.
Dadurch bringen Sie die Erwartungen gemäß A.8.13 in Einklang mit rechtsverbindlichen Verpflichtungen. Zudem erleichtern Sie es Ihnen, Ihre Position nach einem Vorfall zu verteidigen: Sie können auf den vereinbarten Geltungsbereich verweisen, Nachweise für dessen Einhaltung erbringen und verbleibende Risiken transparent diskutieren.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online unterstützt Sie dabei, von Annahmen über Datensicherungen zu einem evidenzbasierten, auditierbaren und wirtschaftlich vertretbaren Datensicherungsmodell zu gelangen, das ISO 27001 A.8.13 und den zugehörigen Kontrollen entspricht. Indem Sie ein einziges ISMS verwenden, um Ihren Datensicherungsstandard zu definieren, ihn Diensten zuzuordnen und Ihre Nachweise zu speichern, erleichtern Sie es Kunden und Auditoren erheblich, zu zeigen, dass Ihr System durchdacht, getestet und kontrolliert ist.
Im Bericht „State of Information Security 2025“ nannten fast alle Organisationen das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 als eine ihrer obersten Prioritäten.
Innerhalb derselben Umgebung können Sie Ihren Master-Backup-Standard verwalten, ihn direkt mit Anhang A.8.13 und den zugehörigen Kontrollen verknüpfen und diesen Standard bestimmten Diensten und Kunden zuordnen. Dadurch erhalten Ihre IT-Sicherheits- und Compliance-Teams einen klaren Überblick darüber, wie die Backup-Anforderungen an Protokolle, Konfigurationen und Systeme in der Praxis umgesetzt werden. Gleichzeitig erhalten Auditoren und anspruchsvolle Kunden eine strukturierte Möglichkeit, Ihre Sicherheitslage zu überprüfen.
Für technische Teams beseitigt die Zentralisierung von Testplänen und Wiederherstellungsergebnissen viele Reibungsverluste. Ingenieure müssen nicht mehr in verschiedenen Tools suchen, um nachzuweisen, dass eine bestimmte Konfiguration innerhalb eines vorgegebenen Zeitraums gesichert und erfolgreich wiederhergestellt wurde. Sie können an einem zentralen Ort einsehen, welche Tests durchgeführt wurden, welche erfolgreich waren, welche fehlgeschlagen sind und welche Folgemaßnahmen ergriffen wurden. Dies unterstützt sowohl interne Qualitätssicherungsmaßnahmen als auch externe Untersuchungen.
Sie können außerdem personalisierte Berichte oder kontrollierte Ansichten für wichtige Kunden erstellen. Anstatt Screenshots per E-Mail zu versenden oder individuelle Präsentationen zusammenzustellen, können Sie eine konsistente Darstellung Ihrer Datensicherung präsentieren, die auf Live-Daten aus Ihrem Managementsystem basiert. So können Sie schwierige Fragen souverän beantworten, ohne sensible Details über andere Kunden oder interne Abläufe preiszugeben.
Schließlich ermöglichen Workflow- und Aufgabenmanagementfunktionen die Zuweisung, Nachverfolgung und Dokumentation von Backup-bezogenen Aktionen – wie etwa die Prüfung von Ausnahmen, die Aktualisierung von Aufbewahrungsregeln oder die Planung von Wiederherstellungstests. Dadurch wird der Kreislauf zwischen Richtlinie, Implementierung und Nachweis geschlossen und gezeigt, dass Ihr Backup-System ein dynamisches Kontrollinstrument und nicht nur ein Dokument ist.
Wenn Sie sehen möchten, wie eine strukturierte Plattform Ihren eigenen Ansatz für Kundenprotokolle, Konfigurationen und Systeme unterstützen kann, ist die Erkundung einer Demo von ISMS.online ein sinnvoller nächster Schritt. Sie ermöglicht es Ihnen, Ihre aktuelle A.8.13-Abdeckung mit einem durchdachteren, testbaren Modell zu vergleichen und zu entscheiden, ob ein zentralisiertes ISMS Ihnen helfen würde, eine stärkere und transparentere Datensicherung für Ihre Kunden und Ihr eigenes Unternehmen zu gewährleisten.
Häufig gestellte Fragen (FAQ)
Wo genau zieht ISO 27001 A.8.13 die Grenze für MSP-Backups von Protokollen und Konfigurationen?
ISO 27001 A.8.13 verlangt, dass Sie Kundenprotokolle und -konfigurationen als erstklassige Informationswerte behandeln und ein sorgfältig konzipiertes, dokumentiertes und getestetes Backup-System implementieren. Dieses System muss den Prüfern genau aufzeigen, was, wie oft, wo und wie gesichert wird und wie die Wiederherstellung funktioniert.
Wie sollte ein Managed Service Provider (MSP) „Datensicherung“ für den täglichen Betrieb von Managed Services definieren?
Für einen Managed Service Provider beschränkt sich die „Datensicherung“ nicht auf virtuelle Maschinen oder Dateisysteme. Sie umfasst alle Daten und Einstellungen, auf die Sie sich verlassen würden, um:
- Wiederherstellung des Kundendienstes nach einem Ausfall
- Untersuchen Sie einen vermuteten Sicherheitsvorfall
- Legen Sie Ihre Handlungen einer Aufsichtsbehörde oder einem Gericht vor.
- Weisen Sie nach, dass Sie Ihre vertraglichen Verpflichtungen erfüllt haben.
Dies bringt üblicherweise Folgendes mit sich:
- Sicherheitsprotokolle von Firewalls, VPNs, EDR/AV-, IDS/IPS- und SIEM-Plattformen
- Wichtige Anwendungs- und Plattformprotokolle, die für die Fehlerbehebung oder forensische Analyse benötigt werden.
- Konfigurationsdaten für Switches, Router, Firewalls und andere Netzwerkgeräte
- Verzeichnis- und Identitätsplattformen wie Active Directory und Entra ID / Azure AD
- Konfigurationsexporte auf Mandantenebene für wichtige SaaS- und Cloud-Dienste
Für jeden dieser Punkte wird ein Wirtschaftsprüfer erwarten, dass Sie Folgendes vorweisen können:
- Es wurde entschieden und dokumentiert, welche Protokolle und Konfigurationssätze für die Wiederherstellung und Verantwortlichkeit relevant sind.
- Definierte Sicherungs- oder Weiterleitungsmethoden (z. B. SIEM-Pipelines, Snapshots, API-Exporte)
- Festlegung von Aufbewahrungsfristen, Lagerorten und Zuständigkeiten für diese Entscheidungen
- Angemessene technische Kontrollmaßnahmen wurden angewendet (Verschlüsselung, Zugriffskontrolle, Trennung, manchmal Unveränderlichkeit).
- Geplante und protokollierte regelmäßige Wiederherstellungstests, die Protokolle und Konfigurationen umfassen, nicht nur Server.
Sie benötigen keine unterschiedliche Philosophie für jeden Kunden. Ein einheitlicher Backup-Standard in Ihrem ISMS, der Protokolle und Konfigurationen explizit als relevante Assets gemäß A.8.13 ausweist und anschließend auf kundenspezifische Bereiche, Aufträge und Wiederherstellungsnachweise verweist, genügt in der Regel, um Auditoren zufriedenzustellen und größeren Kunden Sicherheit zu geben. ISMS.online unterstützt Sie dabei, indem es Ihnen eine zentrale Plattform bietet, um diesen Standard zu verwalten, A.8.13 Ihrem Kontrollset zuzuordnen und die Inventare, Backup-Aufträge und Testprotokolle jedes Kunden zu verknüpfen. So arbeiten Ihre Techniker, Ihr Vertriebsteam und Ihre Auditoren mit derselben Datenbasis.
Wie kann ein Managed Service Provider (MSP) Backup-Ebenen standardisieren, wenn jeder Kunde unterschiedliche RPO- und RTO-Ziele wünscht?
Der nachhaltigste Ansatz besteht darin, wenige Backup-Ebenen mit festen RPO-, RTO- und Aufbewahrungsintervallen zu definieren und anschließend jedes System, jede Protokollquelle und jede Konfiguration jedem Kunden einer dieser Ebenen zuzuordnen. So können Sie sinnvolle Wahlmöglichkeiten bieten, ohne für jeden Dienst ein individuelles Muster zu erstellen.
Wie lassen sich geschäftliche Auswirkungen in konkrete Backup-Stufen übersetzen?
Ein praktikabler Ausgangspunkt für viele Managed Service Provider (MSPs) ist ein dreistufiges Modell, zum Beispiel:
- Stufe 1 – Beweis- und Kontrollebene:
Sicherheitsprotokolle, Kernnetzwerk- und Firewall-Konfigurationen, Identitätsplattformen und andere Steuerungsebenenkomponenten
– Typische RPO: Minuten bis eine Stunde • RTO: einige Stunden
- Tier 2 – Kontinuitätsdaten:
Anwendungsprotokolle und Konfigurationen, die die Verfügbarkeit von Diensten oder den Umsatz wesentlich beeinträchtigen.
– Typischer RPO: wenige Stunden • RTO: nächster Werktag
- Tier 3 – Unterstützende Protokolle:
Routinemäßige Betriebsprotokolle und Systeme mit geringen Auswirkungen
– Typischer RPO: täglich • RTO: „Best-Effort“ nur für Ermittlungen
Für jede Ebene sollten Sie in Ihrem ISMS Folgendes definieren:
- Wiederherstellungsziele (RPO/RTO) und Mindestbindung
- Zulässige Backup-Mechanismen (z. B. SIEM-Weiterleitung, geplante Exporte, Image-Snapshots)
- Speicher- und Schutzregeln (Region, Verschlüsselung, logische Trennung, optionale Unveränderlichkeit)
- Mindestanforderungen an Wiederherstellungstests für Ihren gesamten Kundenstamm
Anschließend ordnen Sie die Dienste, Protokolle und Konfigurationssätze jedes Kunden diesen Ebenen zu und berücksichtigen diese Zuordnung in Verträgen, Betriebshandbüchern und Sicherheitsplänen. Anstatt einen individuellen RPO/RTO-Wert pro Asset zu versprechen, können Sie sagen: „Dieser Dienst befindet sich in Ebene 1, was bedeutet…“ und entsprechende Nachweise vorlegen, die diese Aussage belegen.
Die Modellierung dieser Ebenen und Zuordnungen in ISMS.online – und deren direkte Verknüpfung mit Anhang A.8.13 – stellt sicher, dass jede Änderung (z. B. die Umstellung der Firewall eines Kunden von Ebene 2 auf Ebene 1 nach einer Risikoanalyse) mit Ihrem Backup-Standard, Ihrer Servicebeschreibung und Ihrem Nachweisdokument verknüpft ist. Diese Übereinstimmung zwischen Vertriebsversprechen, Technikerpraxis und Prüfergebnissen ist oft entscheidend für einen reibungslosen oder unangenehmen Auditverlauf.
Welche konkreten Nachweise überzeugen ISO 27001-Auditoren davon, dass die A.8.13-Kontrolle eines MSP wirksam ist?
Die Prüfer möchten sehen, dass Ihre Datensicherung für Systeme, Protokolle und Konfigurationen systematisch, konsistent und in der Praxis bewährt ist. Bei einer stichprobenbasierten Prüfung bedeutet dies üblicherweise eine Kombination aus schriftlichen Standards, Inventarlisten, Konfigurationsbeispielen, Überwachungsergebnissen und Wiederherstellungstestprotokollen, die alle dasselbe Bild zeichnen.
Welche Unterlagen sollten Sie vor Beginn des Audits bereithalten?
Bei einem typischen Überwachungs- oder Zertifizierungsbesuch sollten Sie mit Fragen aus drei Bereichen rechnen:
- Design und Umfang:
- Eine Backup-Richtlinie oder ein Standard, der Protokolle und Konfigurationen explizit als Informationsressourcen gemäß A.8.13 behandelt.
- Eine Service- oder Kundenübersicht, die aufzeigt, welche Systeme, Protokollquellen und Konfigurationssätze mit ihren jeweiligen Ebenen abgedeckt sind.
- Dokumentierte RPO/RTO-Ziele und Aufbewahrungsregeln pro Ebene oder pro Servicebereich
- Bedienung und Überwachung:
- Repräsentative Backup-Jobdefinitionen (z. B. Firewall-Konfigurationen, Identitätsexporte, SIEM-Pipelines, Datenbank-Snapshots)
- Überwachung von Ansichten oder Berichten über einen definierten Zeitraum, die den Umgang mit Erfolgen und Misserfolgen aufzeigen, einschließlich Nachweisen über die Nachverfolgung.
- Änderungsprotokolle, die belegen, dass neue Dienste, Mandanten oder Protokollquellen durch einen wiederholbaren Prozess in den Sicherungsbereich aufgenommen werden.
- Wirksamkeit und Verbesserung:
- Wiederherstellungstestdatensätze, die Protokolle und Konfigurationen enthalten, nicht nur Server oder Datenbanken.
- Notizen oder Maßnahmen aus Überprüfungen, bei denen ein Test fehlgeschlagen ist oder eine Schwäche aufgezeigt hat und Sie daraufhin etwas geändert haben
Auditoren wissen im Allgemeinen, dass Zwischenfälle und Fehlschläge vorkommen. Worauf sie achten, ist eine schlüssige Kette: Die Kontrollen sind definiert, das Design ist dokumentiert, die Prozesse werden ausgeführt, Fehler werden erkannt und realistische Wiederherstellungstests werden durchgeführt und entsprechende Maßnahmen ergriffen.
Wenn diese Informationen in verschiedenen Konsolen, Postfächern und persönlichen Ordnern gespeichert sind, geraten Sie und Ihr Team jedes Mal unter Druck, wenn ein Auditor eine Stichprobe anfordert. Wenn Sie stattdessen ISMS.online nutzen, um die A.8.13-Kontrolle einmalig zu definieren, Ihren Backup-Standard anzuhängen, den Umfang und die Auftragsstichproben jedes Mandanten zu verknüpfen und ein wiederverwendbares „Backup-Nachweispaket“ zu pflegen, können Sie die meisten Stichprobenanfragen zentral beantworten und nachweisen, dass A.8.13 kontrolliert und nicht improvisiert umgesetzt wird.
Wie kann ein Managed Service Provider (MSP) seinen Kunden eine sinnvolle Datensicherungsgarantie bieten, ohne dabei ein unbegrenztes Risiko einzugehen?
Sie geben Zusicherungen hinsichtlich evidenzbasierter Planung, Überwachung und Tests innerhalb klar definierter Grenzen ab, anstatt zu versprechen, dass niemals Daten verloren gehen. Kunden reagieren in der Regel positiv auf konkrete, überprüfbare Zusagen zu Umfang und Wiederherstellungsquoten, die durch aktuelle Erkenntnisse untermauert sind, und sind vorsichtiger gegenüber pauschalen Garantien, die realistischerweise nicht eingehalten werden können.
Wie gestaltet man eine Vertrauensgeschichte, die sich für Kunden sicher anfühlt und für das eigene Unternehmen nachhaltig ist?
Eine praxisorientierte Sicherheitserklärung beantwortet vier Fragen in einfacher Sprache:
- Was wir schützen: Welche Systeme, Protokollquellen und Konfigurationssätze werden für jeden verwalteten Dienst abgedeckt?
- Wie wir sie schützen: Die anwendbare Backup-Ebene, RPO/RTO, Aufbewahrungsregeln, Speicherorte und wichtige technische Kontrollen
- Wie wir uns selbst gegenüber ehrlich bleiben: Wie Backup-Aufträge überwacht, wie Fehler eskaliert und wie häufig Wiederherstellungen getestet werden
- Wo Ihre Verantwortung beginnt: Datenquellen, die exportiert oder aufbewahrt werden müssen, regulatorische Vorgaben, die eine verlängerte Aufbewahrung erfordern, und die verbleibenden Restrisiken
Dies lässt sich in einer kurzen, standardisierten „Übersicht über Datensicherung und -wiederherstellung“ zusammenfassen, die in Angeboten, Sicherheitsplänen und Schulungsunterlagen einheitlich verwendet wird. Im Hintergrund pflegen Ihre Teams für jeden Kunden eine aktuelle Zuordnung der Datensicherungsebenen, Live-Statusanzeigen der Aufträge und stets aktuelle Zusammenfassungen der Wiederherstellungstests.
Indem Sie diese Elemente in ISMS.online integrieren und mit Ihrem A.8.13-Controlling verknüpfen, können Sie potenziellen und bestehenden Kunden sowie gegebenenfalls deren Wirtschaftsprüfern zeigen, dass Ihre öffentlichen Zusagen mit den tatsächlich angewandten Sicherheitsmaßnahmen übereinstimmen. Eine solche präzise und nachweisbare Zusicherung ist in der Regel überzeugender als die einfache Aussage „Wir werden Ihre Daten niemals verlieren“ und schützt Ihr Unternehmen zudem im Falle einer späteren detaillierten Untersuchung eines Vorfalls.
Welche Aufbewahrungs- und Trennungsmuster sind für mandantenfähige Backups von Protokollen und Konfigurationen sinnvoll?
Ein praktikables Vorgehen für die meisten Managed Service Provider (MSPs) besteht darin, einige wenige risikobasierte Aufbewahrungsintervalle zu definieren und diese mit einer strikten logischen Trennung auf gemeinsam genutzten Backup-Plattformen zu kombinieren. Diese Kombination erfüllt in der Regel die Anforderungen an Sicherheit, Datenschutz und regulatorische Vorgaben und lässt gleichzeitig Raum für begründete vertragliche Ausnahmen.
Wie lassen sich in einer gemeinsam genutzten Umgebung Ermittlungsnutzen, Kosten und Datenschutz in Einklang bringen?
Viele Anbieter entscheiden sich für einen Ansatz in dieser Richtung:
- Haltebänder:
- Ein Standardfenster wie z. B. 90 Tagen. von Online-Sicherheitsprotokollen für die meisten Mandanten zur Durchführung des täglichen Betriebs und grundlegender Untersuchungen
- Verlängerte Aufbewahrung, zum Beispiel 12 – 18 Monatefür risikoreichere oder regulierte Arbeitslasten wie Zahlungen, Gesundheitswesen oder kritische Infrastrukturen
- Kürzere Aufbewahrungsfristen für operative Protokolle mit geringem Wert, bei denen Speicherkosten und Datenschutzrisiken den Nutzen für die Ermittlungen überwiegen.
- Optionale Langzeitarchivierung für spezifische „Beweismittel“, die bestimmte Kunden aus rechtlichen, vertraglichen oder regulatorischen Gründen aufbewahren müssen.
- Trennung und Schutz:
- Mandantenspezifische Verschlüsselungsschlüssel oder logisch getrennte Speichercontainer, Tresore oder Konten
- Strenge Zugriffspfade, damit Ingenieure und SOC-Analysten jeweils nur die Daten eines Kunden einsehen können.
- Rollenbasierter Zugriff mit minimalen Berechtigungen für Support-, Betriebs- und Überwachungsfunktionen
- Unveränderliche oder einmalig beschreibbare Einstellungen für wichtige Beweisspeicher, bei denen Manipulation oder Löschung besonders schädlich wären.
Aus der Perspektive von ISO 27001 geht es nicht nur darum, dass diese Maßnahmen existieren, sondern auch darum, dass man sie so beschreiben und demonstrieren kann, dass es für jeden Mandanten sinnvoll ist:
- Welche Protokoll- und Konfigurationsspeicher führen Sie für diesen Kunden?
- Wie lange die einzelnen Kategorien aufbewahrt werden und an welchen Orten
- Wie Trennung und Schutzmaßnahmen umgesetzt und im Laufe der Zeit überprüft werden
Wenn Sie dieses Design in ISMS.online modellieren – unter Verwendung eines einzigen Aufbewahrungs- und Trennungsstandards, der auf A.8.13 abgebildet und mit den einzelnen Kundenbereichen verknüpft ist – wird es wesentlich einfacher, Ihre Entscheidungen gegenüber Wirtschaftsprüfern, Datenschutzbeauftragten und Kunden zu begründen und konsistente Änderungen vorzunehmen, wenn sich Gesetze, Verordnungen oder Verträge weiterentwickeln.
Wie lässt sich Anhang A.8.13 in einen klaren, wiederholbaren Managed-Backup-Service umwandeln, der sowohl vom Vertrieb als auch von den Auditoren verstanden wird?
Sie nutzen A.8.13 als Grundlage für einen Managed-Backup- und Recovery-Service mit benannten Paketen, definierten RPO/RTO- und Aufbewahrungsfristen (auch für Protokolle und Konfigurationen) sowie einem Standard-Sicherheitspaket – alles gesteuert durch Ihr ISMS. So können Sie von einmaligen Zusagen zu einem stabilen Servicekatalog übergehen, der von Vertrieb, Implementierung, Kunden und Auditoren gleichermaßen anerkannt wird.
Wie sieht ein standardisiertes, A.8.13-konformes Backup-System im Kontext eines Managed Service Providers (MSP) aus?
Eine einfache Möglichkeit, dies zu strukturieren, besteht darin, eine kleine Anzahl von Paketen zu definieren, wie zum Beispiel:
- Unverzichtbare Datensicherung:
Kernserver und kritische Konfigurationen; eingeschränkte Protokollabdeckung; standardmäßige RPO/RTO- und Aufbewahrungsfristen für kleinere oder risikoärmere Kunden
- Garantierte Datensicherung:
Server mit höherwertigen Sicherheitsprotokollen und Konfigurationen mit hohem Sicherheitsrisiko; schnellere RPO/RTO und längere Aufbewahrungsfrist für Beweismittel zur Untersuchung und Einhaltung von Vorschriften.
- Erweiterte Datensicherung:
Umfassende Protokollabdeckung, verlängerte Aufbewahrungsfristen, unveränderliche Archive und häufigere Wiederherstellungstests für regulierte oder Hochrisikokunden
Für jedes Paket, das Sie dokumentieren:
- Welche Asset-Typen werden abgedeckt (Systeme, Protokollquellen, Konfigurationssätze)?
- Die anwendbare Backup-Ebene, RPO/RTO, Aufbewahrungs- und Speicher-/Schutzerwartungen
- Die Aufteilung der Verantwortlichkeiten zwischen Ihrem Team und dem Kunden
- Die Überwachungs- und Wiederherstellungstestverfahren, die Anwendung finden
- Wie das Paket Anhang A.8.13 und verwandten Bereichen wie Protokollierung, Vorfallmanagement und Geschäftskontinuität zugeordnet werden kann
Du dann:
- Erfassen Sie den Master-Backup-Standard und diese Paketdefinitionen einmalig in ISMS.online.
- Verknüpfen Sie Kundenverträge, Servicekataloge und Sicherheitspläne mit dem jeweiligen Paket.
- Pflegen Sie eine standardisierte Vorlage für die Nachweisdokumentation, die von Ingenieuren und Betriebspersonal im Rahmen des regulären Geschäftsbetriebs aktualisiert wird.
Mit der Zeit erhalten Sie dadurch eine einheitliche Sprache in Angeboten und Sicherheitsfragebögen („Sie nutzen unseren Assured-Backup-Tarif, der Folgendes beinhaltet…“), einen klaren und wiederverwendbaren Prüfpfad für ISO 27001 und einen deutlich einfacheren Einarbeitungsprozess für neue Teammitglieder. Außerdem positioniert es Ihr Unternehmen als Anbieter, dessen Backup-Verpflichtungen nicht nur zuverlässig, sondern auch nachweislich kontrolliert und reproduzierbar sind – genau den Eindruck, den informierte Kunden und Auditoren erwarten, wenn sie nach Ihrem Vorgehen gemäß A.8.13 fragen.
Wenn Sie einen pragmatischen Weg suchen, Theorie und Praxis umzusetzen, können Sie in ISMS.online einen einzelnen A.8.13-Backup-Standard entwerfen, Ihre ersten drei Stufen oder Pakete skizzieren und einen wichtigen Kunden diesem Modell zuordnen. Sobald sich dieses Muster für ihn bewährt hat, lässt es sich deutlich einfacher auf den Rest Ihres Managed-Services-Portfolios ausweiten.
