Warum Ad-hoc-Softwareinstallationen heute ein existenzielles Risiko für Managed Service Provider darstellen
Ad-hoc-Softwareinstallationen auf Kundenproduktionssystemen bergen für Managed Service Provider (MSPs) erhebliche kommerzielle, vertragliche und regulatorische Risiken, selbst wenn kleine technische Entscheidungen getroffen werden. Wenn Techniker informelle Änderungen in laufenden Umgebungen vornehmen, verlieren Sie die Kontrolle darüber, was wo installiert wird. Die Auswirkungen eines Fehlers werden dadurch deutlich verstärkt, und eine einzelne „Schnelllösung“ kann sich auf viele Mandanten auswirken, Ausfälle oder Störungen verursachen und schwierige Fragen von Kunden, Aufsichtsbehörden und Versicherern aufwerfen. Wenn Sie die Installation als informelle Aktivität statt als kontrollierte Änderung behandeln, wird es zudem erheblich schwieriger, die gebotene Sorgfalt nachzuweisen und Ihr Unternehmen im Schadensfall zu schützen. Aus diesem Grund betrachten viele MSPs die Installationsdisziplin heute als integralen Bestandteil ihrer Unternehmensführung und nicht mehr nur als rein technische Angelegenheit.
Informelle Änderungen sind im Vorfeld günstig, werden aber teuer, wenn etwas kaputt geht.
Die moderne MSP-Angriffsfläche
Moderne Managed Service Provider (MSPs) verwalten hochvernetzte Multi-Tenant-Umgebungen, in denen ein einzelner Techniker mit einer einzigen Aktion Dutzende Kundensysteme verändern kann. Diese Reichweite ist ein großer Vorteil, solange sie kontrolliert wird, und gefährlich, wenn sie unkontrolliert bleibt. Dieselben Fernwartungstools, mit denen sich Probleme schnell beheben lassen, ermöglichen es auch, Fehler oder Schadsoftware innerhalb von Minuten auf viele Kunden zu verbreiten. Wird Software daher informell auf laufenden Systemen installiert, riskiert man inkonsistente Konfigurationen, fehlerhafte Agenten und weitreichendere Probleme im Fehlerfall.
Rund 41 % der Befragten in der ISMS.online-Umfrage „State of Information Security 2025“ nannten die digitale Resilienz als große Herausforderung und unterstrichen damit, wie stark der Druck auf Managed Service Provider (MSPs) ist, operative Veränderungen unter Kontrolle zu halten.
Eine unstrukturierte Softwareinstallation war sinnvoll, als man nur wenige lokale Server für einige wenige Kunden verwaltete. Heute kann derselbe Techniker mit wenigen Klicks in Fernverwaltungstools ein Update für viele Mandanten bereitstellen, sodass jede Abkürzung deutlich riskanter ist als früher.
Eine einzige „Schnellinstallation“ kann nun Folgendes ermöglichen:
- Einschleusen anfälliger oder bösartiger Komponenten in mehrere Kundenumgebungen gleichzeitig.
- Standardmäßige Härtungsrichtlinien werden umgangen, wodurch inkonsistente Konfigurationen entstehen, die sich nicht ohne Weiteres reproduzieren oder rückgängig machen lassen.
- Unterbrechen Sie Überwachungs-, Backup- oder Sicherheitsagenten, von denen Ihre Kunden annehmen, dass sie sie stets schützen.
Unabhängige Bedrohungsberichte, darunter Analysen des missbräuchlichen Einsatzes von Fernverwaltungstools durch Organisationen wie Shadowserver, zeigen regelmäßig, dass Angreifer legitime Fernzugriffstools und Verwaltungsagenten missbrauchen, anstatt eigene Schadsoftware zu entwickeln. Können Sie nicht nachweisen, wer was, wo und mit welcher Genehmigung installiert hat, wird es deutlich schwieriger, nach einem Vorfall die gebotene Sorgfalt nachzuweisen und Prüfer von der Wirksamkeit Ihrer Kontrollmaßnahmen zu überzeugen.
Geschäftliche und regulatorische Risiken, nicht nur IT-Rauschen
Für Managed Service Provider (MSPs) liegt der eigentliche Schaden durch informelle Installationen oft eher im kommerziellen und regulatorischen Bereich als in rein technischen Problemen. Ein Ausfall lässt sich beheben; die Folgefragen zu Governance, Verträgen und Haftung sind jedoch komplexer und langwieriger. Wenn ungeplante Änderungen schiefgehen, drohen SLA-Verletzungen, behördliche Überprüfung und Fragen zur Wirksamkeit grundlegender Governance-Strukturen. Daher werden Ad-hoc-Aktivitäten an Produktionssystemen zunehmend sowohl als Angelegenheit der Geschäftsführung als auch als operatives Problem betrachtet.
Für viele MSP-Gründer und Vendor-Manager liegt das eigentliche Problem nicht in der technischen Behebung, sondern in den Folgewirkungen auf das Geschäft. Ungeplante Änderungen, die zu Ausfällen oder Datenproblemen führen, können Folgendes bewirken:
Die Mehrheit der Organisationen in der ISMS.online-Umfrage 2025 gab an, im vergangenen Jahr von mindestens einem Sicherheitsvorfall bei einem Drittanbieter oder Lieferanten betroffen gewesen zu sein, was die Erwartungen an Managed Service Provider (MSPs) hinsichtlich eines disziplinierten Änderungsmanagements erhöht.
- Verfügbarkeits- oder Reaktionszeit-SLAs mit wichtigen Kunden im Falle von Sicherheitsvorfällen.
- Lösen Sie für Ihre Mandanten regulatorische Meldepflichten aus, insbesondere im Finanz-, Gesundheits- oder öffentlichen Sektor.
- Bei Cyberversicherern sollten Fragen aufgeworfen werden, ob grundlegende Änderungskontrollmechanismen vorhanden waren.
Aufsichtsbehörden und nationale Cybersicherheitsbehörden erwarten zunehmend von Anbietern kritischer Dienste und ihren wichtigsten Zulieferern ein diszipliniertes Änderungsmanagement für laufende Dienste. Leitlinien für die Cybersicherheit auf Vorstandsebene, beispielsweise vom britischen National Cyber Security Centre (NCSC) in seinen Materialien zu Resilienz und Diensten, stellen einen expliziten Zusammenhang zwischen operativer Resilienz und gut gesteuerten Änderungen her. Wenn Ihre Installationen keinem wiederholbaren, dokumentierten Prozess folgen, betrachten Führungskräfte und Regulierungsbehörden dies als Governance-Lücke und nicht als „IT-Problem“.
Aus eigenen Vorfällen lernen
Ein Blick zurück auf die eigenen Vorfälle ist oft der schnellste Weg, A.8.19 von der Theorie in die Praxis umzusetzen, denn wenn man Ausfälle und Beinahe-Unfälle überprüft und diejenigen kennzeichnet, die mit einer informellen Installation oder Aktualisierung begannen, tauchen in der Regel immer wieder dieselben Muster auf, die für Ingenieure, Manager und Vorstandsmitglieder kaum noch zu ignorieren sind.
Man benötigt keine globalen Sicherheitslückenstatistiken, um die Notwendigkeit von Veränderungen zu begründen. Eine einfache interne Retrospektive zeigt oft, wie häufig eine kleine Änderung den Anstoß zu größeren Problemen gab, wie zum Beispiel:
- Neustarts oder Versionskonflikte nach Updates außerhalb der Geschäftszeiten, die nie vollständig getestet wurden.
- Temporäre Hilfsprogramme wurden installiert, um bei der Fehlersuche zu helfen, wurden aber nie wieder entfernt.
- Nicht erfasste Änderungen, die die spätere Ursachenanalyse mühsam und langsam machten.
Genau diese Muster sind die Probleme, die ISO 27001:2022, Abschnitt A.8.19, adressieren soll. Er lenkt weg von einem persönlichkeitsbasierten Vertrauen in einige wenige leitende Ingenieure hin zu einem systembasierten Vertrauen in einen definierten, auditierbaren Prozess. Eine ISMS-Plattform wie ISMS.online kann Ihnen helfen, diese Erkenntnisse in Ihrem Informationssicherheitsmanagementsystem (ISMS) zu erfassen, sodass sie in klare Richtlinien, Risiken und Korrekturmaßnahmen umgesetzt werden, anstatt im individuellen Gedächtnis zu verschwinden.
KontaktWas ISO 27001 A.8.19 in operativen MSP-Umgebungen wirklich fordert
ISO 27001:2022 A.8.19 fordert, dass jede Softwareinstallation auf einem Betriebssystem eine kontrollierte, autorisierte und nachvollziehbare Änderung darstellt. Für einen Managed Service Provider (MSP) bedeutet dies, festzulegen, wer was auf welchen Systemen unter welchen Bedingungen installieren darf, und anschließend nachzuweisen, dass diese Regeln sowohl in der eigenen Umgebung als auch in der Umgebung der Kunden eingehalten wurden.
Der ISMS.online-Bericht „State of Information Security 2025“ stellt fest, dass Kunden zunehmend von ihren Lieferanten erwarten, dass diese sich an formalen Rahmenwerken wie ISO 27001, ISO 27701, DSGVO, Cyber Essentials, SOC 2 und neuen KI-Standards orientieren. Ihre A.8.19-Etage ist daher Teil eines viel umfassenderen Sicherheitskonzepts.
Vereinfacht gesagt, fordert A.8.19 Sie auf, sicherzustellen, dass Software auf Betriebssystemen kontrolliert und nachvollziehbar installiert, aktualisiert und entfernt wird. Diese Kontrolle dient dazu, unüberlegte Handlungen zu verhindern, die unnötige Risiken bergen, und sicherzustellen, dass Sie auf Nachfrage nachweisen können, was Sie getan haben, warum Sie es getan haben und wer es genehmigt hat.
Offizielle ISO-Materialien zu ISO/IEC 27001 bestätigen, dass der Normentext lizenzpflichtig ist. Daher darf der genaue Wortlaut nicht ohne Lizenz reproduziert werden. Zusammenfassungen für Anwender und offizielle Beschreibungen stimmen jedoch in der Kernaussage jeder Kontrollmaßnahme, einschließlich A.8.19, überein. Für operative Systeme (Produktionsserver, Endgeräte, Netzwerkgeräte, Cloud-Workloads und SaaS-Konfigurationen, die den täglichen Geschäftsbetrieb unterstützen) betonen die Auslegungen von A.8.19 durchgängig Folgendes:
- Die Installation, Aktualisierung und Deinstallation von Software sind geplante Aktivitäten, keine zufälligen Handlungen.
- Diese Arbeiten werden ausschließlich von autorisiertem Fachpersonal oder automatisierten Anlagen durchgeführt.
- Die Software selbst ist legitim, geprüft und auf Sicherheitsrisiken hin untersucht.
- Die Installationen erfolgen nach dokumentierten Verfahren, einschließlich Tests, wo dies angebracht ist.
- Die Aufzeichnungen zeigen, was, von wem, wann, wo und mit welcher Genehmigung installiert wurde.
Für einen Managed Service Provider (MSP) befinden sich die „operativen Systeme“ sowohl in der eigenen Umgebung (Tools, gemeinsam genutzte Plattformen) als auch in den IT-Systemen der einzelnen Kunden. Ihre A.8.19-Architektur muss sich daher über mehrere Mandanten erstrecken und nicht nur über Ihre interne Infrastruktur.
Wie A.8.19 mit dem Rest Ihres ISMS verbunden ist
A.8.19 ist nur dann wirklich wirksam, wenn es in Ihr bestehendes ISMS integriert ist und nicht als eigenständige Richtlinie formuliert wird. Die Softwareinstallation sollte die sichtbare Spitze eines umfassenderen Systems darstellen, das Anlagen, Zugriffe, Änderungen und Lieferanten abdeckt.
Die Steuerung knüpft auf natürliche Weise an mehrere andere Anforderungen der ISO 27001:2022 an, darunter:
- Änderungsmanagement: (A.8.32): die übergeordnete Anforderung, dass Änderungen an Informationsverarbeitungsanlagen formalen Änderungsverfahren folgen.
- Konfigurations- und Anlagenverwaltung: zu wissen, welche Systeme existieren und welche Software darauf zugelassen ist.
- Zugangskontrolle: um sicherzustellen, dass nur die berechtigten Personen Installationen oder Bereitstellungen auf Live-Systemen auslösen können.
- Lieferanten- und Cloud-Steuerung: Erkennen, wo Updates von Drittanbietern oder Apps aus Marktplätzen Ihre Kunden beeinträchtigen.
Bei der Konzeption Ihrer Implementierung hilft eine einfache Visualisierung wie diese den Ingenieuren und Prüfern zu erkennen, dass die Softwareinstallation nur ein Punkt in einer gut geregelten Kette ist und keine isolierte Aufgabe.
A.8.19 als Risikobehandlung, nicht als bürokratische Übung
Mit A.8.19 erzielen Sie bessere Ergebnisse, wenn Sie es als Werkzeug zur Reduzierung konkreter Risiken und nicht als bloße Pflichterfüllung betrachten. Je klarer Sie die Kontrollmaßnahme mit realen Problemen wie Lieferkettenunterbrechungen, ungeplanten Ausfallzeiten und Datenproblemen verknüpfen können, desto leichter gewinnen Sie die Unterstützung von Ingenieuren und Entscheidungsträgern.
Der Kontrolltext ist bewusst allgemein gehalten. Seine wahre Stärke entfaltet sich, wenn Sie A.8.19 mit Risiken aus Ihrem eigenen Risikoregister verknüpfen: beispielsweise die Kompromittierung von Fernverwaltungstools, ungeplante Ausfallzeiten durch fehlgeschlagene Updates oder Datenprobleme durch falsch konfigurierte Agenten. Indem Sie die Kontrollmaßnahme als Mittel zur Reduzierung dieser Risiken darstellen, erleichtern Sie die Kommunikation erheblich.
- Statt „Wir müssen dieses Formular ausfüllen, weil es die ISO vorschreibt“, könnten Sie sagen: „Wir verwenden dieses Änderungsprotokoll, um Ihre Betriebszeit zu schützen und nachzuweisen, was wir getan haben, falls etwas schiefgeht.“
- Statt „Ingenieure dürfen Probleme nicht mehr schnell beheben“ könnte man sagen: „So verhindern wir, dass schnelle Lösungen zu langen Ausfällen führen.“
Für Managed Service Provider (MSPs), die von der ISO 27001-Version 2013 auf die Version 2022 umsteigen, ist dies der richtige Ort, um die Änderungen zu erläutern. Das Grundprinzip der kontrollierten Softwareinstallation ist nicht neu, doch unabhängige Zusammenfassungen des Updates von 2022 heben hervor, dass die neu strukturierte Anlage A die Erwartungen hinsichtlich Autorisierung, Tests und Betriebsumfang für operative Kontrollen wie A.8.19 verdeutlicht und somit die Kommunikation dieser Erwartungen in verständlicher Geschäftssprache erleichtert.
Diese Informationen sind allgemeiner Natur und stellen keine Rechtsberatung dar. Sie ersetzen auch nicht die Zusammenarbeit mit einem qualifizierten Berater oder einer Zertifizierungsstelle.
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.
Vom einfachen Ticketing bis hin zu einem geregelten A.8.19-Betriebsmodell für Managed Service Provider (MSPs)
Ein geregeltes A.8.19-Betriebsmodell wandelt das bisherige Vorgehen („Ticket erstellen und hoffen, dass alles gut geht“) in ein vorhersehbares System um, das von Ihren Teams, Auditoren und Kunden gleichermaßen verstanden wird. Anstatt jede Installation als Einzelfall zu behandeln, definieren Sie, wie Softwareänderungen von der Idee bis zur erfolgreichen Implementierung bei allen Kunden umgesetzt werden und machen diesen Prozess transparent, wiederholbar und messbar.
Definition des Betriebsmodells von Anfang bis Ende
Es ist einfacher, A.8.19 zu entwerfen und zu verbessern, wenn man die Softwareinstallation als ein kleines Betriebsmodell und nicht als einen einzelnen Vorgang betrachtet. Dieses Modell beschreibt, wie Anfragen eingehen, wie Risiken bewertet werden, wer die Genehmigung erteilt, wie die Bereitstellung erfolgt und wie aus den Ergebnissen gelernt wird. Es legt mindestens die wichtigsten Phasen fest, die es abdecken sollte.
Eine hilfreiche Herangehensweise an A.8.19 ist die Betrachtung als kleines Betriebsmodell innerhalb Ihres umfassenderen ISMS. Es sollte mindestens Folgendes umfassen:
- Richtlinien und Geltungsbereich: Eine klare Aussage, dass alle Softwareinstallationen auf Betriebssystemen (Ihren eigenen und denen Ihrer Kunden) kontrollierten Prozessen folgen müssen, wobei alle expliziten Ausnahmen definiert werden.
- Anfrageeingang: wie der Bedarf an einer Softwareinstallation entsteht (Störung, Serviceanfrage, interne Verbesserung, Empfehlung des Anbieters).
- Risiko- und Folgenabschätzung: wie Sie die Auswirkungen auf das Geschäft und die Sicherheit der betroffenen Kunden und Systeme beurteilen.
- Die Genehmigung: Wer genehmigt welche Arten von Änderungen und unter welchen Bedingungen?
- Einsatz: wie die Änderung tatsächlich durchgeführt wird (RMM-Job, Skript, manuelle Installation, CI/CD-Pipeline).
- Überprüfung und Begutachtung: Wie man den Erfolg bestätigt, nach Nebenwirkungen sucht und aus Problemen lernt.
- Datenerfassung und Kennzahlen: wie der gesamte Prozess dokumentiert und vermessen wird.
Die meisten Managed Service Provider (MSPs) haben bereits Teile davon implementiert. Ziel ist es, die Zusammenhänge zu verknüpfen, Widersprüche zwischen den Teams aufzulösen und die Struktur im gesamten Unternehmen sichtbar zu machen.
Wenn Sie einen zentralen Ort benötigen, um dieses Betriebsmodell zusammen mit Ihren Risiken und Richtlinien zu beschreiben, kann eine ISMS-Plattform wie ISMS.online als Governance-Ebene über Ihren Service-Tools fungieren, während Sie weiterhin mit vertrauten Tickets und Konsolen arbeiten.
Risikobasierte Änderungskategorien für Installationen
Risikobasierte Kategorien helfen Ihnen, Installationen nicht gleich zu behandeln und gleichzeitig die Kontrolle zu behalten. Durch die Definition von Änderungen mit niedrigem, mittlerem und hohem Risiko können Sie den Umfang von Bewertung, Tests und Genehmigung an die potenziellen Auswirkungen anpassen und wichtige Aufgaben transparent gestalten, ohne Routineaufgaben in Bürokratie zu ersticken.
Wenn Sie jede Softwareinstallation als gleich riskant einstufen, wird Ihr Prozess entweder unerträglich langsam oder stillschweigend umgangen. Ein nachhaltigerer Ansatz besteht darin, einfache Risikokategorien einzuführen:
- Geringes Risiko: Wiederkehrende, gut verstandene Änderungen wie regelmäßige Agentenaktualisierungen oder nicht kritische Hilfsprogramme auf nicht sensiblen Geräten.
- Mittleres Risiko: Änderungen an Geschäftsanwendungen, unterstützenden Diensten oder Kernwerkzeugen, die einen einzelnen Kunden oder eine einzelne Umgebung betreffen.
- Hohes Risiko: Änderungen, die viele Kunden betreffen, kritische gemeinsam genutzte Plattformen oder Systeme mit hohen Anforderungen an Vertraulichkeit oder Verfügbarkeit.
Für jede Ebene sollten klar definierte Erwartungen hinsichtlich Bewertung, Tests, Genehmigungen und Kommunikation bestehen. Beispielsweise könnte ein risikoreicher Rollout bei mehreren Kunden die Genehmigung durch das CAB oder die Geschäftsleitung, Tests in einer Nicht-Produktionsumgebung, ein dokumentiertes Wartungsfenster und einen Kommunikationsplan sowie einen expliziten Rollback-Plan erfordern.
Wie die nachstehende Tabelle zeigt, erleichtert die schriftliche Zuordnung der einzelnen Kategorien zu den Kontrollmaßnahmen die Erklärung und Überprüfung des Modells:
| Risikostufe | Typische Beispiele | Zusätzliche Erwartungen |
|---|---|---|
| Niedrig | Agenten- oder Tool-Updates auf nicht kritischen Systemen | Vorlageschritte, grundlegende Tests |
| Medium | Änderung einer Einzelclient-App oder eines Dienstes | Formale Genehmigung, gezielte Kommunikation |
| Hoch | Änderung einer Multi-Client- oder kritischen Plattform | CAB, vollständige Tests, Kommunikation, Rückrollplan |
Die Dokumentation dieser Erwartungen innerhalb Ihres ISMS und in Ihren internen Serviceverfahren hilft den Ingenieuren zu verstehen, wann sie schnell vorgehen können und wann sie langsamer arbeiten müssen.
Einbeziehung von Cloud-Anbietern in Ihr Modell
Cloud-Dienste und -Anbieter treiben heute viele Softwareänderungen voran, die Ihre Kunden betreffen. Daher muss A.8.19 auch SaaS-Konfigurationen, Marketplace-Apps und vom Anbieter bereitgestellte Updates abdecken. Wenn Sie sich nur auf lokale Installationen konzentrieren, entgehen Ihnen einige der wichtigsten Änderungen.
Rund 41 % der Organisationen gaben in der ISMS.online-Umfrage 2025 an, dass das Management von Drittparteirisiken und die Überwachung der Lieferantenkonformität eine ihrer größten Herausforderungen im Bereich der Informationssicherheit darstellen. Umso wichtiger ist es, lieferantenbedingte Änderungen als Teil Ihres A.8.19-Modells zu behandeln.
In einem modernen Managed Service Provider (MSP) handelt es sich bei vielen „Softwareinstallationen auf operativen Systemen“ nicht mehr um klassische On-Premises-Bereitstellungen. Dazu gehören die Aktivierung oder Aktualisierung von SaaS-Integrationen, die Installation oder das Upgrade von Agenten in Cloud-Workloads, die Anwendung von Add-ons aus dem Marketplace von Anbietern in Unified-Communications- oder CRM-Plattformen sowie die Übernahme automatischer Updates von Plattformanbietern.
Ihr Betriebsmodell A.8.19 sollte diese Szenarien explizit abdecken. Das bedeutet häufig:
- Erfassung derjenigen Lieferanten und Plattformen, die Änderungen in die Kundenumgebungen einspielen können.
- Definition der Art und Weise, wie Lieferantenempfehlungen in Ihren Veränderungsprozess einfließen.
- In Verträgen und RACI-Matrizen sollte klargestellt werden, welche Partei bestimmte Arten von Änderungen genehmigt und bestätigt.
Hier stimmen Sie Ihre A.8.19-Implementierung auch mit den Kundenerwartungen gemäß Vorschriften wie DORA oder branchenspezifischen Sicherheitsbestimmungen ab. Ein geregeltes Modell erfordert zwar Aufwand bei der Entwicklung, zahlt sich aber schnell durch weniger Überraschungen, klarere Verantwortlichkeiten und reibungslosere Audits aus.
Entwicklung eines praktischen, auf A.8.19 abgestimmten Änderungsworkflows für Ihre Ingenieure
Die Implementierung von A.8.19 ist nur dann erfolgreich, wenn Ihre Techniker sie in den von ihnen bereits genutzten Tools umsetzen können. Ein praktischer, wiederholbarer Workflow für Softwareinstallationen in Ihrer PSA- oder IT-Servicemanagement-Plattform verankert Richtlinien in der Praxis und liefert Ihnen konsistente Nachweise dafür, dass Änderungen bewertet, genehmigt, implementiert und überprüft werden.
Ein einheitlicher Standard-Workflow für Softwareinstallationen auf Live-Systemen bietet Entwicklern einen vorhersehbaren Ablauf, der client- und technologieübergreifend funktioniert. Anstatt jedes Mal neue Schritte zu entwickeln, folgen sie einem festen Schema, das von kleinen Änderungen bis hin zu großen Rollouts skalierbar ist und Ihre Kontrollen für Auditoren und Kunden transparent macht.
Definieren Sie zunächst einen einheitlichen Standard-Workflow für alle Softwareinstallationen auf Produktionssystemen. Ein typischer Ablauf sieht folgendermaßen aus, wobei jeder Schritt in Ihrem PSA- oder ITSM-Tool abgebildet ist.
Schritt 1 – Anfrage
Es wird ein Änderungsantrag oder ein Service-Ticket erstellt, in dem der Kunde, die betroffenen Systeme und der Grund für die Installation erfasst werden.
Schritt 2 – Bewertung
Das Risiko und die Auswirkungen werden unter Berücksichtigung aller Sicherheitsaspekte bewertet und ein angemessenes Risikoniveau wird zugewiesen.
Schritt 3 – Genehmigung
Die Anfrage wird anhand des Risikoniveaus, der Kundenrichtlinien und etwaiger regulatorischer Anforderungen an den zuständigen Genehmiger weitergeleitet.
Schritt 4 – Terminplanung
Bei Bedarf wird ein Wartungsfenster vereinbart, wobei die betroffenen Stakeholder und Serviceteams klar benachrichtigt werden.
Schritt 5 – Umsetzung
Die Installation wird gemäß einem dokumentierten Plan unter Verwendung kontrollierter Tools wie RMM, Skripten oder Pipelines durchgeführt.
Schritt 6 – Überprüfung
Funktionalität, Überwachung und Datensicherung werden überprüft; alle festgestellten Probleme werden protokolliert und durch Folgemaßnahmen behoben.
Schritt 7 – Abschluss
Das Ticket wird mit den Ergebnissen aktualisiert, und die gewonnenen Erkenntnisse werden für zukünftige Prozess- und Kontrollverbesserungen festgehalten.
Ihr PSA- oder ITSM-Tool sollte diesen Pfad für jede Änderung erzwingen, die als operative Softwareinstallation eingestuft wird, nicht nur für „große“ Projekte, damit die Techniker standardmäßig zum richtigen Verhalten angeleitet werden.
Je präziser Ihr Änderungsworkflow ist, desto einfacher lässt er sich anwenden und im Falle einer Prüfung nachweisen. Klare Definitionen, Pflichtfelder und wiederverwendbare Aufgabenvorlagen helfen Technikern, auch bei hohem Arbeitsaufkommen und der Betreuung mehrerer Kunden korrekt zu handeln.
Damit der Arbeitsablauf nicht zu einer bloßen Pflichterfüllung wird, muss er konkret und durchsetzbar gestaltet werden:
- Definieren Sie, was als Softwareinstallation auf einem Betriebssystem gilt, mit Beispielen und Ausnahmen.
- Konfigurieren Sie Pflichtfelder wie zum Beispiel:
- Kunden- und Anlagenkennungen.
- Softwarename und -version.
- Quelle (Anbieter, Repository, Marktplatz).
- Risikobewertung und kurze Begründung.
- Tests wurden durchgeführt.
- Plan zur Rücknahme der Funktion oder Erklärung, dass eine Rücknahme nicht erforderlich ist, mit Begründung.
- Erstellen Sie Aufgabenvorlagen für gängige Szenarien, wie zum Beispiel:
- Einführung neuer Geschäftsanwendungen.
- Einsatz von Sicherheitsagenten.
- Datenbank-Engine-Update.
- Upgrade des Fernüberwachungsagenten.
Wenn Felder und Aufgaben in die Ticketstruktur integriert sind, werden die Techniker durch die einzelnen Schritte geführt, ohne sich die Vorgehensweise merken zu müssen. Diese Anleitung liefert Ihnen außerdem konsistente Nachweise für spätere Überprüfungen oder Audits abgeschlossener Änderungen.
Ein kleines Pilotprojekt ist oft der beste Weg, um zu beweisen, dass Ihr Workflow in der Praxis funktioniert. Indem Sie ihn mit einigen wenigen Entwicklern oder Änderungsmanagern testen und anschließend echte Tickets überprüfen, können Sie Probleme beheben, bevor Sie ihn flächendeckend einführen. Sie können außerdem praktische Beispiele für Auditoren und Kunden erstellen und den Widerstand vermeiden, der häufig bei einer erzwungenen, vollständigen Einführung entsteht.
Kein Workflow ist von Anfang an perfekt, und eine erzwungene, abrupte Einführung kann Widerstand hervorrufen. Ein effektiverer Ansatz ist folgender:
- Testen Sie den Workflow mit einer Teilmenge von Kunden, Ingenieuren oder Änderungstypen.
- Überprüfen Sie nach einigen Wochen eine Stichprobe der abgeschlossenen Änderungen, um dies zu kontrollieren:
- Ob die Felder frei waren.
- Ob die Genehmigungen korrekt weitergeleitet wurden.
- Ob sich die Ingenieure blockiert oder unterstützt fühlten.
- Passen Sie Schritte, Formulierungen und Zuständigkeiten an, um Reibungsverluste zu minimieren und gleichzeitig die Kontrolle zu behalten.
Die Dokumentation des Workflows und seiner Entwicklung in Ihrem ISMS sowie dessen Ausrichtung an A.8.19 und A.8.32 helfen Auditoren, Ihre Compliance und kontinuierliche Verbesserung nachzuweisen. Eine ISMS-Plattform wie ISMS.online kann genutzt werden, um Workflow, Verantwortlichkeiten und Kontrollzuordnungen als Governance-Ebene über Ihren PSA- und RMM-Tools zu erfassen.
Wenn Sie sehen möchten, wie eine solche Governance-Ebene für Ihren eigenen Veränderungsprozess aussehen könnte, kann Ihnen ein Gespräch mit dem ISMS.online-Team konkrete Beispiele liefern, die auf MSP-Umgebungen zugeschnitten sind.
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.
Genehmigungen, Funktionstrennung und Kunden-RACI-Matrix, die tatsächlich funktionieren
A.8.19 verlangt mehr als nur einen technischen Prozess; es fordert klare Entscheidungen darüber, wer Softwareinstallationen auf operativen Systemen anfordern, genehmigen und implementieren darf. Für Managed Service Provider (MSPs) bedeutet dies, gemeinsam mit den Kunden eine RACI-Matrix zu erstellen, eine Aufgabentrennung zu definieren, die auch in kleinen Teams funktioniert, und die Einhaltung dieser Regeln schriftlich nachzuweisen.
Erstellung einer gemeinsamen MSP-Kunden-RACI
Eine gemeinsame RACI-Matrix klärt, wer bei Softwareinstallationen für Sie und Ihre Kunden welche Aufgaben übernimmt. Wenn beide Seiten die gleichen Erwartungen hinsichtlich Verantwortung, Rechenschaftspflicht, Beratung und Information haben, verlaufen Genehmigungsprozesse für Änderungen reibungsloser und Auditgespräche unkomplizierter.
Da Softwareinstallationen auf Kundensystemen erfolgen, teilen Sie sich die Verantwortung. Eine einfache, schriftliche RACI-Matrix (Verantwortlich, Rechenschaftspflichtig, Beratend, Informiert) für Softwareänderungen auf laufenden Systemen kann viele Missverständnisse vermeiden. Definieren Sie für jede Änderungskategorie (Standard, Normal, Notfall):
- Wer kann eine Änderung anfordern (MSP, Kunde, Anbieter als Auslöser)?
- Wer ist für die Implementierung verantwortlich (MSP-Team oder IT-Abteilung des Kunden)?
- Wer ist für die Genehmigung der Änderung verantwortlich (Systeminhaber des Kunden, Leiter der Servicebereitstellung des MSP)?
- Wer muss konsultiert werden (Sicherheit, Datenschutz, Anwendungsinhaber)?
- Wer muss informiert werden (Service Desk, Business Stakeholder)?
Integrieren Sie diese RACI-Matrix in Ihre ISMS-Dokumentation, Verträge und SLAs, damit sie für beide Seiten klar ist, und überprüfen Sie sie regelmäßig, da sich Dienstleistungen, Vorschriften und Kundenerwartungen weiterentwickeln.
Genehmigungsregeln und Aufgabentrennung in kleinen Teams
Auch kleinere Managed Service Provider (MSPs) können eine durchdachte Aufgabentrennung nachweisen, wenn sie klare Schwellenwerte und Ausnahmen festlegen. Prüfer achten typischerweise darauf, ob Änderungen mit höherem Risiko einer verstärkten unabhängigen Prüfung unterzogen werden, selbst wenn dieselbe Person im Notfall mehrere Aufgaben gleichzeitig übernehmen muss.
Im Idealfall sollte die Person, die eine Änderung genehmigt, niemals auch diejenige sein, die sie umsetzt. In kleinen Managed Service Providern (MSPs) oder im Nachtdienst ist dies jedoch nicht immer möglich. Sie können dennoch bewährte Verfahren anwenden, indem Sie:
- Definition von Schwellenwerten, ab denen eine strengere Trennung gilt, zum Beispiel:
- Änderungen mit hohem Risiko erfordern die Zustimmung einer Person, die nicht an der Umsetzung beteiligt ist.
- Änderungen mit mittlerem Risiko erfordern eine Peer-Review, auch wenn sie von derselben Person umgesetzt werden.
- Dokumentation akzeptabler Ausnahmen:
- Zum Beispiel Notfalländerungen außerhalb der regulären Arbeitszeiten, bei denen derselbe Ingenieur die Änderungen prüft, genehmigt und umsetzt, gefolgt von einer Überprüfung und Freigabe durch einen Manager am nächsten Tag.
- Sicherstellen, dass die Konten der Ingenieure und der privilegierte Zugriff kontrolliert werden, sodass nicht jeder jederzeit irgendetwas genehmigen kann.
Prüfer legen in der Regel weniger Wert auf Perfektion, sondern vielmehr darauf, ob ein durchdachter, risikobasierter Ansatz verfolgt und konsequent angewendet wird.
Einbeziehung regulierter Rollen und Überprüfungen
Bei der Betreuung von Mandanten in regulierten Branchen erfordern manche Änderungen eine zusätzliche Überwachung durch die Bereiche Datenschutz, Risikomanagement oder interne Revision. Die explizite Berücksichtigung dieser Rollen in Ihren Genehmigungsregeln hilft Ihnen, Überraschungen zu vermeiden und zeigt, dass Sie sowohl die Pflichten Ihrer Mandanten als auch Ihre eigenen operationellen Risiken verstehen.
Für Kunden in regulierten Branchen können bestimmte Systeme oder Datentypen eine zusätzliche Prüfung durch Funktionen wie Datenschutzbeauftragte oder Risikogremien erfordern. Die Rechenschaftsrahmen von Aufsichtsbehörden wie dem britischen Information Commissioner's Office (ICO) – beispielsweise in dessen Leitlinien zu Rechenschaftspflicht und Governance – betonen ausdrücklich die Bedeutung unabhängiger Aufsicht bei risikoreicher Datenverarbeitung und Systemänderungen. Ihre Genehmigungsregeln sollten festlegen, wann diese Funktionen einbezogen werden und wie ihre Entscheidungen dokumentiert werden. Planen Sie außerdem regelmäßige gemeinsame Überprüfungen mit wichtigen Kunden ein, um ungewöhnliche oder folgenreiche Installationen und die daraus gewonnenen Erkenntnisse zu analysieren. Diese Überprüfungen stärken das Vertrauen und liefern Ihnen konkrete Nachweise für die Aufsicht gemäß A.8.19, die wertvoll sind, wenn Prüfer oder Aufsichtsbehörden nach Ihrer Governance von Shared Services fragen.
Erstellung von revisionssicheren Aufzeichnungen: Tickets, Protokolle und Nachweise für A.8.19
A.8.19 steht und fällt letztendlich mit der Qualität Ihrer Dokumentation. Richtlinien und Arbeitsabläufe verdeutlichen die Absicht; Tickets, Protokolle und Prüfungen belegen, dass die Änderungskontrolle tatsächlich stattfindet. Wenn Sie Ihre Dokumentation von Anfang an auf Auditierbarkeit ausrichten, sparen Sie Zeit, reduzieren Stress und geben Kunden und Auditoren die Gewissheit, dass Softwareinstallationen auf operativen Systemen ordnungsgemäß verwaltet werden.
Definition eines minimalen Datensatzes für jede Änderung
Ein gut gestaltetes Änderungsprotokoll liefert Ihnen genügend Informationen, um den Ablauf zu rekonstruieren, ohne die Techniker mit Formularen zu überfordern. Die Definition eines minimalen Datensatzes hilft Ihnen, dieses Gleichgewicht zu finden und sicherzustellen, dass verschiedene Teams vergleichbare Informationen erfassen, wenn sie Installationen an operativen Systemen durchführen.
Beginnen Sie damit, die Mindestinformationen festzulegen, die bei jeder Softwareinstallation auf einem Betriebssystem vorhanden sein müssen. Viele Managed Service Provider (MSPs) verwenden hierfür einen zweischichtigen Kerndatensatz.
Kernkennungen und Kontext:
- Eindeutige Änderungs-ID und Links zu zugehörigen Vorfällen oder Anfragen.
- Name des Kunden und betroffene Systeme oder Konfigurationselemente.
- Softwarename, Version und Quelle.
- Beschreibung und Zweck der Änderung.
Risiko-, Ergebnis- und Sicherungsdaten:
- Risiko- oder Auswirkungszusammenfassung und -kategorie (niedrig, mittel oder hoch).
- Durchgeführte Tests und verwendete Umgebungen.
- Genehmigungen (wer, wann, in welcher Funktion).
- Details zur Durchführung (wer hat was wann gemacht?).
- Ergebnis der Überprüfung und etwaige Probleme.
- Rollback durchgeführt oder nicht, mit Begründung.
Dieser Detaillierungsgrad bietet Ihnen eine konsistente Grundlage, die Sie den Prüfern vorlegen können, und ermöglicht gleichzeitig Flexibilität in weniger risikoreichen Situationen und Notfallszenarien.
Verknüpfung von Tickets mit technischen Protokollen
Die Verknüpfung Ihrer strukturierten Änderungsaufzeichnungen mit technischen Protokollen macht Ihre Nachweise deutlich überzeugender. Wenn die Vorgänge im Ticket mit Zeitstempeln, Vorgangsverläufen und Systemprotokollen übereinstimmen, können Prüfer und Kunden erkennen, dass Ihre Kontrollen real sind und in den von Ihnen täglich verwendeten Tools funktionieren.
Ein Änderungsbericht ist deutlich aussagekräftiger, wenn nachgewiesen werden kann, dass die dokumentierten Arbeiten dem tatsächlichen Geschehen entsprechen. Das bedeutet:
- Sicherstellen, dass RMM-Jobs, Skripte, Bereitstellungspipelines und Systemprotokolle nach Möglichkeit identifizierbare Änderungs-IDs enthalten.
- Mithilfe von Zeitstempeln und Asset-IDs werden Tickets mit Protokollen und Überwachungsdaten korreliert.
- Wichtige Protokolle werden geschützt und sind während des von Ihnen festgelegten Aufbewahrungszeitraums zugänglich.
In der Praxis können Sie Ihre Bereitstellungstools so konfigurieren, dass vor dem Ausführen eines Auftrags eine Änderungs-ID abgefragt oder in Kommentaren angegeben wird. Wenn später jemand fragt: „Wer hat diesen Agenten auf diesen Servern installiert?“, können Sie innerhalb von Minuten sicher antworten, anstatt die Ereignisse manuell zu rekonstruieren.
Testen von Abruf- und Handhabungsumgebungen
Ihre Fähigkeit, schnell Nachweise zu beschaffen, ist selbst ein Indikator für die Reife Ihres Kontrollsystems. Wenn es Ihnen schwerfällt, ein schlüssiges Bild der kürzlich erfolgten Softwareinstallationen auf On-Premise-, Cloud- und SaaS-Plattformen zu erstellen, müssen Sie noch einiges tun, bevor ein externer Prüfer unter Zeitdruck dieselben Fragen stellt.
Betriebsumgebungen sind selten homogen. Sie können Folgendes verwalten:
- Lokale Server und Netzwerkgeräte.
- Virtuelle Maschinen und Container in mehreren Clouds.
- SaaS-Plattformen mit eigener Änderungshistorie.
Ihr Nachweismodell muss alle Aspekte abdecken. Das bedeutet in der Regel, die Identifizierung von Assets über verschiedene Tools hinweg zu standardisieren und sicherzustellen, dass Ihr ISMS diese Muster berücksichtigt. Es empfiehlt sich außerdem, regelmäßig „Nachweisübungen“ durchzuführen: Wählen Sie einige kürzlich installierte Objekte aus und messen Sie, wie lange es dauert, die vollständige Dokumentation zusammenzustellen. Sollte diese Übung aufwendig sein, besteht weiterhin Handlungsbedarf gemäß A.8.19.
Eine ISMS-Plattform wie ISMS.online kann Ihnen dabei helfen, Richtlinien, Risiken, Verfahren und Stichprobennachweise an einem Ort zu verknüpfen, sodass Sie einen Auditor durch Ihre A.8.19-Etage führen können, ohne in Echtzeit zwischen verschiedenen Tools wechseln zu müssen.
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.
Umgang mit Patches, Standard- und Notfalländerungen unter Beibehaltung der Agilität
Patches und dringende Fehlerbehebungen stellen die Disziplin im Änderungsmanagement auf die Probe. A.8.19 verlangt nicht, dass jedes Update extrem verlangsamt wird, sondern erwartet, dass Sie zwischen Standard-, normalen und Notfalländerungen unterscheiden und nachweisen, dass jede Art von Änderung mit der gebotenen Sorgfalt behandelt wird.
Definition von Standard-, Normal- und Notfalländerungen
Ein einfaches Trio von Änderungstypen – Standard, Normal und Notfall – sorgt für eine einheitliche Sprache und klare Erwartungen. Sobald die Techniker wissen, in welche Kategorie eine Softwareinstallation fällt, wissen sie ungefähr, wie viel Bewertung, Genehmigung und Dokumentation erforderlich ist, bevor sie auf eine bestimmte Anfrage reagieren, insbesondere wenn diese Typen die an anderer Stelle verwendeten Kategorien für niedriges, mittleres und hohes Risiko ergänzen.
Ein einfaches Drei-Typen-Modell eignet sich gut für die meisten Managed Service Provider (MSPs) und ergänzt die von Ihnen andernorts verwendeten Kategorien für niedriges, mittleres und hohes Risiko:
- Standardänderungen: – Gut nachvollziehbare, risikoarme Änderungen, die häufig mit vordefinierten Schritten, Tests und Rollback-Verfahren durchgeführt werden. Beispiel: monatliche Agentenaktualisierungen auf nicht kritischen Endpunkten.
- Normale Änderungen: – geplante Änderungen, die einer vollständigen Bewertung und Genehmigung unterzogen werden, wobei eine risikoabhängige Prüfung erfolgt.
- Notfalländerungen: – dringende Maßnahmen erforderlich, um schwerwiegende Probleme zu beheben oder zu verhindern; diese müssen schnell umgesetzt und anschließend überprüft werden.
Bei Softwareinstallationen sollten Sie dokumentieren, welche Aktivitäten in welche Kategorien fallen und welche Nachweise erforderlich sind. Standardänderungen können auf vorab genehmigten Vorlagen und gebündelten Genehmigungen basieren, während Notfalländerungen eine schnelle Genehmigung mit einer gründlicheren Überprüfung am Folgetag ermöglichen.
Die drei Änderungsarten lassen sich in einem kompakten Vergleich zusammenfassen:
| Typ ändern | Typische Beispiele | Fokus der Tastensteuerung |
|---|---|---|
| Standard | Regelmäßige Aktualisierungen von Agenten oder Versorgungsunternehmen | Vorab genehmigte Schritte, grundlegende Nachweise |
| Normal | Geplante Anwendungs- oder Plattformänderung | Vollständige Bewertung, formelle Genehmigung |
| Notfall | Kritische Sicherheitsbehebung oder Störungsbehebung | Schnelles Handeln, starke Nachbewertung |
Dieses Modell sorgt für klare Gespräche und erleichtert es, den Prüfern zu zeigen, dass Sie nicht jede Änderung gleich behandeln.
Gestaltung sicherer Standard- und Notfallwege
Standard- und Notfallverfahren erfordern unterschiedliche Sicherheitsvorkehrungen. Standardänderungen basieren auf bewährten Vorlagen und Automatisierung, während Notfalländerungen klare Kriterien und systematische Überprüfungen nach der Implementierung voraussetzen. Die korrekte Umsetzung beider Verfahren sichert Ihre Agilität und Nachvollziehbarkeit und hält gleichzeitig die Auswirkungen auf Ihr Geschäft akzeptabel.
Um die Beweglichkeit zu erhalten und gleichzeitig die Kontrolle zu wahren:
- Für Standardänderungen:
- Pflegen Sie einen Katalog vorab genehmigter Muster mit klaren Voraussetzungen (vorhandene Backups, Tests in der Testumgebung, Kommunikationsvorlagen).
- Automatisieren Sie so viel wie möglich mithilfe von Fernverwaltungstools oder Skripten, die mit Ihren Änderungsaufzeichnungen verknüpft sind.
- Überprüfen Sie den Katalog regelmäßig, um Muster auszumustern oder anzupassen, wenn sich die Umgebungen ändern.
- Bei Notfalländerungen:
- Definieren Sie klare Kriterien (z. B. Schweregrad von Sicherheitsproblemen oder aktiven Ausfällen), die die Nutzung des Notfallpfads rechtfertigen.
- Verlangen Sie eine schnelle Dokumentation darüber, was geändert wird und warum, auch wenn Genehmigungen und eine vollständige Bewertung unmittelbar danach erfolgen.
- Planen Sie obligatorische Überprüfungen nach der Implementierung ein, um zu prüfen, ob der Notfallplan gerechtfertigt war und was verbessert werden muss.
Dieser Ansatz ermöglicht es den Ingenieuren, im Tempo des Risikos zu agieren und gleichzeitig eine Spur zu hinterlassen, die A.8.19 genügt und zukünftige interne oder externe Audits unterstützt.
Koordinierung der Patch-Strategie über Plattformen und Clients hinweg
Eine durchdachte Patch-Strategie verhindert, dass Sie zwischen ruhigen Phasen und hektischen Notfallmaßnahmen hin und her schwanken. Indem Sie Ihren Patch-Rhythmus für Endgeräte, Server und Cloud-Dienste aufeinander abstimmen, erleichtern Sie es Ihren Kunden, die zu erwartenden Updates zu verstehen, und Ihren Auditoren, zu erkennen, dass Aktualisierungen gezielt erfolgen und nicht etwa chaotische Reaktionen auf jede neue Empfehlung darstellen.
Patching ist nie nur eine technische Aufgabe. Um Ihre A.8.19-Implementierung praktikabel zu gestalten, sollten Sie Folgendes beachten:
- Behalten Sie Herstellerhinweise und Ankündigungen zum Produktlebenszyklus im Blick, damit Sie Änderungen gezielt planen können und nicht erst in letzter Minute.
- Harmonisieren Sie die Patching-Strategien für Endgeräte, Server und Cloud-Dienste, damit Ihre Support-Teams und Kunden den Ablauf und die Erwartungen verstehen.
- Überwachen Sie fehlgeschlagene und zurückgesetzte Patches, um festzustellen, wo Tests, Kommunikationsvorgänge oder die Zeitplanung nicht funktionieren und verbessert werden müssen.
- Kommunizieren Sie die Patching-Richtlinien klar an die Kunden, damit diese wissen, was sie erwartet, insbesondere bei Notfalländerungen und kurzfristigen Wartungsfenstern.
Wenn Patchzyklen vorhersehbar sind und mit einem transparenten Änderungsmodell verknüpft sind, verspüren die Entwickler weniger die Versuchung zu improvisieren, und die Kunden sind weniger überrascht, wenn man schnell handeln muss, um ihre Sicherheit zu gewährleisten.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online unterstützt Sie dabei, ISO 27001 A.8.19 von einer statischen Klausel in ein dynamisches, auditierbares Änderungsmanagementsystem für alle Ihre Kunden zu verwandeln. Wenn Sie möchten, dass Ihre Techniker schnell arbeiten und Sie gleichzeitig Kunden und Auditoren nachweisen können, dass Installationen in operativen Systemen kontrolliert und nachvollziehbar sind, ist die Nutzung einer ISMS-Plattform als Governance-Ebene über Ihren PSA- und RMM-Tools der logische nächste Schritt.
Wie ISMS.online A.8.19 für MSPs unterstützt
Die Leitlinien für die sichere Softwarebereitstellung von Organisationen wie dem NIST, beispielsweise in dessen Secure Software Development Framework, betonen den Wert einer strukturierten Umgebung für Richtlinien, Risiken, Arbeitsabläufe und Nachweise. Eine ISMS-Plattform wie ISMS.online bietet Ihnen genau diese strukturierte Plattform für Ihre A.8.19-Richtlinien, Risiken, Arbeitsabläufe und Nachweise. Anstatt Ihre Informationen über Dokumente, Tabellen und Tickets zu verteilen, können Sie Ihr Betriebsmodell einmalig beschreiben und mit realen Beispielen aus Ihren Produktionsumgebungen verknüpfen.
In der Praxis können Sie Folgendes tun:
- Bilden Sie Ihre A.8.19-Richtlinien, -Ziele und -Risiken in einer strukturierten Bibliothek ab, zusammen mit zugehörigen Kontrollmechanismen wie Änderungsmanagement und Lieferantensicherheit.
- Führen Sie ein aktuelles Register der Risiken bei der Softwareinstallation und verknüpfen Sie jedes Risiko mit spezifischen Behandlungs- und Kontrollmaßnahmen, damit Sie erkennen können, wo Ihre größten Risiken liegen.
- Richten Sie die Governance-Workflows in der Plattform an den Änderungsschritten aus, die Sie bereits in Ihren PSA-, ITSM- und RMM-Tools durchführen, damit die Teams das Gefühl haben, einem einheitlichen System zu folgen und nicht doppelte Arbeit zu leisten.
- Erstellen Sie übersichtliche Berichte und Dashboards, die Kunden und Wirtschaftsprüfern erläutern, wie Änderungen in allen Ihren verwalteten Umgebungen angefordert, genehmigt, implementiert und verifiziert werden.
- Planen und verfolgen Sie regelmäßige Überprüfungen Ihrer Installationssteuerungen, damit diese sich mit Ihrem Serviceangebot, Ihrem Kundenstamm und der Bedrohungslandschaft weiterentwickeln.
Diese Beschreibung dient lediglich der Veranschaulichung und stellt keine Garantie für eine Zertifizierung oder die Einhaltung gesetzlicher Bestimmungen dar.
Wann eine Demo der richtige nächste Schritt ist
Ein Gespräch mit dem ISMS.online-Team ist besonders dann sinnvoll, wenn Sie bereits erkannt haben, dass Ad-hoc-Installationen und ein einfaches Ticketsystem nicht ausreichen und Sie ein besser geregeltes, evidenzbasiertes A.8.19-Betriebsmodell wünschen, das es Ihren Technikern dennoch ermöglicht, schnell mit den ihnen vertrauten Werkzeugen zu arbeiten.
Trotz des steigenden Drucks nannten fast alle Befragten in der ISMS.online-Umfrage „State of Information Security 2025“ die Erlangung oder Aufrechterhaltung von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 als oberste Priorität, was die Anforderungen von Kunden und Aufsichtsbehörden widerspiegelt.
Wenn Sie bereit sind, von informellen Installationen zu einer disziplinierten, revisionssicheren Änderungskontrolle für alle Ihre Kunden überzugehen, ist die Wahl von ISMS.online als Ihre ISMS-Plattform ein praktischer Weg, diesen Wandel zu vollziehen. Und wenn Sie Wert auf klare Governance, stärkeres Kundenvertrauen und reibungslosere Audits legen, steht Ihnen das Team gerne zur Seite, um zu erkunden, wie das in Ihrer eigenen MSP-Umgebung aussehen könnte.
KontaktHäufig gestellte Fragen (FAQ)
Was genau erwartet ISO 27001:2022 Abschnitt A.8.19 von einem Managed Service Provider (MSP) im täglichen Betrieb?
Es wird erwartet, dass jede Softwareinstallation auf einem Live-System autorisiert, risikobewertet und von der Anfrage bis zur Verifizierung nachvollziehbar ist. Für einen Managed Service Provider (MSP) bedeutet dies, dass Installationen auf eigenen Plattformen und in Kundensystemen als … behandelt werden. kontrollierte betriebliche ÄnderungenEs handelt sich nicht um informelle Anpassungen, an die sich jemand „am Freitagabend“ erinnert. Sie legen fest, welche Umgebungen in den Geltungsbereich fallen, wer Arbeiten anfordern und genehmigen kann, wann Tests erforderlich sind und welche Felder jedes Mal erfasst werden müssen.
Im Alltag bedeutet das in der Regel Folgendes: eine kurze schriftliche Regel, die Geltungsbereich und Rollen beschreibt, einen einfachen, obligatorischen Pfad in Ihrem PSA/ITSM-System, der für „operative Installationen“ gekennzeichnet ist, und einen kleinen, konsistenten Datensatz, den Sie ohne langes Suchen in Chatprotokollen abrufen können. Wenn Sie schnell einige wenige kürzlich vorgenommene Änderungen aufzeigen können, die klar darlegen, warum die Installation notwendig war, wie das Risiko bewertet wurde, wer sie genehmigt hat, wie sie durchgeführt wurde und woran Sie den Erfolg festgestellt haben, entsprechen Sie bereits weitgehend den Anforderungen von sicherheitserfahrenen Kunden und ISO-27001-Auditoren gemäß A.8.19.
Wie sollte ein Managed Service Provider (MSP) entscheiden, was als operatives System „in den Geltungsbereich fällt“?
Anstatt von Serverlisten auszugehen, sollte man die Auswirkungen betrachten. Eine praxisnahe Geltungsbereichsbeschreibung für A.8.19 umfasst üblicherweise Folgendes:
- Kundenspezifische Produktionssysteme und kritische Geschäftsanwendungen.
- Gemeinsam genutzte Plattformen wie RMM, Backup, Monitoring und Sicherheitslösungen.
- Interne Dienste, die die Kundenauslieferung unterstützen oder Kundendaten speichern.
Nicht-Produktionslabore und kurzlebige Testumgebungen können außerhalb des Produktionsbereichs liegen, aber nur, wenn diese Grenze klar definiert und konsequent eingehalten wird. Eine hilfreiche Frage ist: „Könnte eine misslungene Installation die Verfügbarkeit, Vertraulichkeit, Integrität oder das regulatorische Risiko für uns oder einen Kunden beeinträchtigen?“ Lautet die Antwort ja, ist dies als betriebliche Änderung gemäß A.8.19 zu behandeln.
Was umfasst ein „kurzes schriftliches Regelwerk“ für A.8.19 normalerweise?
Ihr Basisregelwerk muss nicht umfangreich sein. Die meisten Managed Service Provider (MSPs) können A.8.19 auf einer Seite abdecken, sofern Folgendes klar dargelegt wird:
- Umfang: – welche Umgebungen und Kunden abgedeckt sind und welche als nicht betriebsbereit behandelt werden.
- Rollen: – der Softwareinstallationen anfordern, genehmigen, implementieren und überprüfen kann.
- Löst aus: – was als operative Installation gilt (z. B. alles, was in der Produktion eingesetzt wird, gemeinsam genutzte Plattformen oder Sicherheitstools).
- Mindestrekord: – die Pflichtfelder, die bei jeder Installation erfasst werden müssen.
Sobald dies vereinbart und kommuniziert ist, werden Ihre Werkzeuge zum Mittel der Wahl, um diese Entscheidungen umzusetzen, anstatt dass jeder Ingenieur seinen eigenen Ansatz entwickelt.
Nutzen Sie die Tools, mit denen Ihre Ingenieure bereits arbeiten, und fügen Sie nur so viel Struktur hinzu, dass der Prozess wiederholbar und nachvollziehbar ist. Ein bewährtes Muster ist: Anfrage → Bewertung → Genehmigung → Termin → Umsetzung → Überprüfung → AbschlussDiese Einstellung wird automatisch auf alle Tickets oder Änderungsarten angewendet, die mit „Softwareinstallation auf einem Betriebssystem“ gekennzeichnet sind. Im Bewertungsschritt entscheiden Sie, ob die Arbeiten einem vorab genehmigten Standardverfahren entsprechen oder aufgrund von Mandantenfähigkeit, Kundenkontakt oder höherem Risiko einer umfassenderen Prüfung bedürfen.
Die Implementierung sollte über kontrollierte Kanäle wie RMM-Jobs, Bereitstellungsskripte oder Pipelines erfolgen, wobei jede Änderung mit ihrem Ticket oder ihrer Änderungs-ID verknüpft wird. Abschließend erwarten Sie einen kurzen Bestätigungsvermerk und einen Verweis auf technische Nachweise wie Protokolle oder Integritätsprüfungen, damit jeder nachvollziehen kann, welche Aktionen ausgeführt wurden und die wichtigsten Dienste weiterhin einwandfrei funktionieren. Wenn dieses Muster in Ihrem PSA/ITSM sichtbar ist und konsequent angewendet wird, können Sie einem Auditor oder einem wichtigen potenziellen Kunden Ihren A.8.19-Ansatz in wenigen Schritten erläutern.
Ein reibungsloser Arbeitsablauf setzt sich in der Regel aus Komponenten zusammen, die man bereits besitzt:
- Ein spezieller Ticket- oder Änderungstyp mit Pflichtfeldern für Kunde, Anlage oder Dienstleistung, Software, Zweck, grundlegendes Risiko, Tests und Rollback.
- RMM- oder Bereitstellungsaufträge, die mit dieser Änderungs-ID gekennzeichnet sind, damit Sie ohne Rätselraten die Frage „Was hat sich wo und wann geändert?“ beantworten können.
- Vorlagen für gängige Szenarien wie Agenten-Rollouts, Upgrades der Sicherheitsarchitektur oder Änderungen an Backup-Agenten, damit die Techniker die richtigen Schritte sehen, ohne sie neu schreiben zu müssen.
Wenn Ingenieure erkennen, dass der offizielle Weg tatsächlich der schnellste ist, um sichere Änderungen live zu schalten, werden sie ihn mit weitaus größerer Wahrscheinlichkeit nutzen.
Wenn Sie diesen Workflow in einem strukturierten Informationssicherheitsmanagementsystem abbilden möchten, anstatt ihn über verschiedene Tools zu verteilen, können Sie mit ISMS.online den Prozess einmal beschreiben, ihn direkt den Änderungsmanagementklauseln der ISO 27001 A.8.19 und des Anhangs L zuordnen und Live-Beispiele anhängen, sodass Sie für Kunden und Auditoren stets Nachweise parat haben.
Wie können Sie Kunden und Prüfern zeigen, dass der Prozess real ist und nicht nur auf dem Papier existiert?
Visualisierungen sind hilfreich. Ein einfaches Swimlane-Diagramm mit Ingenieuren, Service Desk, Genehmigern und Kunden oben und den sieben Schritten von links nach rechts verdeutlicht den Ablauf. Kombiniert man dies mit zwei oder drei realen Änderungsdatensätzen, die dem Diagramm entsprechen, zeigt man schnell, dass die A.8.19-Kontrolle in die Betriebsabläufe integriert ist und nicht nur in einer Richtlinie festgehalten wurde.
Welche spezifischen Risiken werden in A.8.19 behandelt, und warum sind diese für Managed Service Provider (MSPs) verstärkt?
Die Kontrollmaßnahme zielt darauf ab, zu verhindern, dass routinemäßige Softwareinstallationen zu größeren Zwischenfällen führen. Als Managed Service Provider (MSP) spielen Sie häufig dieselbe Änderung mithilfe gemeinsam genutzter Tools gleichzeitig in vielen Umgebungen ein, wodurch sich das potenzielle Risiko naturgemäß erhöht. Version A.8.19 dient dazu, mehrere spezifische Risiken zu minimieren:
- Nicht genehmigte oder schlecht begründete Installationen: die Ihre eigenen Standards oder die mit dem Kunden vereinbarten Basiswerte umgehen.
- Unzureichend getestete Updates: die Überwachung, Sicherungsagenten oder Kernanwendungen über mehrere Mandanten hinweg deaktivieren.
- Kompromittierte Update-Kanäle: , wenn ein Angreifer den Installationsassistenten eines Herstellers oder Ihr RMM missbraucht, um bösartigen Code in großem Umfang zu verbreiten.
- Fehlende oder inkonsistente Datensätze: Dadurch sind Sie angreifbar, wenn Sie einer Aufsichtsbehörde, einem Versicherer oder einem wichtigen Kunden erklären müssen, was passiert ist.
Da ein falsch ausgerichteter RMM-Job oder ein falsch ausgerichtetes Skript innerhalb von Minuten Dutzende von Kunden betreffen kann, wird die gleiche Änderungsdisziplin, die früher in einem einzelnen IT-Team vielleicht noch wünschenswert war, in einem Managed Service unerlässlich. A.8.19 schreibt vor, dass Sie diese Berechtigung durch Autorisierung, angemessene Tests und Nachverfolgbarkeit absichern müssen.
Mangelnde Kontrolle über Änderungen an Betriebssystemen bleibt selten ein rein internes Problem. Für Managed Service Provider (MSPs) umfassen die Folgen üblicherweise Folgendes:
- Vertraglicher Stress: Von SLA-Gutschriften und Vertragsstrafendiskussionen bis hin zu Streitigkeiten darüber, wer die Kosten eines Vorfalls trägt.
- Regulierungsdruck: Beispielsweise im Rahmen der DSGVO, der NIS 2 oder branchenspezifischer Vorschriften, bei denen Ihre Rolle als Lieferant überprüft wird, wenn ein Ausfall oder eine Verletzung Ihrer Dienste vorliegt.
- Versicherungsherausforderungen: Da Cyberversicherer zunehmend klare Nachweise über ein strukturiertes Änderungsmanagement verlangen, bevor sie den Versicherungsschutz verlängern oder Ansprüche auszahlen, ...
Wenn Sie schnell einen kurzen, konsistenten Satz von Änderungsaufzeichnungen für kürzlich durchgeführte Installationen erstellen können, sind Sie deutlich besser in der Lage nachzuweisen, dass Sie angemessene Maßnahmen ergriffen haben und dass das Problem auf einen unvorhergesehenen Mangel und nicht auf mangelnde Kontrolle zurückzuführen ist. Diese Unterscheidung ist für Wirtschaftsprüfer, Aufsichtsbehörden und Versicherer von Bedeutung und genau das soll A.8.19 verdeutlichen.
Wie kann ein Managed Service Provider (MSP) diese Risiken in einen Wettbewerbsvorteil verwandeln?
Wenn Sie ein diszipliniertes und skalierbares Änderungsmanagement für Softwareinstallationen nachweisen können, sind Sie für größere, regulierte Organisationen attraktiver. Sie können detaillierte Sicherheitsfragebögen souverän beantworten, Due-Diligence-Zyklen verkürzen und Ihren Service als risikoärmere Alternative zu Wettbewerbern positionieren, die noch auf informelle Praktiken setzen. Wenn Sie A.8.19 als Teil Ihrer Markteinführungsstrategie und nicht als reine Compliance-Pflicht betrachten, können Sie anspruchsvollere Kunden gewinnen und langfristig binden.
Wie sehen überzeugende Nachweise gemäß A.8.19 für einen ISO 27001-Auditor aus, der einen Managed Service Provider (MSP) prüft?
Die Prüfer achten eher auf klare, konsistente Darstellungen als auf perfekte Formulierungen. Aussagekräftige Nachweise gemäß A.8.19 ermöglichen es ihnen, eine Stichprobe realer Installationen auf operativen Systemen auszuwählen und für jede einzelne Installation schnell Folgendes zu erkennen:
- Warum die Änderung notwendig war und welcher Kunde oder interne Dienst davon profitierte.
- Welche Software wurde installiert, von welcher vertrauenswürdigen Quelle und auf welchen Systemen?
- Wie Risiko und Auswirkungen berücksichtigt wurden, einschließlich etwaiger Abhängigkeitsprüfungen.
- Wer hat die Arbeiten wann genehmigt, einschließlich einer gegebenenfalls erforderlichen Kundenunterzeichnung.
- Wie die Installation durchgeführt wurde (RMM, Skript, Pipeline, manuell) und wann.
- Wie Erfolg und Stabilität überprüft wurden und ob Nachuntersuchungen erforderlich waren.
Idealerweise sind diese Änderungsdatensätze mit zugrundeliegenden technischen Artefakten wie RMM-Verläufen, Bereitstellungsprotokollen oder Überwachungs-Screenshots verknüpft, sodass die Beschreibung dem tatsächlichen Geschehen entspricht. Ein Auditor sollte keine Ingenieure befragen müssen, um Routinearbeiten zu verstehen. Wenn er den Ablauf anhand des Systems rekonstruieren kann, sind Sie gut auf die Anforderungen von A.8.19 und die umfassenderen Anforderungen an das Änderungsmanagement gemäß Anhang L vorbereitet.
Welche Mindestdatensätze sollte jede Softwareinstallation gemäß A.8.19 erfassen?
Eine gute Abdeckung lässt sich in der Regel mit einem kompakten, wiederholbaren Satz von Feldern erreichen, zum Beispiel:
- Kunden und betroffene Dienstleistungen oder Umgebungen.
- Softwarename, Version und vertrauenswürdige Quelle oder Repository.
- Klarer geschäftlicher Grund sowie eine kurze Zusammenfassung der Risiken oder Auswirkungen.
- Änderungsart (Standard, Normal, Notfall) und Risikobewertung.
- Angaben zum Genehmiger mit Funktion und Zeitstempel, gegebenenfalls auch externe Genehmigungen.
- Testnotizen und ein definierter Rückruf- oder Notfallplan.
- Details zur Implementierung (wer, wann, wie) mit Verweisen auf verwendete Skripte oder Jobs.
- Ergebnisse der Überprüfung und etwaige Folgemaßnahmen wie z. B. zusätzliche Überwachung.
Ein kurzes, präzises Protokoll, das immer die gleiche Geschichte erzählt, ist für einen Prüfer wertvoller als ein ausuferndes Formular, das niemand richtig ausfüllt.
Wenn Sie eine Plattform wie ISMS.online verwenden, können Sie dieses „Grundgerüst“ einmal definieren, es direkt mit ISO 27001 A.8.19 und den zugehörigen Klauseln des Anhangs L verknüpfen und eine fortlaufend aktualisierte Sammlung von Beispielen bereithalten, sodass Sie nicht erst kurz vor einem Audit in unfertigen Ticketwarteschlangen wühlen müssen.
Wie können Sie testen, ob Ihre A.8.19-Aufzeichnungen revisionssicher sind?
Ein einfacher Selbsttest besteht darin, einen Kollegen, der nicht direkt in die Arbeit eingebunden ist, drei zufällig ausgewählte Änderungsdokumente prüfen zu lassen. Kann er genau erklären, warum die jeweilige Installation durchgeführt wurde, wie mit den Risiken umgegangen wurde und woran Sie die Wirksamkeit erkennen, sind Ihre Dokumente korrekt. Muss er sich hingegen immer wieder an die Techniker wenden, um Klärungen vorzunehmen, sollten Sie wahrscheinlich die Vorgaben oder Richtlinien anpassen.
Wie können Managed Service Provider (MSPs) Standard-, Normal- und Notfall-Softwareänderungen klassifizieren, ohne die Auslieferung zu verlangsamen?
Geschwindigkeit wird durch die Anpassung des Prozessaufwands an das Risiko erhalten, nicht durch die gleiche Behandlung aller Installationen. Ein einfaches Modell für Managed Service Provider (MSPs) ist:
- Standardänderungen: – Risikoarme, gut wiederholbare Installationen mit klar definierten Ergebnissen, wie z. B. routinemäßige Agentenaktualisierungen für nicht kritische Endpunkte. Diese sind vorab genehmigt, folgen einer dokumentierten Vorlage und erfordern nur minimalen zusätzlichen Bewertungsaufwand.
- Normale Änderungen: – Geplante Arbeiten mit gewissen Unsicherheiten oder Auswirkungen auf das Geschäft, wie z. B. Anwendungs-Upgrades, Änderungen an gemeinsam genutzten Plattformen oder Konfigurationsänderungen. Diese durchlaufen eine klare Risiko- und Folgenabschätzung, eine ausdrückliche Genehmigung, eine Terminplanung und eine dokumentierte Überprüfung.
- Notfalländerungen: – dringende Maßnahmen zur Behebung aktiver Vorfälle oder zur Anwendung kritischer Sicherheitspatches, wobei die anfängliche Bewertung und Genehmigung komprimiert wird, um den Dienst schnell wiederherzustellen, und anschließend eine Überprüfung nach der Implementierung durchgeführt und die Aufzeichnungen bereinigt werden.
Der Nutzen liegt in den einfachen, schriftlichen Kriterien und Beispielen für jede Kategorie, die in einer für Ihre Ingenieure verständlichen Sprache verfasst sind. A.8.19 schreibt nicht für jede Routineänderung einen Ausschuss vor; vielmehr wird von Ihnen erwartet, dass Sie zwischen verschiedenen Arbeitsarten unterscheiden und verhältnismäßig vorgehen, einschließlich der Meldung von Notfällen.
Wie kann man verhindern, dass Kategorien missbraucht werden, um den Prozess zu umgehen?
Missbrauch tritt meist dann auf, wenn Menschen befürchten, der formale Weg würde sie ausbremsen. Zwei praktische Gegenmaßnahmen helfen:
- Die Schritte für Standard- und Notfallrouten sollten so kurz wie möglich gehalten werden, ohne dabei die Sicherheit der Kunden und der eigenen Plattformen zu beeinträchtigen. Wenn das Ausfüllen der Vorlage später tatsächlich Zeit spart, werden die Techniker dies gerne tun.
- Beobachten Sie die Nutzung der Kategorien im Zeitverlauf. Wenn die Anzahl der „Notfälle“ stetig zunimmt, während die Anzahl echter Vorfälle konstant bleibt, sollten Sie dies als Signal nutzen, Ihre Kriterien zu verfeinern oder lokale Gewohnheiten zu berücksichtigen, anstatt Einzelpersonen zu disziplinieren.
Die regelmäßige Verwendung anonymisierter Beispiele in Teamdiskussionen – „Dieses Upgrade war wirklich Standard, dieses war eindeutig normal, dieses musste ein Notfall sein“ – schafft ein gemeinsames Verständnis der Abläufe und erleichtert die Entscheidungsfindung an vorderster Front.
Wie kann ISMS.online einem Managed Service Provider (MSP) dabei helfen, A.8.19 bei allen Kunden zu implementieren, ohne dabei einen hohen Verwaltungsaufwand zu verursachen?
ISMS.online bietet Ihnen eine zentrale Plattform zur Entwicklung und zum Nachweis Ihres A.8.19-Ansatzes, während Ihre Techniker weiterhin mit ihren gewohnten PSA-, ITSM- und RMM-Tools arbeiten können. Sie dokumentieren, wie Softwareinstallationen auf operativen Systemen angefordert, bewertet, genehmigt, implementiert und überprüft werden, und ordnen dieses Modell anschließend direkt den ISO 27001 A.8.19- und den zugehörigen Anhang-L-Klauseln zum Änderungsmanagement in Ihrem Informationssicherheitsmanagementsystem zu.
Dort können Sie Umfang, Rollen, Klassifizierungsregeln und Prüfzyklen einmalig festlegen und im Verlauf Beispiele, Risikobewertungen und Verbesserungsmaßnahmen hinzufügen. Wenn ein Auditor, Versicherer oder ein potenzieller Großkunde fragt, wie Sie verhindern, dass ein falsch definiertes Update zu einem Ausfall mehrerer Kunden führt, können Sie ihm eine klare Beschreibung Ihrer Kontrollmaßnahmen und aktuelle Nachweise präsentieren, anstatt ein individuelles Dokument von Grund auf neu zu erstellen.
Wie unterstützt ISMS.online den täglichen Betrieb von Managed Service Providern, anstatt „ein weiteres System“ zu werden?
Es geht darum, Governance und Qualitätssicherung einzuführen, ohne den Arbeitsaufwand zu verdoppeln:
- Ihre Teams erstellen und bearbeiten weiterhin Änderungsanträge in den bestehenden Tools unter Verwendung der Kategorien und Vorlagen, die Sie vereinbart haben.
- ISMS.online spiegelt den gleichen Arbeitsablauf auf der Governance-Ebene wider und verknüpft Richtlinien, Risiken, Kontrollen und Nachweise, damit die Führungsebene sehen kann, wie A.8.19 in der Praxis funktioniert.
- Die im ISMS hinterlegten Nachweise bestehen aus Verweisen auf reale Tickets, Skripte, Protokolle und Berichte und nicht aus neu eingegebenen Daten. Daher wird die Aktualisierung des ISMS Teil der normalen Arbeit und nicht zu einem separaten Projekt.
Wenn Sie der Managed Service Provider (MSP) sein möchten, auf den Banken, Gesundheitsdienstleister und andere regulierte Organisationen vertrauen können, hilft Ihnen eine übersichtliche, gemäß Anhang L konforme Änderungsmanagement-Dokumentation für A.8.19 in ISMS.online, sich von der Konkurrenz abzuheben. So wird Ihr Änderungsmanagement von einer selbstverständlichen Annahme zu einer sichtbaren Stärke, der Ihre Kunden vertrauen können.
