Warum die MSP-Vorsorge im Jahr 2025 unzureichend sein wird
Viele Managed Service Provider (MSPs) behandeln die Reaktion auf Sicherheitsvorfälle immer noch eher improvisiert als als dokumentierte, wiederholbare Fähigkeit, deren Wirksamkeit sie unter Aufsicht nachweisen können. Wenn Ihre Vorfallhistorie aus Screenshots, Chatverläufen und unvollständigen Tickets besteht, können Sie nicht belegen, dass Sie Vorfälle einheitlich planen, kontrollieren und prüfen. Diese Lücke wird schmerzlich deutlich, wenn ein Kunde, Versicherer oder Wirtschaftsprüfer einen klaren Zeitplan, nachvollziehbare Entscheidungen und Nachweise für die Erfüllung vertraglicher und regulatorischer Vorgaben verlangt.
Vorfälle scheitern selten aufgrund von Technologie; sie scheitern, weil Vorbereitung und Verantwortlichkeit nie klar definiert wurden.
In unserer ISMS.online-Umfrage zum Stand der Informationssicherheit 2025 gaben nur etwa ein Fünftel der Organisationen an, im Vorjahr keinen Datenverlust erlitten zu haben.
Operatives Chaos im alltäglichen Umgang mit Zwischenfällen
Operatives Chaos entsteht, wenn sich der Arbeitsablauf bei Sicherheitsvorfällen um Personen und Tools herum entwickelt, anstatt auf einem durchdachten, dokumentierten und für alle verständlichen Konzept zu basieren. Alltägliche Tickets mögen überschaubar erscheinen, doch ein schwerwiegender Sicherheitsvorfall deckt Lücken in Zuständigkeiten, Prioritäten und Kommunikation auf, die zwar schon immer bestanden, aber nie unter realem Druck getestet wurden.
MSP-Vorfälle folgen oft einem bekannten Muster:
- Zersplitterte Eigentumsverhältnisse: – Überwachung, Eindämmung und Kundenaktualisierungen sind in verschiedenen Teams angesiedelt, ohne dass es einen einzelnen verantwortlichen Verantwortlichen gibt.
- Ticketchaos: – Sicherheitsvorfälle teilen sich die Warteschlange mit Routinefehlern, wobei improvisierte Kategorien und inkonsistente Prioritäten verwendet werden.
- Vertragsdrift: – SLAs und Sicherheitspläne versprechen Reaktionsmuster, die Ihre tägliche Praxis nicht mehr widerspiegelt.
- Verwirrung bei mehreren Mietern: – Gemeinsam genutzte Plattformen erzeugen Probleme, die mehrere Kunden betreffen, doch Sie behandeln sie als isolierte Ereignisse.
- Schwaches Lernen: – Lehren aus großen Vorfällen finden selten Eingang in Handlungsanweisungen, Werkzeuge oder Verträge.
Dieses Muster erschwert es, den tatsächlichen Hergang zu beweisen, die Entscheidungsträger zu ermitteln und die Erfüllung vertraglicher Verpflichtungen zu überprüfen. Es führt außerdem dazu, dass sich jeder größere Vorfall neu anfühlt, selbst wenn die Ursache bekannt ist und mit besserer Vorbereitung und klarerer Planung reibungsloser hätte abgewickelt werden können.
Kunden, Versicherer und Aufsichtsbehörden setzen heute voraus, dass Ihr Krisenmanagement definiert, geübt und dokumentiert ist und nicht erst in einer Krise improvisiert wird. Die regulatorischen Vorgaben zu Sicherheit und personenbezogenen Daten legen zunehmend Wert auf dokumentierte, erprobte Prozesse und klare Aufzeichnungen, die den Umgang mit Vorfällen belegen und nicht nur deren Kenntnisnahme. Sie erwarten, dass Sie technische Arbeit, Entscheidungsfindung und Kommunikation team- und nutzerübergreifend koordinieren, ohne sich bei schwerwiegenden Problemen auf unüberlegte Maßnahmen oder Vermutungen zu verlassen.
Unternehmenskunden, Cyberversicherer und Aufsichtsbehörden gehen zunehmend davon aus, dass das Incident-Management definiert, geübt und dokumentiert ist und nicht erst im Ernstfall improvisiert wird. Branchenberichte über Sicherheitsvorfälle und Bedrohungen decken regelmäßig Lücken in der Vorbereitung und Kommunikation auf, was wiederum dazu führt, dass Stakeholder von ihren Anbietern eine besser dokumentierte Bearbeitung von Vorfällen fordern. Sie erwarten von Ihnen, dass Sie die technische Arbeit, Entscheidungsfindung und Kommunikation team- und mandantenübergreifend koordinieren können, ohne auf Einzelleistungen angewiesen zu sein. Die ISO/IEC 27001:2022, Kontrollpunkt A.5.24, gibt diesen Erwartungen konkrete Form und eine Sprache, die externe Prüfer bei der Bewertung Ihrer Fähigkeiten verwenden. Der Kontrolltext konzentriert sich auf Planung, Vorbereitung und klar zugewiesene Verantwortlichkeiten bei Informationssicherheitsvorfällen und bietet Auditoren und Gutachtern einen gemeinsamen Bezugspunkt bei der Prüfung von Managed Service Providern (MSPs).
In der Praxis bedeutet das, dass Sie früher oder später nachweisen müssen, dass Sie über eine dokumentierte Richtlinie und ein Verfahren für den Umgang mit Vorfällen verfügen, dass Ihre Mitarbeiter ihre Rollen kennen und bei Vorfällen einheitliche Vorgehensweisen befolgen und dass Sie nachvollziehbare Aufzeichnungen über Maßnahmen, Genehmigungen und Kommunikationen erstellen können. Können Sie dies heute nicht ohne Weiteres leisten, ist die Lücke nicht nur ein Problem der Einhaltung von Vorschriften; sie kann leicht zu einem umfassenderen Vertrauensverlust führen, der Vertragsverlängerungen, Weiterleitungen und die Versicherungsfähigkeit gefährdet.
Wie A.5.24 die Lücke in der MSP-Bereitschaft aufdeckt
A.5.24 deckt auf, ob Ihre Incident-Management-Strategie tatsächlich konzipiert und reproduzierbar ist oder lediglich eine lose Sammlung von Tickets und guten Absichten für viele Kunden darstellt. Für Managed Service Provider (MSPs) prüft die Kontrolle, ob Ihr Live-Betrieb den Anforderungen Ihrer Richtlinie entspricht und ob Sie Ihren Ansatz Außenstehenden, die Ihre Umgebung nicht kennen, verständlich erläutern können.
A.5.24 verpflichtet Sie, Prozesse, Rollen und Verantwortlichkeiten für das Incident-Management im Voraus zu definieren, festzulegen und zu kommunizieren und deren Anwendung nachzuweisen. Die Beschreibungen der Kontrollmaßnahmen betonen stets die Bedeutung dokumentierter Prozesse, klarer Verantwortlichkeiten und des Nachweises, dass diese Prozesse in der Praxis eingehalten werden, anstatt sich auf informelle Gewohnheiten zu verlassen. Für Managed Service Provider (MSPs) ist dies keine reine Formalität; es ist ein Test dafür, ob Ihre Incident-Management-Praxis in der Praxis einer kritischen Prüfung bei vielen Kunden gleichzeitig standhält und Außenstehenden verständlich erklärt werden kann.
Eine einfache Möglichkeit, Ihren aktuellen Zustand zu betrachten, besteht darin, sich drei Fragen zu stellen:
- Könnten Sie einem Prüfer zeigen, wo die Rollen, Prozesse und Verantwortlichkeiten im Zusammenhang mit Vorfällen dokumentiert und genehmigt sind?
- Könnten Sie einem strategischen Kunden einen kürzlich aufgetretenen Vorfall anhand eines einzigen, zusammenhängenden Berichts als verlässlicher Datenquelle erläutern?
- Könnten Sie nachweisen, dass die Lehren aus dem letzten größeren Vorfall zu Änderungen bei Vorgehensweisen, Werkzeugen oder Verträgen geführt haben?
Wenn eine der Antworten „nicht wirklich“ lautet, besteht Handlungsbedarf. Der Vorteil liegt darin, dass dieselben Grundlagen, die die Lücke gemäß A.5.24 schließen, auch das Chaos reduzieren, die Margen verbessern und es einfacher machen, Sie zu versichern und von Ihnen zu kaufen – insbesondere, wenn Sie Ihren Ansatz einfach und nachvollziehbar erläutern können.
KontaktWas ISO 27001:2022 A.5.24 wirklich fordert
ISO 27001:2022 A.5.24 verlangt von Ihnen den Betrieb eines echten Incident-Management-Frameworks und nicht nur die Existenz eines Dokuments mit dem Titel „Incident-Response-Plan“. Für einen Managed Service Provider (MSP) muss dieses Framework client- und plattformübergreifend funktionieren und gleichzeitig so einfach sein, dass es für Mitarbeiter verständlich und für Auditoren leicht zu beurteilen ist. Die Prüfung zielt im Wesentlichen darauf ab, ob Sie beschreiben können, was Sie beabsichtigen zu tun, wie Sie es tun, wer es tut und wie Sie es anschließend nachweisen.
Fast alle Befragten unserer ISMS.online-Umfrage zum Stand der Informationssicherheit 2025 nannten das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 als eine der obersten Prioritäten ihres Unternehmens.
A.5.24 verlangt weit mehr als nur einen allgemeinen „Notfallplan“. Vielmehr wird ein funktionierendes Rahmenwerk erwartet, das sich unter Druck erklären, anwenden und nachweisen lässt. Für einen Managed Service Provider (MSP) muss dieses Rahmenwerk für viele Kunden, verschiedene Technologien und unterschiedliche Vertragsarten geeignet sein, ohne unübersichtlich zu werden oder sich von der Realität zu entfernen. Es ist die Grundlage für den Nachweis der Einsatzbereitschaft und kein Dokument, das lediglich eine Checkliste für ein einmaliges Audit darstellt.
Die vier praktischen Ebenen von A.5.24 für MSPs
Sie können A.5.24 für Ihre Teams verständlicher machen, indem Sie es in vier praktische Ebenen unterteilen: Governance, Prozess, Kompetenz und Nachweis. Governance definiert Absicht und Befugnisse; der Prozess definiert den Lebenszyklus; die Kompetenz stellt Personal und Werkzeuge bereit; der Nachweis belegt, dass Sie die Vorgaben tatsächlich umsetzen. Zusammen ergeben sie eine einfache Checkliste, die der Denkweise von Auditoren und strategischen Kunden hinsichtlich Ihrer Notfallvorsorge entspricht.
A.5.24 lässt sich leichter verstehen, wenn man es in vier Ebenen unterteilt: Governance, Prozess, Kompetenz und Nachweis. Zusammen beschreiben sie, was Sie beabsichtigen zu tun, wie Sie es tun, wer es tut und wie Sie es später nachweisen – genau so, wie Wirtschaftsprüfer und strategische Kunden Sie beurteilen werden.
Schritt 1 – Klare Governance und Verantwortlichkeiten festlegen
Definieren Sie eine Richtlinie für Vorfälle, deren Geltungsbereich, Definitionen und benannte Rollen mit delegierter Befugnis, damit Entscheidungen nicht ins Stocken geraten.
Schritt 2 – Beschreiben Sie einen einfachen, wiederholbaren Prozess
Vereinbaren Sie, wie Ereignisse zu Vorfällen werden und wie sie definierte Lebenszyklusphasen durchlaufen, an denen sich die Mitarbeiter orientieren können.
Schritt 3 – Aufbau und Schulung der unterstützenden Fähigkeiten
Geben Sie den Menschen, den Werkzeugen und den Informationen die Struktur, die sie benötigen, um den Prozess mandantenübergreifend zuverlässig durchzuführen.
Schritt 4 – Nachweise für das Management von Vorfällen erfassen
Stellen Sie sicher, dass bei Vorfällen eine nachvollziehbare Aufzeichnung von Zeitabläufen, Entscheidungen, Maßnahmen und gewonnenen Erkenntnissen erstellt wird, die Sie anderen vorlegen können.
Im Hinblick auf die Unternehmensführung benötigen Sie eine genehmigte Vorfallrichtlinie, eine klare Definition dessen, was als „Ereignis“ und was als „Vorfall“ gilt, sowie klar benannte Rollen wie Vorfallmanager, technischer Leiter, Kommunikationsleiter und Kundenansprechpartner. Diese Rollen müssen über ausreichende Befugnisse verfügen, um schnell handeln zu können, und sowohl von Ihren Teams als auch von Ihren Kunden anerkannt werden.
Prozess bedeutet einen dokumentierten Lebenszyklus, der von allen Beteiligten erkannt und eingehalten wird. Ein gängiges Muster umfasst Erkennung und Meldung, Bewertung und Klassifizierung, Eindämmung und Beseitigung, Wiederherstellung und Verifizierung sowie die Auswertung der gewonnenen Erkenntnisse. Der Standard legt weniger Wert auf die genaue Bezeichnung, sondern vielmehr darauf, dass der Prozess dokumentiert, kommuniziert und konsequent angewendet wird, sodass niemand die einzelnen Schritte spontan improvisieren muss.
Leistungsfähigkeit hängt von den Mitarbeitern und den Werkzeugen ab. Analysten und Ingenieure müssen den Prozess und ihre Rolle darin verstehen. Überwachungs- und Ticketsysteme müssen den Lebenszyklus unterstützen, anstatt ihn zu behindern. Vorab genehmigte Kommunikationswege, Entscheidungskriterien und der Zugriff auf Protokolle und Nachweisquellen sorgen für einen reibungslosen Ablauf im täglichen Betrieb.
Die Bedeutung von Nachweisen wird von vielen Managed Service Providern (MSPs) unterschätzt. Sie benötigen Vorfallberichte mit Zeitstempeln, Maßnahmen und Genehmigungen, Aufzeichnungen von Übungen und Schulungen sowie Ergebnisse von Nachbesprechungen und Managementdiskussionen zu Vorfalltrends und deren Wirksamkeit. Plattformen wie ISMS.online erleichtern die Strukturierung und Abstimmung dieser Dokumente im gesamten Informationssicherheitsmanagementsystem, sodass Sie sie bei Bedarf schnell vorlegen können. Unsere Leitlinien zu Anhang A.5.24 konzentrieren sich auf die Strukturierung von Richtlinien, RACI-Matrizen und Vorfallberichten in einem zentralen ISMS, um eine durchgängige Verfügbarkeit dieser Dokumentation für interne und externe Prüfungen zu gewährleisten.
In der Praxis bietet Ihnen diese vierstufige Sichtweise eine einfache Checkliste: Richtlinien und Rollen vorhanden, Prozesse definiert, Fähigkeiten aktiviert und Nachweise erfasst. Wenn Sie alle vier Punkte zuverlässig abhaken können, fühlt sich A.5.24 eher wie eine Beschreibung Ihrer normalen Arbeitsabläufe als wie eine externe Anforderung an.
Wie A.5.24 mit dem Rest Ihres ISMS verbunden ist
A.5.24 verknüpft die Planung und Vorbereitung von Sicherheitsvorfällen mit dem umfassenderen Informationssicherheitsmanagementsystem und kann daher nicht als eigenständige Aufgabe betrachtet werden. Prüfer und Kunden werden überprüfen, ob Ihre Richtlinien für Sicherheitsvorfälle, Risikobewertungen, Ihr Lieferantenmanagement und Ihre Notfallplanung ein einheitliches Bild davon zeichnen, wie Sie mit Sicherheitsereignissen und Ausfällen umgehen.
A.5.24 ist keine isolierte Kontrollmaßnahme; sie berührt nahezu jeden Bereich Ihres Informationssicherheitsmanagementsystems. Das ist wichtig, denn Prüfer und Kunden achten auf Konsistenz und nicht nur auf ein einzelnes, optisch ansprechendes Dokument.
Rund 41 % der Organisationen gaben in unserer ISMS.online-Umfrage „State of Information Security 2025“ an, dass das Management von Drittparteirisiken und die Überwachung der Einhaltung von Vorschriften durch Lieferanten eine ihrer größten Herausforderungen im Bereich der Informationssicherheit darstellen.
Es verknüpft sich mit anderen ereignisbezogenen Kontrollmechanismen für Bewertung, Reaktion und Lernen. Protokollierungs- und Überwachungskontrollen unterstützen die Erkennung und Beweissicherung. Geschäftskontinuitäts- und Lieferantenkontrollen beeinflussen den Umgang mit Serviceausfällen und Fehlern von Drittanbietern. Die Kernklauseln des ISMS zu Kompetenz, Sensibilisierung, Leistungsbewertung und -verbesserung legen fest, wie Sie Mitarbeiter schulen, Ergebnisse messen und das System kontinuierlich optimieren.
Für Managed Service Provider (MSPs) besteht der eigentliche Wandel darin, nicht mehr zu fragen: „Haben wir eine Richtlinie für den Umgang mit Sicherheitsvorfällen?“, sondern: „Könnten wir unsere Fähigkeit zum Umgang mit Sicherheitsvorfällen – sowohl auf dem Papier als auch in der Praxis – gegenüber einem Auditor, einer Aufsichtsbehörde und einem strategischen Kunden nachweisen?“ Betrachtet man A.5.24 unter diesem Gesichtspunkt, wird es zum Kernstück des Bereitschaftsnachweises und nicht nur zu einer isolierten Checkliste. Es ebnet den Weg für die Diskussion darüber, wer welche Aufgaben übernimmt, wenn ein Vorfall sowohl Sie als auch Ihre Kunden betrifft.
A.5.24 in ein funktionierendes Rahmenwerk für verschiedene Kunden umwandeln
Ein praktikables A.5.24-Framework für einen Managed Service Provider (MSP) muss einen gemeinsamen Kern für alle Mandanten bieten und gleichzeitig kundenspezifische Verantwortlichkeiten und regulatorische Verpflichtungen berücksichtigen. Die einmalige Entwicklung dieses „Kern-plus-Variationen“-Modells und dessen anschließende Anwendung für jeden Kunden erspart die Neuerfindung des Incident-Managements für jeden Vertrag und reduziert das Risiko unkontrollierbarer Abweichungen.
Da Sie zahlreiche Organisationen betreuen, können Sie nicht für jeden Mandanten ein eigenes Incident-Management-System entwickeln und erwarten, dass es stets aktuell bleibt. Stattdessen definieren Sie ein Kernmodell, das für Ihr gesamtes Portfolio gilt, und passen dann die spezifischen Verantwortlichkeiten und Eskalationswege kundenspezifisch an, wobei Sie diese Unterschiede in Ihren Verträgen widerspiegeln.
In der Praxis sieht das aus wie ein standardisiertes Regelwerk für Vorfallsmanagement, ergänzt durch wiederverwendbare Playbooks und Runbooks, die alle auf A.5.24 und zugehörige Kontrollen abgestimmt sind. Kundenspezifische Bestimmungen, wie z. B. Benachrichtigungsregeln oder regulatorische Verpflichtungen, werden dann an diesen gemeinsamen Kern angehängt. Eine ISMS-Plattform bietet Ihnen die ideale Umgebung für dieses Modell und verknüpft Richtlinien, Risiken, Lieferanten, Kontinuität und Vorfälle in einer einzigen Umgebung, sodass Aktualisierungen und Überprüfungen einheitlich für alle Ihre Kunden erfolgen.
Sobald dieser gemeinsame Rahmen geschaffen ist, besteht der nächste logische Schritt darin, genau festzulegen, wie die Verantwortlichkeiten zwischen Ihrem Team und jedem einzelnen Kunden aufgeteilt sind. Hier kommen klare Rollen, RACI-Matrizen und Abgrenzungen ins Spiel.
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.
Definition von MSP- und Kundenrollen, RACI-Matrix und Abgrenzungen
Klare Rollen und Zuständigkeiten zwischen Ihrem Managed Service Provider (MSP) und jedem einzelnen Kunden sind bei schwerwiegenden Vorfällen genauso wichtig wie die technischen Abläufe. Ohne vereinbarte Verantwortlichkeiten riskieren Sie, regulatorische Fristen zu verpassen, Verzögerungen bei der Eindämmung zu erleiden und Kommunikationskonflikte zu verursachen, die das Vertrauen schädigen. Gemäß A.5.24 müssen diese Fragen vor einem Vorfall geklärt werden, nicht erst, wenn alle Beteiligten bereits unter Druck stehen.
Jeder schwerwiegende Vorfall mit einem Kunden wirft dieselben Fragen auf: Wer ist für welche Entscheidungen zuständig? Wer kommuniziert nach außen? Wer trägt die regulatorische Verantwortung? Diese Fragen lassen sich deutlich leichter beantworten, wenn sie im Vorfeld geklärt sind. A.5.24 erwartet, dass Sie diese Punkte festlegen, bevor etwas schiefgeht – nicht erst, wenn Sie einen laufenden Angriff abwehren und mitten in einer Krise über die Zuständigkeiten diskutieren. Klare Rollen sind die Grundlage für eine glaubwürdige Reaktionsfähigkeit von Managed Service Providern (MSPs) im Krisenfall.
Warum Sie mieterorientierte Rollen und Grenzen benötigen
Mieterorientierte Rollen und Zuständigkeiten gewährleisten, dass Ihr Team und Ihr Kunde Entscheidungen zum richtigen Zeitpunkt, mit der entsprechenden Befugnis und auf Basis eines gemeinsamen Verständnisses der Zuständigkeiten treffen. Unklare Zuständigkeiten können ein zunächst technisch vermeidbares Problem schnell in ein Vertrauensproblem verwandeln, das sich negativ auf Vertragsverlängerungen und Weiterempfehlungen auswirkt.
Unklare Rollenverteilung ist einer der schnellsten Wege, einen noch beherrschbaren Vorfall in eine Vertrauenskrise zu verwandeln. Wenn Ihr Team davon ausgeht, dass der Kunde die Aufsichtsbehörden informiert, während der Kunde erwartet, dass Sie ihm den Zeitpunkt der Benachrichtigung mitteilen, können wichtige Fristen unbeachtet verstreichen. Wenn niemand weiß, wer die Genehmigung für eingreifende Maßnahmen erteilt, zögern die Techniker, Diskussionen geraten ins Stocken und der Schaden wächst, während alle auf Anweisungen warten.
Ein mieterorientiertes RACI-Modell (Verantwortlich, Rechenschaftspflichtig, Beratend, Informiert) ermöglicht die einfache und wiederholbare Rollenzuweisung. Für jede Phase des Vorfalllebenszyklus definieren Sie die jeweilige Aktivität, die beteiligten Parteien und die Verteilung der Verantwortung. Dieses Modell dient als Grundlage für Verträge, Verfahren und Leitfäden, sodass Realität und Dokumentation übereinstimmen und beide Seiten wissen, was sie voneinander erwarten können.
Erstellung einer praktischen MSP-Kunden-RACI-Matrix
Eine praxisorientierte RACI-Matrix für Managed Service Provider (MSP) und deren Kunden basiert auf einem generischen Modell, das Ihre aktuelle Arbeitsweise widerspiegelt. Dieses Modell lässt sich dann an die Kritikalität und die regulatorischen Anforderungen der Kunden anpassen, ohne die Grundstruktur zu verändern. So bleibt die Arbeit für Ihre Teams einfach, während Account Manager gleichzeitig die Flexibilität erhalten, kundenspezifische Verantwortlichkeiten dort auszuhandeln, wo es darauf ankommt.
Ein guter Ausgangspunkt ist eine generische RACI-Matrix für einen „typischen“ Kunden, angepasst an Kritikalität und regulatorische Vorgaben. So können Sie das Modell fallweise anpassen, ohne es jedes Mal neu entwickeln zu müssen, und gleichzeitig die von Ihren Teams vertraute Struktur beibehalten.
Ein einfaches Beispiel aus einer Erzählung könnte so aussehen:
| Vorfallphase | Rolle des Kunden (Zusammenfassung) | Die Rolle des MSP (Zusammenfassung) |
|---|---|---|
| Erkennung und Meldung | Empfängt und leitet Benutzerberichte weiter | Überwacht Systeme und wandelt Warnmeldungen in Tickets um |
| Triage und Beurteilung | Bietet Kontext zur geschäftlichen Auswirkung | Klassifiziert und priorisiert Ereignisse und Vorfälle |
| Eindämmung | Genehmigt störende Maßnahmen | Schlägt technische Eindämmungsmaßnahmen vor und setzt diese um |
| Benachrichtigung | Verantwortlich für die regulatorische und öffentliche Berichterstattung | Liefert technische Details und Zeitangaben. |
| Lessons learned | Legt die Risikobereitschaft fest und ändert Änderungen | Dokumentiert die Ursachen und schlägt Verbesserungen vor |
Entscheidend ist nicht der genaue Wortlaut, sondern die Beseitigung von Unklarheiten. Keine Aktivität sollte in einem Umfeld stattfinden, in dem jede Seite stillschweigend davon ausgeht, dass die andere handeln wird. Bei der Erstellung von Leistungsbeschreibungen, SLAs, operativen Vereinbarungen und Onboarding-Materialien sollte diese RACI-Matrix klar erkennbar sein, damit Vertriebsversprechen, operative Realität und Kundenerwartungen übereinstimmen.
Umgang mit Aufsichtsbehörden, Beweismitteln und Dritten
Der Umgang mit Aufsichtsbehörden, Beweismitteln und Dritten erfordert mehr als allgemeine Formulierungen in Ihren Verträgen. Sie benötigen konkrete Auslöser, Entscheidungen und Übergabeprozesse für Szenarien, in denen Fristen und rechtliche Standards gelten. Die korrekte Berücksichtigung dieser Punkte in Ihrer RACI-Matrix schützt Sie und Ihre Mandanten, wenn Vorfälle externe Aufmerksamkeit erregen.
Die meisten Organisationen, die in unserem ISMS.online-Bericht „State of Information Security 2025“ aufgeführt sind, gaben an, im vergangenen Jahr von mindestens einem Sicherheitsvorfall im Zusammenhang mit Drittanbietern oder Lieferanten betroffen gewesen zu sein.
Bei manchen Aufgaben ist besondere Sorgfalt geboten, um Überraschungen in Krisenzeiten zu vermeiden, da externe Parteien involviert sind und feste Fristen gelten.
Gesetzliche Fristen sind wichtig. Wenn ein Kunde gesetzlich festgelegte Meldefristen hat, müssen Ihre Verträge und Verfahren genau festlegen, wer entscheidet, ob ein Vorfall meldepflichtig ist, wer die Frist startet und wer die Meldungen tatsächlich einreicht. Öffentliche Leitlinien zur Vorfallsmeldung betonen häufig die Notwendigkeit klarer Meldekriterien, definierter Verantwortlichkeiten und vereinbarter Fristen, insbesondere wenn gesetzliche Fristen gelten. Ihr Vorfallsmanagementprozess sollte Hinweise enthalten, die diese Entscheidungen rechtzeitig auslösen, sowie klare Eskalationswege bei Meinungsverschiedenheiten.
Die Eigentumsverhältnisse an Beweismitteln sind ein weiterer sensibler Bereich. Es bedarf Vereinbarungen darüber, wie Protokolle, Screenshots und andere Artefakte weitergegeben werden und wie die Nachweiskette lückenlos dokumentiert wird. Die Behandlung von Kundendaten als reine interne Angelegenheit wird einer rechtlichen oder behördlichen Prüfung nicht standhalten, wenn Ermittler nachfragen, wie Sie diese erhoben und geschützt haben.
Drittanbieter verkomplizieren die Zeitabläufe. Viele Vorfälle betreffen Cloud-Plattformen, SaaS-Anbieter oder Netzbetreiber. Ihre RACI-Matrix sollte klarstellen, wer welchen Anbieter kontaktiert, welche Informationen weitergegeben werden und wie diese Interaktionen in Ihrem Vorfallmanagementsystem erfasst werden, damit Sie später die Sorgfaltspflicht nachweisen können.
Nicht-technische Rollen wie Datenschutz, Recht und Personalwesen müssen ebenfalls klar definierte Rollen im Prozess einnehmen. Es reicht nicht aus, sie lediglich als „bei Bedarf einzubeziehen“ zu bezeichnen; sie benötigen Auslösebedingungen und erwartete Maßnahmen, damit ihre Arbeit reibungslos mit der technischen Reaktion zusammenarbeitet. Sobald diese Grenzen klar definiert sind, können Sie sie in den Richtlinien, Verfahren, Playbooks und Runbooks Ihrer Incident-Bibliothek verankern.
Entwicklung von Richtlinien, Verfahren, Spielanleitungen und Betriebshandbüchern
Ihre Fähigkeit zum Umgang mit Sicherheitsvorfällen lässt sich nur dann clientübergreifend skalieren, wenn Sie sie als kleine, gestaffelte Bibliothek aus Richtlinien, Verfahren, Playbooks und Runbooks organisieren, anstatt als einen einzigen, aufgeblähten Plan. Jede Ebene sollte eine andere Frage beantworten und für eine andere Zielgruppe verfasst sein – von Führungskräften, die die Richtlinien genehmigen, bis hin zu Analysten, die unter Zeitdruck Runbooks befolgen.
Eine effektive Incident-Management-Lösung für einen Managed Service Provider (MSP) ist kein einzelnes Dokument mit einem „Incident-Response-Plan“, das versucht, alles abzudecken. Vielmehr handelt es sich um eine kleine, in sich stimmige Sammlung von Richtlinien, Verfahren, Playbooks und Runbooks, die von verschiedenen Personen mit unterschiedlichem Detaillierungsgrad genutzt werden können und alle mit A.5.24 und den RACI-Matrizen zwischen MSP und Kunde verknüpft sind. Durch die gezielte Gestaltung dieser Sammlung können Sie Ihren Ansatz skalieren und seine Glaubwürdigkeit auch bei Überprüfungen gewährleisten.
Eine kleine, gestaffelte Bibliothek statt eines Monsterplans
Eine mehrschichtige Bibliothek verhindert, dass Ihre Vorfallsdokumentation unleserlich und veraltet wird, da jedes Dokument eine klare Aufgabe und Zielgruppe hat. Richtlinien definieren die Absicht, Verfahren den Lebenszyklus, Playbooks Szenarien und Runbooks die einzelnen Schritte auf Tool-Ebene. Zusammen vermitteln sie Ihren Teams und Auditoren ein einheitliches Bild davon, wie Sie Vorfälle bearbeiten.
Man kann sich die Bibliothek als vier Ebenen vorstellen, die unterschiedliche Fragen beantworten: Warum, Was, Wie und Mit welchen Werkzeugen. Durch die übersichtliche Gestaltung dieser Ebenen wird verhindert, dass Dokumente unübersichtlich werden, und die Mitarbeitenden wissen in stressigen Situationen genau, wo sie die benötigten Informationen finden – und haben nur Sekunden, nicht Minuten, um die richtige Anleitung zu finden.
Schritt 1 – Eine prägnante Richtlinie zum Vorfallmanagement verfassen
Legen Sie Umfang, Zielsetzung und übergeordnete Verantwortlichkeiten in einer kurzen, genehmigten Erklärung fest, die jeder verstehen kann.
Schritt 2 – Definieren Sie ein allgemeines Verfahren für das Vorfallmanagement
Beschreiben Sie die Phasen des Lebenszyklus, Entscheidungspunkte und Eskalationsregeln auf Prozessebene, unabhängig von spezifischen Werkzeugen.
Dokumentieren Sie Auslöser, Ziele, Rollen, Maßnahmen und Kommunikationsabläufe für typische Szenarien, mit denen Ihre Kunden tatsächlich konfrontiert werden.
Schritt 4 – Werkzeugspezifische technische Betriebshandbücher pflegen
Zeigen Sie schrittweise Aktionen auf spezifischen Plattformen an, auf die in Playbooks verwiesen wird, sodass Analysten und Ingenieure diese direkt nutzen können.
Die Richtlinie erläutert, warum Vorfälle bearbeitet werden, was in den Geltungsbereich fällt und wer letztendlich verantwortlich ist. Das Verfahren setzt diese Absicht in einen konsistenten Lebenszyklus um und erklärt, wann von einer Phase zur nächsten übergegangen wird. Playbooks wandeln den allgemeinen Prozess in konkrete, szenariospezifische Anleitungen um, denen Analysten folgen können. Runbooks verankern diese Szenarien in realen Tools, sodass Techniker nicht improvisieren müssen.
Die ersten wichtigen Strategien auswählen
Ihre ersten Handlungsanweisungen sollten die wahrscheinlichsten und schädlichsten Vorfälle für Ihre Kunden abdecken, nicht jedes theoretische Szenario. Die Konzentration auf wenige, aber wichtige Fälle erleichtert die Mitarbeiterschulung, die Optimierung der Anleitungen durch praktische Anwendung und den Nachweis konkreter Maßnahmen gegenüber Kunden und Wirtschaftsprüfern.
Sie benötigen nicht Dutzende von Handlungsanweisungen, um zu beginnen; im Gegenteil, eine überladene Bibliothek ist schwieriger zu pflegen und wird seltener genutzt. Es ist effektiver, einige wenige, aber hochwertige Szenarien zu entwickeln, die zu Ihrer Kundenbasis und Ihrem Technologie-Stack passen, und diese dann durch praktische Anwendung und strukturierte Übungen zu optimieren.
Gute frühe Kandidaten für MSP-Playbooks sind oft:
- Malware oder Ransomware auf einem verwalteten Endpunkt in einem typischen Client.
- Kompromittierung von Geschäfts-E-Mails über eine Standard-Cloud-E-Mail-Plattform.
- Kompromittierung eines privilegierten Kontos in einem Verzeichnis oder einer Cloud-Konsole.
- Verdächtige Aktivitäten auf einer gemeinsam genutzten Fernverwaltungsplattform.
- Beeinträchtigung der Dienste in Multi-Tenant-Systemen, die möglicherweise sicherheitsrelevant ist.
Jedes Handbuch sollte den Ablauf eines Vorfalls, die unmittelbaren Ziele, die beteiligten Rollen, die zu treffenden Entscheidungen und die zu sichernden Beweise definieren. Kurze, einheitliche Vorlagen erleichtern die Pflege und die Anwendung durch Analysten unter Zeitdruck und vereinfachen zudem die Einarbeitung neuer Mitarbeiter.
Runbooks enthalten dann toolspezifische Details, beispielsweise zur Isolierung eines Hosts in einem bestimmten Endpoint-Detection-Tool oder zum Export von Protokollen aus einer bestimmten Cloud-Plattform. Durch die Trennung von Richtlinien und Verfahren werden ständige Richtlinienänderungen bei Toolwechseln oder der Einführung neuer Plattformen für verschiedene Kundensegmente vermieden.
Dokumente nutzbar und realitätsnah halten
Ihre Dokumentation ist nur dann wertvoll, wenn sie Ihre aktuelle Arbeitsweise widerspiegelt und für Ihre Mitarbeiter leicht auffindbar ist. Einfaches Änderungsmanagement, klare Verantwortlichkeiten und die Integration in die täglichen Arbeitsabläufe sorgen dafür, dass Ihre Dokumentation den aktuellen Gegebenheiten entspricht und zeigen Auditoren, dass Sie Ihre Vorfallsunterlagen nicht nur erstellen, sondern auch pflegen.
Dokumente, die in einem isolierten Ordner gespeichert und nie aktualisiert werden, entfernen sich schnell von der tatsächlichen Praxis, was sowohl die Einsatzbereitschaft als auch die Glaubwürdigkeit von Audits beeinträchtigt. Um Ihre Dokumentenbibliothek aktuell zu halten, etablieren Sie eine einfache Änderungsroutine und verknüpfen Sie Aktualisierungen direkt mit Vorfällen und Übungen.
Nach größeren Vorfällen oder Übungen sollten Sie überprüfen, welche Dokumente hilfreich, welche unvollständig und welche fehlerhaft waren. Aktualisieren Sie die entsprechenden Richtlinien, Verfahrensanweisungen, Handbücher oder Ablaufpläne gezielt mit einer schlanken Versionskontrolle und Genehmigungsprozessen. Ihr Ziel ist es, schriftliche Vorgaben und die tatsächliche Praxis aufeinander abzustimmen, ohne das Team in Bürokratie zu erdrücken oder notwendige Änderungen zu verzögern.
Es ist außerdem hilfreich, diese Dokumente direkt am Arbeitsplatz einzubinden. Die direkte Verknüpfung von Playbooks und Runbooks mit Incident-Tickets oder SOC-Dashboards erhöht die Nutzungswahrscheinlichkeit erheblich, anstatt dass Mitarbeiter in einem separaten Repository suchen müssen. ISMS.online und ähnliche Plattformen können als zentrales Element dienen und Ihre Richtlinien und Verfahren mit Risiken, Lieferanten, Notfallplänen und Vorfallsaufzeichnungen verknüpfen, sodass Ihre Mitarbeiter stets aktuelle Anleitungen zur Hand haben. Sobald die Dokumentenbibliothek eingerichtet ist, besteht die nächste Herausforderung darin, sicherzustellen, dass Ihre Ticketing-, Monitoring- und SOC-Tools dieses Design auch tatsächlich widerspiegeln.
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.
Integration von A.5.24 mit Ticketing, Monitoring und SOC-Betrieb
A.5.24 bietet nur dann einen Mehrwert, wenn Ihr Incident-Design in den Tools widergespiegelt wird, die Ihre Teams täglich nutzen. Für die meisten Managed Service Provider (MSPs) sollte der Service Desk oder die IT-Service-Management-Plattform (ITSM) das zentrale System für Incidents sein, während Monitoring- und SOC-Tools die Daten auf vorhersehbare Weise einspeisen. Wenn diese Tools Ihre Prozesse, Rollen und Ihr Nachweismodell abbilden, können Sie die Kontrolle über die Vorfälle nachweisen, anstatt sich auf Erzählungen und Erinnerungen zu verlassen.
A.5.24 entfaltet seinen Wert erst dann, wenn er in Ihre täglichen Arbeitsabläufe und die tatsächliche Arbeitsweise Ihrer Teams integriert ist. Für die meisten Managed Service Provider (MSPs) sollte das Service-Desk- oder IT-Service-Management-System (ITSM) als zentrales System für Incidents dienen, wobei Monitoring- und SOC-Tools (Security Operations Center) kontrolliert Daten einspeisen. Bewährte Richtlinien für das Incident-Management empfehlen in der Regel einen zentralen Datensatz für jeden Vorfall, in den Erkennungssysteme und Reaktionsteams Daten einspeisen, anstatt separate, fragmentierte Protokolle zu führen. Wenn diese Tools Ihre Prozesse und Rollen widerspiegeln, wird Ihre Bereitschaft nachweisbar und nicht nur behauptet.
Das ITSM-Tool als Ihr Incident-System nutzen
Wenn Sie Ihre ITSM-Plattform als zentrales System zur Erfassung von Vorfällen nutzen, wird sichergestellt, dass jedes wichtige Ereignis eine strukturierte Dokumentation hinterlässt, die Sie überprüfen und weitergeben können. Sind Kategorien, Workflows und Felder mit A.5.24 und Ihrem Vorfalllebenszyklus abgestimmt, sind Sie nicht mehr auf verstreute E-Mails oder Chatprotokolle angewiesen, um den Vorfall zu dokumentieren; das Ticket selbst dient als Grundlage für die Dokumentation gegenüber Prüfern und Kunden.
Wenn Sicherheitsereignisse und -vorfälle über E-Mail-Verläufe, Chatkanäle und Ad-hoc-Dokumente verstreut sind, lässt sich die Kontrolle nur schwer nachweisen und aus Erfahrung lernen. Wenn Ihre ITSM-Konfiguration Ihrem Vorfallsmanagementprozess entspricht, hinterlässt jedes wichtige Ereignis eine strukturierte Spur, die Sie problemlos überprüfen und Kunden, Auditoren und Versicherern präsentieren können.
Schritt 1 – Definieren Sie, wie aus Warnmeldungen Vorfälle werden
Vereinbaren Sie, welche Warnmeldungen Tickets öffnen sollen und wie Analysten Vorfälle vor der Eskalation bestätigen und klassifizieren.
Schritt 2 – Kategorien, Prioritäten und Arbeitsabläufe konfigurieren
Richten Sie dedizierte Sicherheitskategorien, Schweregrade und Lebenszykluszustände ein, die Ihren dokumentierten Prozess widerspiegeln.
Schritt 3 – Strukturierte Daten für jeden Vorfall erfassen
Fügen Sie Felder und Vorlagen für Erkennungsquellen, Auswirkungen, Genehmigungen, Kommunikationsvorgänge und gewonnene Erkenntnisse hinzu.
Legen Sie zunächst fest, wie Überwachungsalarme in das ITSM-Tool gelangen. Überwachungssysteme sollten entweder automatisch Tickets erstellen oder eine Triage-Warteschlange speisen, in der Analysten entscheiden, ob Vorfälle eröffnet oder aktualisiert werden. Sobald ein Vorfall bestätigt ist, sollte er eindeutig als sicherheitsrelevant gekennzeichnet und mit einem vereinbarten Schweregrad versehen werden, der die Auswirkungen und die Dringlichkeit berücksichtigt, um eine einheitliche Reaktion zu gewährleisten.
Konfigurieren Sie Kategorien und Untertypen, um Sicherheitsvorfälle von routinemäßigen Serviceproblemen zu unterscheiden. Definieren Sie Lebenszyklusphasen wie „Offen“, „Triage“, „Untersuchung“, „Eindämmung“, „Wiederherstellung“, „Überprüfung“ und „Abgeschlossen“ und stellen Sie sicher, dass Tickets diese Phasen kontrolliert durchlaufen. Fügen Sie Felder und Vorlagen für wichtige Datenpunkte gemäß A.5.24 hinzu, z. B. Erkennungsquelle, betroffene Assets, wichtige Entscheidungen, Genehmigungen und Kommunikationsvorgänge, damit Prüfer den Sachverhalt auf einen Blick nachvollziehen können.
Um das zu verdeutlichen, stellen Sie sich eine Ransomware-Warnung auf einem verwalteten Endpunkt vor. Das Überwachungstool löst ein Ereignis aus, das ein Ticket für einen Sicherheitsvorfall öffnet. Dieses Ticket ist bereits mit Quelle, betroffenem Host, Erkennungsregel und Schweregrad vorausgefüllt. Analysten verwenden anschließend ein strukturiertes Formular, um Entscheidungen zur Priorisierung, Eindämmungsmaßnahmen, Clientbenachrichtigungen und abschließende Wiederherstellungsschritte in einem einzigen Datensatz zu dokumentieren. Das resultierende Ticket liest sich wie eine Zeitleiste, nicht wie ein Rätsel.
Verknüpfung von Überwachung, SOC und Kundenkommunikation
Monitoring- und SOC-Tools benötigen klare, dokumentierte Schnittstellen zu Ihrem Incident-Prozess, damit Warnmeldungen, Untersuchungen und Kundeninformationen stets aufeinander abgestimmt sind. Ihr Ziel ist ein kontrollierter Ablauf, in dem technische Systeme Tickets erstellen oder aktualisieren, Analysten diese verfeinern und eskalieren und Account-Teams auf nachvollziehbare und erklärbare Weise kommunizieren.
Im Bereich Monitoring und SOC sind klare und nachvollziehbare Abläufe von Warnmeldungen bis hin zu Datensätzen wichtig. SIEM-Systeme (Security Information and Event Management), EDR-Tools (Endpoint Detection and Response), Cloud-Sicherheitsplattformen und andere Quellen sollten Tickets gemäß den in Ihren Verfahren und Playbooks definierten Regeln entweder erstellen oder aktualisieren. Die Optimierung von Regeln zur Reduzierung von Fehlalarmen und Duplikaten steigert die Effizienz und zeigt, dass Sie sich intensiv mit der Erkennung auseinandergesetzt haben.
Bei schwerwiegenden Vorfällen kann ein Kommunikationsmechanismus wie ein eigens eingerichteter Chatkanal für den Krisenstab oder regelmäßige Telefonkonferenzen eingerichtet werden. Die Beteiligung, Entscheidungen und wichtigen Nachrichten aus diesem Kommunikationskanal sollten im Vorfallsbericht zusammengefasst werden, damit sie später nicht anhand von Protokollen und Erinnerungen rekonstruiert werden müssen, wenn jemand eine Chronologie verlangt.
Die Kundenkommunikation sollte derselben Struktur folgen. Änderungen des Schweregrades sollten interne Statusänderungen und gegebenenfalls externe Aktualisierungen über Statusseiten, E-Mails oder Anrufe des Account Managers auslösen. Die Verwendung vorab genehmigter Nachrichtenvorlagen und klarer Genehmigungsprozesse verringert das Risiko widersprüchlicher oder irreführender Aussagen unter Zeitdruck und erleichtert den Nachweis zeitnaher und angemessener Maßnahmen.
Aus jedem Vorfall lernen, um das System zu verbessern
Ihre Tools und Arbeitsabläufe sollten sich nach jedem schwerwiegenden Vorfall weiterentwickeln, damit der nächste Vorfall leichter zu bewältigen und zu dokumentieren ist. Durch die Integration von „Überprüfungs- und Verbesserungsphasen“ in Ihren Prozess wird A.5.24 zu einem Motor für operative Reife und nicht zu einer statischen Compliance-Aufgabe.
Die Planungs- und Vorbereitungsabsicht von A.5.24 wird nur dann erfüllt, wenn Sie Vorfälle nutzen, um Ihr System zu optimieren, anstatt jeden einzelnen als einmaliges Problem zu behandeln. Das bedeutet, ein wiederholbares Muster für die Überprüfung von Vorfällen zu entwickeln und deren Ergebnisse in nachvollziehbare Veränderungen einfließen zu lassen.
Fragen Sie sich nach jedem größeren Vorfall, ob die Tools und Prozesse hilfreich oder hinderlich waren. Hatten Sie alle benötigten Informationen an einem Ort? Gab es manuelle Schritte, die durch einfache Formulare oder Automatisierungen hätten ausgelöst werden können? War der Ablauf vom Erkennen bis zum Abschluss des Vorfalls nachvollziehbar dokumentiert und für andere nachvollziehbar?
Setzen Sie diese Erkenntnisse in konkrete Maßnahmen um: Passen Sie Kategorien an, optimieren Sie Arbeitsabläufe, ändern Sie Vorlagen, verbessern Sie Playbooks oder aktualisieren Sie Verträge. Dokumentieren Sie Verbesserungsmaßnahmen so, dass Sie deren Abschluss nachverfolgen und in Management-Reviews darauf verweisen können. Dadurch wird A.5.24 im Laufe der Zeit von einer statischen Kontrollmaßnahme zu einem Motor für kontinuierliche Verbesserung in Ihren MSP-Prozessen. Dies führt ganz natürlich zu Fragen darüber, wie Sie die Nachweise gestalten und schützen, auf denen diese Reviews basieren.
Beweissicherung, Protokollierung und forensische Bereitschaft für Multi-Tenant-MSPs
A.5.24 setzt voraus, dass Sie nachweisen können, wie Vorfälle behandelt wurden, und nicht nur behaupten, dass sie angemessen behandelt wurden. Für Managed Service Provider (MSPs) ist dies schwierig, da sie die Qualität der Nachweise, die Trennung von Mandanten und die Einhaltung der Datenschutzbestimmungen gegenüber einer Vielzahl von Kunden und Anbietern in Einklang bringen und gleichzeitig die Kosten im Griff behalten müssen. Ein durchdachtes, dokumentiertes Nachweismodell macht diesen Balanceakt zu einer wiederholbaren Praxis anstatt zu einem unstrukturierten Vorgehen. Kommentare zum Kontrollmechanismus unterstreichen häufig den Bedarf an Aufzeichnungen und Artefakten, die Planung, Entscheidungsfindung und Nachverfolgung belegen, und nicht nur allgemeine Aussagen über die erfolgte Reaktion.
Entwicklung eines mieterspezifischen Nachweismodells
Ein mandantenbezogenes Beweismodell hilft Ihnen, sowohl blinde Flecken als auch versehentliche Datenlecks zu vermeiden, indem es definiert, welche Protokolle und Artefakte erfasst werden, wo sie gespeichert werden und wie sie mit Vorfallsaufzeichnungen verknüpft sind. Wenn alle dieses Modell verstehen, können Sie Untersuchungen souverän bearbeiten, anstatt in unkontrollierten Datenbeständen suchen zu müssen.
Ein einfaches, dokumentiertes Nachweismodell für jeden Kunden hilft Ihnen, sowohl Datenlücken als auch versehentliche Datenoffenlegung zu vermeiden. Das Modell sollte klären, welche Protokolle und Artefakte Sie erfassen, wo diese gespeichert werden, wie die Zeiterfassung erfolgt und wie Datensätze mit Vorfällen in Ihren ITSM- oder Fallmanagement-Systemen verknüpft sind.
Schritt 1 – Wichtige Protokoll- und Ereignisquellen pro Client auflisten
Ermitteln Sie, welche Systeme sicherheitsrelevante Datensätze generieren und wie Sie schnell darauf zugreifen können.
Schritt 2 – Speicher-, Zeitsynchronisierungs- und Aufbewahrungsregeln definieren
Dokumentieren Sie, wo Daten gespeichert werden, wie die Uhren synchronisiert bleiben und wie lange Sie die einzelnen Datensatztypen aufbewahren.
Schritt 3 – Beweismittel mit Vorfallsakten verknüpfen
Beschreiben Sie, wie Protokolle, Artefakte und Entscheidungen mit Tickets verknüpft werden, um sie später zu überprüfen und zu auditieren.
Sie benötigen kein aufwendiges Diagramm für jeden Kunden, sollten aber beispielsweise erklären können, dass sicherheitsrelevante Protokolle definierter Systeme in zentrale Repositories oder klar definierte Speicher fließen, dass die Uhren synchronisiert sind, sodass Zeitabläufe plattformübergreifend Sinn ergeben, und dass der Zugriff auf diese Speicher kontrolliert und protokolliert wird. Diese Erklärung sollte mit Ihren Richtlinien und Verträgen übereinstimmen.
Die Verknüpfung von Beweismitteln mit Vorfällen kann so einfach sein wie das Zuordnen von Protokollauszügen, Berichten oder Verweisen zu bestimmten Repositories in Ihren ITSM-Tickets. Entscheidend ist, dass jemand den Vorfall später anhand der Aufzeichnungen rekonstruieren kann, ohne mühsam Systeme und Konten durchsuchen zu müssen, und dass nachvollziehbar ist, warum bestimmte Entscheidungen zu bestimmten Zeitpunkten getroffen wurden.
Aufbewahrung, Zugriff und Trennung richtig umsetzen
Aufbewahrung, Zugriff und Trennung von Vorfallsdaten müssen rechtliche Verpflichtungen, Kundenerwartungen und betriebliche Erfordernisse in Einklang bringen. Zu viele Daten, die zu lange aufbewahrt werden, erhöhen das Risiko; zu wenige Daten oder eine übermäßig aggressive Löschung verhindern, dass Sie Untersuchungen unterstützen oder im Falle von Nachfragen Ihre Sorgfaltspflicht nachweisen können.
Bei Entscheidungen über Aufbewahrung und Löschung von Daten müssen Sicherheit, Datenschutz und Kosten abgewogen werden. Eine zu lange Aufbewahrung erhöht das Risiko und kann gegen Datenschutzbestimmungen verstoßen; eine zu aggressive Löschung erschwert die Beantwortung berechtigter Fragen nach einem Vorfall oder die Unterstützung rechtlicher Verfahren.
Dokumentieren Sie Ihre Vorgehensweise bei verschiedenen Datentypen wie Rohdaten, aggregierten Ereignissen und Untersuchungsergebnissen. Geben Sie an, wo Sie aus regulatorischen oder vertraglichen Gründen längere Aufbewahrungsfristen festlegen, und definieren Sie Auslöser für eine verlängerte Aufbewahrung bei bestimmten Vorfällen, z. B. bei behördlichen Anordnungen oder Versicherungsermittlungen. Erläutern Sie, wie und wann Daten sicher gelöscht werden, und stellen Sie sicher, dass diese Vorgehensweise Ihren Richtlinien und Kundenvereinbarungen entspricht.
In einer Umgebung mit mehreren Mietern ist die Trennung von Daten genauso wichtig wie die Kundenbindung. Sie möchten die Gewissheit haben, dass:
- Analysten, die einen Kunden untersuchen, können nicht einfach beiläufig die Daten eines anderen Kunden durchsuchen.
- Administrative Vorgänge in Bezug auf Protokoll- und Beweismittelarchive werden selbst protokolliert und regelmäßig überprüft.
- Wenn Sie Artefakte mit Kunden teilen, tun Sie dies über genehmigte, sichere Kanäle mit klaren Zugriffskontrollen.
Diese Anforderungen sollten in Ihrem Nachweismodell und Ihren Betriebsabläufen enthalten sein. Bei Verwendung einer ISMS-Plattform können Sie Nachweisreferenzen häufig zentralisieren und gleichzeitig die zugrunde liegenden Daten in segmentierten technischen Speichern ablegen. So wahren Sie die Trennung, ohne den Überblick darüber zu verlieren, wo welche Daten gespeichert sind.
Die Beweissicherung in den Arbeitsalltag integrieren
Die Beweissicherung muss in die täglichen Maßnahmen zur Reaktion auf Vorfälle integriert werden und darf nicht als optionaler nachträglicher Gedanke behandelt werden, wenn Sie zuverlässige Aufzeichnungen gemäß A.5.24 benötigen. Indem Sie wichtige Schritte zur Beweissicherung in Checklisten innerhalb von Playbooks, Runbooks und Ticketvorlagen umwandeln, erleichtern Sie es den Analysten, auch unter Druck das Richtige zu tun.
Der richtige Zeitpunkt, um über Beweise nachzudenken, ist nicht erst nach Abschluss eines Vorfalls, sondern während der Ausführung von Einsatzplänen und Handlungsanweisungen in Echtzeit. Wenn die Beweissicherung als zusätzliche Arbeit empfunden wird, wird sie unter Druck vernachlässigt, und die Lücke wird erst dann entdeckt, wenn kritische Fragen gestellt werden.
Um dies zu vermeiden, sollten Playbooks und Runbooks so gestaltet sein, dass wichtige Aktionen explizite Nachweisschritte beinhalten. Beispielsweise erstellen Analysten vor der Isolierung eines Hosts vereinbarte Screenshots oder exportieren bestimmte Protokolle; nach dem Zurücksetzen von Zugangsdaten protokollieren sie, welche Konten wann geändert wurden; bei der Benachrichtigung eines Kunden fügen sie die genehmigte Stellungnahme bei und vermerken, wer diese wann unterzeichnet hat.
Abgeschlossene Vorfälle eignen sich gut als Beispielprüfung. Wählen Sie regelmäßig einige aus und prüfen Sie diese aus der Perspektive eines Prüfers, einer Aufsichtsbehörde oder eines strategischen Kunden. Prüfen Sie, ob ein vollständiger Zeitablauf von der Entdeckung bis zum Abschluss vorliegt, ob die Gründe für die wichtigsten Maßnahmen nachvollziehbar sind und ob die beigefügten Nachweise einen externen Prüfer überzeugen würden. Falls die Antwort „Nein“ lautet, optimieren Sie Ihr Nachweismodell, Ihre Dokumentation und Ihre Schulungen, um bei ähnlichen Vorfällen bessere Aufzeichnungen und Analysen zu erzielen und so die Grundlage für gezieltere Prüfungen zu schaffen.
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.
Schulung, Übungen und ISMS-Integration in den Abschnitten A.5.24–A.5.30
Schulungen und Übungen machen Ihr A.5.24-Design zu einer dynamischen Lösung, die auch unter Stressbedingungen genutzt werden kann. Für einen Managed Service Provider (MSP) bedeutet dies, spezifische Aufgaben im Umgang mit Vorfällen maßgeschneiderten Schulungen zuzuordnen, realistische Szenarien mit verschiedenen Mandanten durchzuspielen und die gewonnenen Erkenntnisse in Ihr übergeordnetes Informationssicherheitsmanagementsystem (ISMS) einfließen zu lassen, damit Verbesserungen sichtbar und nicht nur angenommen werden.
Rund zwei Drittel der Organisationen, die an unserer ISMS.online-Umfrage zum Stand der Informationssicherheit 2025 teilnahmen, gaben an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Einhaltung von Sicherheits- und Datenschutzbestimmungen immer schwieriger machen.
A.5.24 setzt voraus, dass Ihre Notfallprozesse nicht nur schriftlich festgehalten, sondern auch von denjenigen, die sie anwenden müssen, verstanden und geübt werden. Leitlinien von Normungsorganisationen zur Notfallplanung betonen immer wieder, dass Schulungen, Übungen und die Vertrautheit der Mitarbeiter mit den Verfahren unerlässliche Ergänzungen zur schriftlichen Dokumentation darstellen. Für Managed Service Provider (MSPs) bedeutet dies, spezifische Fähigkeiten in verschiedenen Rollen zu entwickeln und Übungen durchzuführen, um sowohl Ihre Planung als auch Ihre Einsatzbereitschaft über verschiedene Mieter und Zeitzonen hinweg zu testen. Schulungen und Übungen schließen die Lücke zwischen sorgfältig ausgearbeiteten Dokumenten und der komplexen Realität im Notfall.
Zuordnung von Rollen zu den Schulungen, die sie tatsächlich benötigen
Unterschiedliche Rollen erfordern unterschiedliche Schulungen, um Auslöser von Vorfällen zu erkennen, Verfahren einzuhalten und fundierte Entscheidungen zu treffen. Die Zuordnung dieser Rollen zu konkreten Lernzielen macht Ihr Schulungsprogramm zielgerichtet und messbar und liefert überzeugende Belege dafür, dass A.5.24 in der Praxis verankert und nicht nur theoretisch ist.
Allgemeine Sicherheitsschulungen bereiten Ihre Teams nicht auf die Bearbeitung von Sicherheitsvorfällen in mandantenfähigen Umgebungen vor, wo Verantwortlichkeiten über Organisationsgrenzen hinwegreichen. Sie müssen Rollen konkreten Lernzielen zuordnen und anschließend anhand Ihrer realen Playbooks, Runbooks und Tools trainieren, damit sich die Teilnehmenden in den Szenarien wiederfinden.
Schritt 1 – Identifizierung der ereignisbezogenen Rollen in den verschiedenen Teams
Listen Sie Analysten, Ingenieure, Account Manager, Datenschutzbeauftragte, Rechtsberater und leitende Entscheidungsträger auf, die mit Vorfällen in Berührung kommen.
Schritt 2 – Definieren Sie, was jede Rolle erkennen und tun muss.
Legen Sie Auslöser, Aktionen, Eskalationswege und Kommunikationsaufgaben pro Rolle fest, einschließlich des Zeitpunkts der Übergabe.
Nutzen Sie kurze Sitzungen, in denen realistische Vorfälle anhand Ihrer Live-Tools und tatsächlicher Ticketprozesse durchgespielt werden.
Analysten im Kundenservice und Service-Desk-Mitarbeiter müssen die Auslöser von Vorfällen erkennen, die vorgegebenen Vorgehensweisen befolgen und fortlaufend Beweise sichern. Techniker müssen die vorgegebenen Vorgehensweisen sicher umsetzen, die Eindämmungsoptionen kennen und wissen, wann sie zur Genehmigung eskalieren müssen. Account Manager sollten wissen, wann und wie sie mit Kunden kommunizieren, insbesondere in unklaren Anfangsphasen. Führungskräfte benötigen Klarheit darüber, in welchen Situationen ihr Eingreifen erforderlich ist und welche Entscheidungen sie gegebenenfalls schnell und unter unvollständigen Informationen treffen müssen.
Schulungen sind am effektivsten, wenn sie mit Ihrer tatsächlichen Vorfallbibliothek und Ihren Tools durchgeführt werden. Das Durchspielen eines Ransomware-Szenarios in Ihrer realen Ticket- und Überwachungsumgebung ist deutlich wirksamer als eine allgemeine Präsentation, da die Mitarbeiter genau sehen, welche Bildschirme, Felder und Arbeitsabläufe sie beim nächsten Vorfall verwenden werden.
Ein Trainingsprogramm entwerfen, das sich real anfühlt
Ein Übungsprogramm sollte sowohl Ihre Mitarbeiter als auch Ihr Konzept auf die Probe stellen, indem realistische, zeitlich begrenzte Vorfälle simuliert werden, die Ihre Kundenbasis widerspiegeln. Durch den Wechsel von Szenarien und Kundensegmenten gewinnen Sie Vertrauen in die Wirksamkeit Ihres A.5.24-Ansatzes unter verschiedenen Bedingungen und belegen, dass Ihr Managed Service Provider (MSP) die Einsatzbereitschaft ernst nimmt.
Variieren Sie die drei Dimensionen, um die Übungen sinnvoll zu gestalten:
- Szenariotyp: – Ransomware bei einem wichtigen Kunden, Kompromittierung einer gemeinsam genutzten Managementplattform, Verdacht auf Datenleck oder Fehlkonfiguration der Cloud.
- Kundensegment: – regulierte versus nicht regulierte Kunden oder Konten mit hoher versus mittlerer Kritikalität.
- Frequenz: – vierteljährliche interne Übungen und gelegentliche gemeinsame Übungen mit ausgewählten Klienten, bei denen das Risiko am höchsten ist.
Gemeinsame Übungen mit wichtigen Kunden können besonders wirkungsvoll sein. Sie helfen, Erwartungen abzustimmen, RACI-Matrizen zu überprüfen und vertragliche Annahmen aufzudecken, die unter Druck nicht standhalten. Zudem liefern sie aussagekräftige Belege für Wirtschaftsprüfer und Risikoausschüsse, dass Sie die Einsatzbereitschaft in gemeinsamen Umgebungen ernst nehmen. Gut durchgeführte Übungen hinterlassen in der Regel Protokolle, Berichte und Maßnahmen zur Verbesserung, die Aufsichtsgremien als konkreten Nachweis dafür prüfen können, wie Sie Ihre Reaktionsfähigkeit trainieren und optimieren.
Behandeln Sie jede Übung wie einen kleinen Vorfall. Dokumentieren Sie, was funktioniert hat, was nicht und was in Dokumenten, Tools oder Vereinbarungen geändert werden muss. Verfolgen Sie diese Maßnahmen und fassen Sie sie in Ihrem Management-Review-Programm zusammen, um Verbesserungen im Zeitverlauf und nicht nur Aktivitäten aufzuzeigen. Dieses Vorgehen verknüpft A.5.24 direkt mit den umfassenderen Klauseln zur Leistungsbewertung und -verbesserung in Ihrem ISMS.
Schließen des Kreislaufs in Ihrem ISMS
Der wahre Nutzen von A.5.24 zeigt sich, wenn die Planung von Vorfällen, Schulungen und Übungen in das Risikomanagement, die Lieferantenüberwachung und die Geschäftskontinuität einfließen und so Ihr gesamtes ISMS stärken. Dieser Kreislauf verdeutlicht, dass die Bereitschaft für Vorfälle integraler Bestandteil Ihrer Unternehmensführung ist und nicht nur eine isolierte technische Angelegenheit.
A.5.24 ist neben anderen ereignisbezogenen Kontrollmaßnahmen wie Bewertung, Reaktion, Lernen und Geschäftskontinuität angesiedelt und fließt in Ihr gesamtes Managementsystem ein. Durch Übungen und Schulungen, die diese Kontrollmaßnahmen unterstützen, wird Ihre Ereignisbearbeitung zu einem Motor für systemweite Verbesserungen und nicht zu einem isolierten Prozess.
Beispielsweise sollten Muster aus Vorfällen und Übungen in Risikobewertungen, Lieferantenbewertungen und Notfallpläne einfließen. Wiederholte Probleme mit einer bestimmten Plattform können Lieferantenüberprüfungen oder Technologieänderungen auslösen. Lücken in Schulungen oder Entscheidungsprozessen können zu Änderungen in Kompetenz- und Sensibilisierungsprogrammen oder Anpassungen Ihrer RACI-Matrix und Eskalationsregeln führen.
Die zentrale Erfassung von Vorfallsberichten, Übungsberichten und Verbesserungsmaßnahmen auf einer Plattform wie ISMS.online macht diese Zusammenhänge sichtbar. Zudem erleichtert sie es, Auditoren zu verdeutlichen, wie Ihre Vorfallsplanung und -vorbereitung Ihr Informationssicherheitsmanagementsystem beeinflussen und von diesem beeinflusst werden. So entsteht eine natürliche Brücke zu Gesprächen darüber, wie Technologie Ihre Ziele gemäß A.5.24 unterstützen kann.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online unterstützt Sie dabei, ISO 27001 A.5.24 von einer statischen Kontrollmaßnahme in eine dynamische, MSP-fähige Incident-Management-Lösung zu verwandeln, die Sie für alle Ihre Kunden einsetzen und nachweisen können. Durch die Verknüpfung von Richtlinien, RACI-Matrizen, Playbooks, Incident-Berichten, Nachweisen und Verbesserungsmaßnahmen in einer zentralen Umgebung erhalten Sie ein solides Fundament für Ihre Incident-Bereitschaft, das mit Ihrem Portfolio skaliert und Ihre Vorgehensweise gegenüber Kunden, Auditoren und Versicherern transparent macht. Die Art und Weise, wie die Plattform die Incident-Planung, Verantwortlichkeiten und Dokumentation gemäß Anhang A.5.24 organisiert, ist speziell darauf ausgelegt, MSPs bei Nachfragen sowohl die Planung als auch die Durchführung von Incidents zu erleichtern.
Was Sie davon haben, ISMS.online in Aktion zu sehen
Die schnellste Methode, um zu beurteilen, ob eine strukturierte Implementierung von A.5.24 zu den Arbeitsabläufen Ihres Managed Service Providers (MSP) passt, ist, ISMS.online in Aktion zu erleben. Ein gezielter Rundgang kann einen realen Vorfall von der Erkennung bis zu den gewonnenen Erkenntnissen nachverfolgen, aufzeigen, wo Richtlinien und RACI-Matrizen gespeichert sind, wie Vorfallsaufzeichnungen mit Ihrem Nachweismodell übereinstimmen und wie Managementansichten alles für die Überwachung und Berichterstattung zusammenführen.
Ein kurzer, fokussierter Rundgang ermöglicht es Ihnen zu testen, wie ein strukturierter Ansatz für das Incident-Management Ihre eigenen jüngsten Vorfälle verändern würde. Sie können untersuchen, wie Incident-Richtlinien und -Verfahren mit A.5.24 übereinstimmen, wie RACI-Matrizen und Playbooks erfasst werden, wie Vorfalldatensätze mit Nachweisen und Verbesserungsmaßnahmen verknüpft sind und wie Managementansichten all dies an einem Ort zusammenführen. Die Verknüpfung dieser Elemente erleichtert die Beurteilung, ob dies die richtige Grundlage für die Incident-Bereitschaft Ihres MSP ist.
Entscheidung, ob ISMS.online das Richtige ist
Die Wahl der richtigen Plattform für A.5.24 hängt im Wesentlichen davon ab, wie Sie die Reaktionsfähigkeit Ihrer Teams und Kunden auf Sicherheitsvorfälle gestalten möchten. Wenn Sie ein nachvollziehbares, mandantenübergreifend skalierbares und in Ihr bestehendes ISMS integriertes Incident-Management-System (statt einer nachträglichen Erweiterung) benötigen, bietet ISMS.online eine praxisorientierte und standardkonforme Grundlage.
ISMS.online ist die richtige Wahl für Sie, wenn Sie eine auditierbare, mandantenübergreifend skalierbare und in Ihr Informationssicherheitsmanagementsystem integrierte Lösung zur Vorbereitung auf Sicherheitsvorfälle benötigen. Wenn Sie Wert auf unabhängige Audits, strukturierte Nachweise und eine zentrale Datenquelle legen, die Sie Kunden, Auditoren und Versicherern vorlegen können, unterstützen wir Sie gerne.
Ein Gespräch, in dem ein oder zwei reale Vorfälle und deren mögliche Auswirkungen auf ein integriertes ISMS besprochen werden, zeigt, ob dies die richtige Grundlage für Ihre nächste Wachstumsphase bildet. Wenn Ihr aktueller Stand den zuvor beschriebenen Lücken entspricht und Sie bereit sind, A.5.24 zu stärken, indem Sie das Chaos im Umgang mit Vorfällen in eine strukturierte, wirtschaftlich wertvolle Fähigkeit verwandeln, unterstützt Sie ISMS.online gerne.
KontaktHäufig gestellte Fragen (FAQ)
Wie sollte ein Managed Service Provider (MSP) ISO 27001:2022 A.5.24 im täglichen Betrieb interpretieren?
ISO 27001:2022 A.5.24 erwartet von Ihrem Managed Service Provider (MSP), dass eine wiederholbare Vorfallsfunktion ausführenEs geht nicht nur darum, eine „Vorfallsrichtlinie“ in Ihrem ISMS zu speichern. In der Praxis bedeutet das, dass Sie einen Vorfalllebenszyklus entwerfen, mit Ressourcen ausstatten, betreiben und regelmäßig testen – und nachweisen können, dass reale Fälle diesem Entwurf gefolgt sind.
Was bedeutet „geplant und vorbereitet“ für einen Managed Service Provider (MSP)?
Für einen Managed Service Provider ist A.5.24 in vier sehr sichtbaren Bereichen relevant:
- Design: – eine Richtlinie und ein dokumentiertes Verfahren, die zu Ihrem Informationssicherheitsmanagementsystem (ISMS) oder Annex L Integrated Management System (IMS) passen, mit klaren Definitionen dessen, was mandanten- und serviceübergreifend als „Informationssicherheitsvorfall“ gilt.
- Menschen: – benannte Rollen, die über Zeitzonen und mehrere Mandanten hinweg funktionieren, mit Verantwortlichen für Erkennung, Priorisierung, Eindämmung, Kommunikation, Wiederherstellung und Überprüfung.
- Ausführung: – ein Lebenszyklus, dem Ingenieure unter Druck folgen können, ohne in SharePoint suchen zu müssen; in der Regel ein einfacher Ablauf von Erkennung → Triage → Eindämmung → Wiederherstellung → Überprüfung.
- Beweis: – ein Aufzeichnungssystem, das alles miteinander verbindet und aufzeigt, wie sich reale Ereignisse durch diesen Lebenszyklus entwickelt haben.
Wenn ein Wirtschaftsprüfer oder ein wichtiger Kunde Ihr Team bittet, den letzten schwerwiegenden Vorfall bei einem wichtigen Mieter zu rekapitulieren, sollten Sie dazu in der Lage sein:
- Öffnen Sie in Ihrem ITSM-Tool einen einzelnen Vorfalldatensatz für diesen Mandanten.
- Zeitstempel, Statusänderungen, Schweregrad und zugewiesene Rollen anzeigen.
- Verweisen Sie auf Richtlinienklauseln, RACI-Matrizen und die Ausrichtung an A.5.24.
- Zeigen Sie, was sich im Anschluss geändert hat – Korrekturmaßnahmen, Aktualisierungen des Playbooks, Schulungen oder Vertragsänderungen.
Ein gut organisiertes Vorfallmanagement wirkt von außen betrachtet langweilig – weil die Überraschungen bereits von vornherein ausgeschlossen wurden.
Wenn Sie Ihre Richtlinien für Vorfallsmanagement, Verfahren, Rollen und Vorfallsaufzeichnungen gemeinsam in ISMS.online verwalten, können Sie zeigen, dass A.5.24 fester Bestandteil Ihres ISMS oder Annex L IMS ist und nicht nur ein separates Dokument darstellt, das Sie vor einem externen Audit hervorholen.
Wie sollte ein MSP die Verantwortlichkeiten für Vorfälle mit jedem Kunden gemäß A.5.24 strukturieren?
Gemäß A.5.24 wird von Ihnen erwartet, dass Sie die Verantwortlichkeiten im Zusammenhang mit Vorfällen als solche behandeln. entworfenes, mieterbasiertes Shared-ModellEs handelt sich nicht um eine vage Annahme, die in E-Mail-Verläufen versteckt ist. Prüfer und Unternehmenskunden achten darauf, ob Sie festgelegt und dokumentiert haben, wer in jeder Phase eines Vorfalls welche Aufgaben übernimmt und dass beide Seiten diese Aufteilung anerkennen.
Wie lässt sich ein klares Modell geteilter Verantwortung entwerfen?
Eine praktische Methode, die in den meisten MSP-Umgebungen funktioniert, ist:
- Beginnen Sie mit einer Standard-RACI-Matrix: das Ihrem normalen Vorfallablauf entspricht: Erkennung, Priorisierung, Eindämmung, Beseitigung, Wiederherstellung, Benachrichtigung, Kommunikation und Überprüfung.
- Sinnvolle Standardeinstellungen festlegen: zum Beispiel für Ihre Managed Services:
- Ihr Managed Service Provider (MSP): verantwortlich für die Erkennung und Eindämmung von Bedrohungen innerhalb der verwalteten Plattformen und Dienste.
- Der Kunde: verantwortlich für behördliche Meldungen, Kundenkommunikation und Geschäftsentscheidungen, die sich auf seinen eigenen Betrieb auswirken.
- Gemeinsam: Bereitstellung von Beweismitteln, Vereinbarung von störenden Maßnahmen, Definition dessen, was „wesentlich“ oder „meldepflichtig“ ist.
- Anpassung nach Mieter: statt das Rad neu zu erfinden:
- In risikoreicheren oder regulierten Sektoren (Finanzwesen, Gesundheitswesen, öffentlicher Sektor) sind möglicherweise schnellere Meldepflichten und mehr gemeinsame Entscheidungen erforderlich.
- Anspruchsvolle interne Sicherheitsteams wünschen sich möglicherweise mehr Kontrolle; kleinere Kunden erwarten unter Umständen, dass Sie fast alles steuern.
Diese RACI-Matrizen sollten dort abgelegt werden, wo die Teams sie auch tatsächlich finden und pflegen – typischerweise innerhalb Ihres ISMS oder IMS, verknüpft mit A.5.24, Lieferantenkontrollen wie A.5.19 und den entsprechenden Leistungsbeschreibungen.
Wie lassen sich geteilte Verantwortlichkeiten in realen Krisensituationen sichtbar machen?
Eine geplante Aufteilung hilft nur dann, wenn sie den Anschein erweckt in den Werkzeugen und Artefakten, die Menschen unter Druck berühren:
- Verträge und SLAs: Beachten Sie das gemeinsame Vorfallmodell und legen Sie Erwartungen hinsichtlich Erkennungs-, Benachrichtigungs- und Reaktionszeiten fest.
- Ticketvorlagen: Dazu gehören Felder wie „Kundenbetreuer für Vorfälle“, „Betreuer für behördliche Meldungen“, „Genehmiger für störende Maßnahmen“ und „Kommunikationsverantwortlicher“.
- Spielbücher: Nennen Sie, wer welche Entscheidung auslöst, wer mit welcher Interessengruppe spricht und welche Genehmigungen in jedem Schritt erforderlich sind.
Wenn Sie nachweisen können, dass das gleiche gemeinsame Design in Verträgen, RACI-Matrizen, Ticketfeldern, Playbooks und einem aktuellen mandantenspezifischen Vorfallbericht konsistent erscheint, erleichtern Sie es Prüfern und großen Käufern, A.5.24 zu vertrauen – und es Ihren Teams erheblich, es bei Hunderten von Kunden zu befolgen.
Welche Incident-Playbooks und Runbooks benötigt ein MSP tatsächlich für A.5.24?
A.5.24 belohnt kein aufgeblähtes Wiki, das um 2 Uhr nachts niemand öffnet. Es erwartet ein schlanker Satz von Spielbüchern und Laufbüchern die Ihre wahrscheinlichsten Bedrohungen abdecken und auf die von Ihnen tatsächlich betriebenen Dienste sowie die von Ihrem SOC und Ihren Ingenieuren tatsächlich verwendeten Tools abgestimmt sind.
Die meisten Managed Service Provider (MSPs) erhalten eine umfassende Abdeckung mit 4–7 gut durchdachten Playbooks, die auf ihre verwalteten Umgebungen zugeschnitten sind, zum Beispiel:
- Ransomware oder zerstörerische Malware: auf verwalteten Endpunkten oder Servern.
- Kompromittierung geschäftlicher E-Mails: – Kontoübernahmen, MFA-Müdigkeit, riskante Weiterleitungsregeln.
- Kompromittierung eines privilegierten Kontos: – Administratoren, Servicekonten, Notfallidentitäten.
- Verdacht auf Datenexfiltration: aus einer verwalteten Cloud- oder On-Premise-Umgebung.
- Vorfall auf einer Mandantenplattform: – wenn ein gängiges Tool oder ein Dienst nicht ordnungsgemäß funktioniert und die Sicherheit möglicherweise nicht die Ursache ist.
- Kompromisse bei SaaS-Lösungen von Drittanbietern: das betrifft mehrere Mandanten über Ihre verwaltete Plattform.
Jedes Strategiebuch sollte dieselben grundlegenden Fragen beantworten:
- Was löst dieses Szenario typischerweise aus?
- Wer führt und wer unterstützt – innerhalb Ihrer Organisation und auf Kundenseite?
- Wie klassifizieren Sie den Schweregrad und wann eskalieren Sie?
- Wann und wie binden Sie die Mandanten-, Rechts- und Datenschutzbeauftragten ein?
- Welche Genehmigungen sind vor einschneidenden Maßnahmen wie der Isolierung oder dem Löschen von Daten erforderlich?
- Welche Informationen müssen in der Ereignisdokumentation in jeder Phase erfasst werden, um die Anforderungen von A.5.24 und den angrenzenden Bestimmungen zu erfüllen?
Wie sollten Sie Runbooks für bestimmte Tools strukturieren und pflegen?
Playbooks beschreiben Wer macht was und wann? auf Szenarioebene; Runbooks erfassen wie um auf jeder Plattform bestimmte Aktionen durchzuführen:
- Isolierung eines Geräts in Ihrer EDR- oder Endpoint-Management-Lösung.
- Sperren und Zurücksetzen von Identitäten bei großen Cloud-Anbietern.
- Erfassung von Protokoll- und Telemetrie-Snapshots von SIEM, Firewall oder Proxy.
- Überprüfung und Bereinigung verdächtiger Postfachregeln und Weiterleitungsziele.
Richtlinien, Spielzüge und Betriebshandbücher aufbewahren getrennt, aber vernetzt ISMS.online bietet klare Vorteile:
- Die Governance (die Formulierung von Richtlinien und Kontrollen) bleibt stabil, während sich die Technologie ändert.
- Ingenieure wissen genau, wo sie nach der Frage „Was ist der richtige nächste Schritt?“ suchen müssen, im Gegensatz zu der Frage „Welchen Befehl oder Konsolenknopf soll ich verwenden?“.
- Sie können den Prüfern eine lückenlose Kette vom Richtlinientext A.5.24 → Szenario-Playbook → plattformspezifischem Runbook → realen Incident-Tickets zeigen, in denen diese Artefakte verwendet wurden.
Wenn Ihr aktuelles Repository unübersichtlich oder veraltet ist, ist der Aufbau einer fokussierten Bibliothek, die Ihren häufigsten Vorfällen entspricht, für A.5.24 – und für Ihre Kunden – sinnvoller als eine lange Liste selten genutzter Dokumente.
Wie kann ein Managed Service Provider (MSP) A.5.24 in Ticketing-, Monitoring- und SOC-Abläufe integrieren, ohne die Techniker auszubremsen?
Sie machen A.5.24 zu einem Teil der normalen Arbeit, indem Sie Behandeln Sie Ihren ITSM-Vorfallsbericht als einzige Quelle der Wahrheit und die dazugehörigen Überwachungs- und Kollaborationstools. Das Ereignisprotokoll liefert alle Details; Konsolen, Dashboards und Chat erfassen die technischen Feinheiten dieser Ereignisse.
Was sollte ein gemäß A.5.24 erstellter Vorfallbericht enthalten?
Definieren Sie in Ihrem ITSM- oder Service-Desk-Tool einen dedizierten „Informationssicherheitsvorfall“-Typ, der Ihren dokumentierten Prozess widerspiegelt:
- Kernbereiche: für Mieter, Umfeld, betroffene Dienste, Schweregrad, Datensensibilität und potenzielle regulatorische Relevanz.
- Zustandsfluss: das Ihrem Verfahren entspricht (zum Beispiel: Neu → Triage → Untersuchung → Eindämmung → Wiederherstellung → Überprüfung → Abgeschlossen).
- Pflichtfelder und Checklisten: bei wichtigen Übergängen:
- Wurde vor dem Abschluss eine Überprüfung durchgeführt?
- Wurde bei dem Vorfall, der personenbezogene Daten betraf, der Datenschutz konsultiert?
- Wurden die vereinbarten Benachrichtigungsfristen eingehalten?
- Zusammenfassungen und Links: für:
- Wichtige Maßnahmen und Genehmigungen, wer was wann genehmigt hat.
- Kundenkommunikation, einschließlich Kanäle und Zeiten.
- Zugrunde liegende Warnmeldungen, Fälle oder Protokollquellen, die an anderer Stelle gespeichert sind.
Sicherheitsspezifische Kategorien und Tags ermöglichen es Ihnen, Informationssicherheitsvorfälle von allgemeinen Ausfällen zu unterscheiden. Dadurch wird es deutlich einfacher, über Trends zu berichten, gegenüber Auditoren die Bereitschaft nachzuweisen und Verbesserungen in Ihrem Informationssicherheitsmanagementsystem voranzutreiben.
Wie lassen sich Monitoring- und SOC-Tools in dieses Design integrieren?
Sobald Sie einen klaren Datensatztyp und -ablauf festgelegt haben, entscheiden Sie Welche Warnmeldungen sollten Vorfallsaufzeichnungen erstellen oder anreichern?, Wie:
- Hochriskante oder hochzuverlässige Erkennungen durch SIEM-, EDR- oder Cloud-Sicherheitstools führen automatisch zur Erstellung vorausgefüllter Vorfallstickets.
- Signale mit niedrigerem Schweregrad werden zur Überprüfung durch Analysten zusammengefasst und können bei Erfüllung bestimmter Kriterien leicht zu einem „Vorfall“ hochgestuft werden.
- Integrationen, die Kontextinformationen – betroffene Benutzer oder Geräte, korrelierte Ereignisse, Beweismittel – in den Masterdatensatz zurückführen, anstatt alles im Chat oder in einzelnen Konsolen gefangen zu lassen.
Wenn Ihr Team während der Live-Bearbeitung Chat oder virtuelle Brücken nutzt, sollte stets eine kurze Zusammenfassung der Entscheidungen und Genehmigungen in den Vorfallbericht aufgenommen werden, damit Sie die Kontrolle nachweisen können, wenn jemand Monate später den Fall überprüft.
Wenn Sie diesen Ablauf einmal entwerfen, ihn mit A.5.24 und den zugehörigen Steuerelementen in ISMS.online verbinden und Ihr SOC und Ihren Service Desk darin schulen, den Vorfalldatensatz als „Ort, an dem die Story zu finden ist“ zu behandeln, erfüllen Sie die Kontrollanforderung, ohne den Technikern zusätzlichen bürokratischen Aufwand zu verursachen.
Welche Nachweise sollte ein MSP aufbewahren, um seine Einsatzbereitschaft für A.5.24 überzeugend zu belegen?
A.5.24 wird üblicherweise getestet durch Aktuelle reale VorfälleEs handelt sich nicht um theoretische Checklisten. Wirtschaftsprüfer, Versicherer und Großkunden wählen in der Regel ein oder zwei Fälle aus und bitten Sie, darzulegen, wie diese sich im Vergleich zu Ihrem dokumentierten Vorgehen bei Vorfällen entwickelt haben.
Wie sieht ein überzeugender Beweissatz für jeden einzelnen Vorfall aus?
Für jeden wesentlichen Vorfall – insbesondere solche, die sensible Daten betreffen oder größere Störungen verursachen – sollten Sie Folgendes vorlegen können:
- Hauptereignisbericht:
- Zeitstempel, Zustandsänderungen und Schweregrad.
- Zugewiesene Rollen und Übergaben zwischen Schichten oder Teams.
- Kurze Schilderung des Geschehens und der Gründe für die getroffenen Entscheidungen.
- Verknüpfte technische Artefakte:
- SIEM- oder EDR-Warnmeldungen, Fall-IDs und Zusammenfassungsexporte.
- Relevante Protokollauszüge oder forensische Notizen oder Verweise darauf, wo diese Daten sicher aufbewahrt werden.
- Kundenkontakthistorie:
- Wer wurde wann und über welchen Kanal informiert?
- Wie Sie die vertraglich vereinbarten Benachrichtigungsfristen eingehalten oder übertroffen haben.
- Sämtliche Folgeberichte oder Besprechungsnotizen, die dem Kunden zur Verfügung gestellt wurden.
- Ergebnisse der Überprüfung und Verbesserung:
- Wahrscheinliche Grundursache, begünstigende Faktoren und Restrisiko.
- Konkrete Korrektur- und Verbesserungsmaßnahmen mit Verantwortlichen und Fälligkeitsterminen.
- Als Folge davon wurden Aktualisierungen an Playbooks, Verträgen, Vorlagen oder RACI-Matrizen vorgenommen.
Für die meisten Managed Service Provider (MSPs) liegt die Herausforderung eher in der Konsistenz als im Datenvolumen. Einige wenige, gut gewählte Anhänge und Referenzen, die den Sachverhalt klar untermauern, sind weitaus wertvoller als Dutzende unstrukturierter Protokolldateien.
Wie kann man vermeiden, in der Beweislage bei einer Vielzahl von Mietern und Dienstleistungen zu ertrinken?
Sie halten die Beweislage überschaubar, indem Sie Standardisierung von Mustern nach Kundensegment:
- Definieren Sie, auf welche Protokollquellen und Überwachungsausgaben Sie sich für die verschiedenen Diensttypen (verwalteter Endpunkt, Cloud-Tenancy, Netzwerk) verlassen.
- Standardisieren Sie, wie diese Artefakte in Vorfallsberichten referenziert oder angehängt werden.
- Legen Sie Aufbewahrungsfristen und Zugriffskontrollen fest, die den rechtlichen und vertraglichen Verpflichtungen für jedes Segment entsprechen.
Regelmäßige Überprüfungen der Beweislage – bei denen man einen abgeschlossenen Vorfall zufällig auswählt und fragt: „Würde ein Außenstehender dies als vollständig und glaubwürdig einstufen?“ – bringen oft kleine Designanpassungen mit großen Vorteilen ans Licht.
Wenn Sie Ihr Vorfallsnachweismodell, die zugehörigen Richtlinien und die A.5.24-Zuordnungen gemeinsam in ISMS.online verwalten, können Sie Prüfern und strategischen Kunden zeigen, dass die Bereitschaft konsistent und mieterorientiert ist und nicht erst mühsam wiederhergestellt werden muss, wenn ein Fragebogen oder eine Forderung eintrifft.
Wie können Schulungen und Übungen einem MSP dabei helfen, von der Einhaltung der Vorschriften auf dem Papier zur tatsächlichen Umsetzung gemäß A.5.24 zu gelangen?
Training und Übungen sind der Ort, an dem A.5.24 wandelt sich von Dokumentation zu ReflexenDie Kontrollmaßnahmen beziehen sich auf Planung und Vorbereitung; für einen Managed Service Provider (MSP) bedeutet das, dass Teams in verschiedenen Funktionen realistische Vorfälle mit den tatsächlichen Tools, Aufzeichnungen und Playbooks geübt haben und nicht nur einmal im Jahr eine Richtlinie lesen.
Welche Schulungsansätze eignen sich am besten für MSP-Teams?
Kurze, rollenspezifische Sitzungen sind fast immer besser als lange, allgemeine Präsentationen:
- Analysten und Ingenieure: Führen Sie simulierte Warnmeldungen in Ihrem Überwachungssystem durch, erstellen und aktualisieren Sie Vorfallberichte und folgen Sie den Playbooks Schritt für Schritt, bis sich das Muster natürlich anfühlt.
- Account Manager und Serviceverantwortliche: Üben Sie zeitkritische Kundenaktualisierungen während eines realistischen Ausfalls oder einer Beeinträchtigung, indem Sie die Informationen verwenden, die die Kunden in Tickets und Dashboards sehen würden.
- Kollegen aus den Bereichen Recht, Datenschutz und Compliance: Üben Sie Benachrichtigungsentscheidungen mit unvollständigen Informationen, basierend auf dem, was tatsächlich in Ihren Vorfallsaufzeichnungen und Protokollen erfasst ist.
- Leitende Führungskräfte: Üben Sie, wann man Brücken schlägt, wie man störende Eindämmungsmaßnahmen schnell genehmigt und wie man interne und externe Botschaften aufeinander abstimmt.
Diese Schulungen schaffen Vertrauen, dass die Beteiligten im Falle eines schwerwiegenden Ereignisses, das einen wichtigen Mieter betrifft, genau wissen, wo sie suchen und was zu tun ist, anstatt Zeit mit der Diskussion grundlegender Schritte zu verschwenden.
Wie gestaltet man ein Übungsprogramm, das die Anforderungen von A.5.24 erfüllt, ohne die Teams zu überlasten?
Sie benötigen kein aufwendiges Planspielprogramm; ein einfacher, übersichtlicher Kalender genügt oft:
- Interne Simulationen sollten mindestens einmal jährlich für Ihre wichtigsten Szenarien durchgeführt werden (z. B. Ransomware, Kompromittierung von Geschäfts-E-Mails, größerer Plattformausfall).
- Gelegentliche gemeinsame Übungen mit strategisch wichtigen oder regulierten Kunden, wodurch RACI-Matrizen, Eskalationswege und Kommunikationsmuster für beide Seiten real werden.
- Kurzberichte nach jeder Übung, die Folgendes festhielten:
- Was gut funktioniert hat und verstärkt werden sollte.
- Wo Rollen, Informationen oder Werkzeuge verwirrend oder langsam waren.
- Eine kleine Anzahl konkreter Verbesserungen an RACI-Matrizen, Playbooks, Ticketvorlagen, Protokollierung oder Verträgen.
Diese Verbesserungsmaßnahmen sollten in Ihre üblichen ISO 27001-Mechanismen – Risikobehandlungspläne, Korrekturmaßnahmenprotokolle, Managementbewertungen – einfließen, damit Sie einen vollständigen Kreislauf vom Entwurf über die Prüfung bis zur Verbesserung nachweisen können.
Wenn Sie diese Schulungen in ISMS.online zusammen mit Ihrer A.5.24-Richtlinie, Ihren Handlungsanweisungen und Vorfallsberichten planen, durchführen und nachverfolgen, vermitteln Sie Prüfern, Aufsichtsbehörden und Unternehmenskunden ein klares Bild: Die Vorbereitung auf Sicherheitsvorfälle wird als Teil Ihres Informationssicherheitsmanagementsystems konzipiert, geübt und gestärkt und nicht dem Zufall überlassen. Genau diese Position möchte ein moderner Managed Service Provider im Falle eines schwerwiegenden Vorfalls oder eines anspruchsvollen Kunden einnehmen.
