Zum Inhalt

Warum die Lieferketten von Managed Service Providern jetzt Ihre größte Angriffsfläche darstellen

Moderne Managed Service Provider sehen sich zunehmend Risiken in ihren ITK-Lieferketten ausgesetzt, nicht nur in ihren eigenen Rechenzentren. Vorgelagerte Tools, Plattformen und Partner können zu Single Points of Failure werden, deren Kompromittierung oder Nichtverfügbarkeit zahlreiche Kunden und Services gleichzeitig beeinträchtigt. Anhang A.5.21 soll Ihnen helfen, diese Abhängigkeiten zu verstehen, klare Sicherheitserwartungen mit Lieferanten und Kunden zu vereinbaren und Lieferkettenrisiken als integralen Bestandteil Ihres ISMS zu behandeln, anstatt sie erst im Nachhinein zu berücksichtigen.

Für viele Managed Service Provider ist die Lieferkette aus Tools, Plattformen und Partnern, von denen sie abhängig sind, neben dem eigenen Rechenzentrum zu einem der risikoreichsten Bereiche ihrer IT-Umgebung geworden. Diese gemeinsam genutzten Komponenten bilden die Grundlage für ihre Umsätze, Verträge und die Einhaltung regulatorischer Verpflichtungen. Fällt eine dieser Komponenten aus oder wird sie kompromittiert, können sich die Auswirkungen innerhalb weniger Stunden auf zahlreiche Kunden auswirken. Deshalb ist Anhang A.5.21 so wichtig, um dieses Geflecht an Abhängigkeiten bewusst zu gestalten und zu verwalten.

Moderne Managed Service Provider (MSPs) tragen das Risiko, das sich aus der Mandantenfähigkeit von Fernverwaltungsplattformen, Cloud-Diensten, Identitätsanbietern und Spezialtools ergibt, die zwischen ihnen und ihren Kunden positioniert sind. Ein einziger Angriff auf eine vorgelagerte Plattform kann einem Angreifer privilegierten Zugriff auf einen großen Teil Ihres Kundenstamms verschaffen. Ebenso kann ein Ausfall einer Kernplattform mehrere Kunden gleichzeitig offline nehmen, unabhängig davon, wie gut Ihre eigene Infrastruktur betrieben wird.

Starke Lieferketten beginnen damit, zu wissen, von wem man wirklich abhängig ist.

Die neue Realität des MSP-Lieferkettenrisikos

Die neue Realität für Managed Service Provider (MSPs) besteht darin, dass sich Angreifer und Ausfälle über gemeinsam genutzte IT-Plattformen schneller ausbreiten als über individuelle Kundennetzwerke. Mit der Integration von Fernverwaltungstools, Cloud-Diensten, Identitätsplattformen und Sicherheitsprodukten in Ihre Angebote wird jede gemeinsam genutzte Komponente zu einem potenziellen Single Point of Failure. Anhang A.5.21 soll Ihnen helfen, diese Realität zu erkennen und angemessene Kontrollmechanismen zu entwickeln.

Moderne Managed Service Provider (MSPs) übernehmen den Großteil ihres Lieferkettenrisikos von den Cloud-Plattformen, SaaS-Tools und Subunternehmern, die sie in ihre Services integrieren. Beim Aufbau neuer Angebote ist es naheliegend, zusätzlich zu den Kernfunktionen spezialisierte Plattformen, Monitoring-Tools, Backup-Anbieter und Sicherheitsdienste hinzuzufügen.

Der Bericht „State of Information Security 2025“ zeigt, dass die Mehrheit der Organisationen im vergangenen Jahr mindestens einen Sicherheitsvorfall erlebt hat, der von einem Drittanbieter oder Lieferanten verursacht wurde.

Mit der Zeit entstehen durch dieses Wachstum dichte, mehrstufige Abhängigkeitsketten: Fernüberwachungstools in der Public Cloud, Identitätsplattformen, die mit Kundensystemen verknüpft sind, Backup-Anbieter, die Daten regionsübergreifend replizieren, und spezialisierte Sicherheitstools, die über APIs integriert sind. Angreifer müssen nicht jeden Kunden einzeln angreifen. Die Kompromittierung eines vorgelagerten Dienstes kann privilegierten Zugriff auf viele verwaltete Umgebungen ermöglichen oder die schnelle Verbreitung von Ransomware zwischen Kunden mit denselben Tools gewährleisten. Analysen von Angriffen auf Software-Lieferketten beschreiben genau dieses Muster: Die Kompromittierung eines weit verbreiteten Anbieters oder einer Komponente kann eine große Anzahl nachgelagerter Organisationen gleichzeitig beeinträchtigen (Analyse von Angriffen auf Software-Lieferketten).

Ausfälle verhalten sich analog. Ein Ausfall eines zentralen Identitätsanbieters oder einer Remote-Management-Plattform kann mehrere Kunden offline nehmen, Vertragsstrafen auslösen und die Aufmerksamkeit der Aufsichtsbehörden auf sich ziehen, selbst wenn Ihre eigene Infrastruktur nicht betroffen ist. Branchenleitfäden zur Bewertung und zum Management von Cybersicherheitsrisiken in der Lieferkette heben häufig hervor, wie Störungen oder Kompromittierungen gemeinsam genutzter Cloud- oder Identitätsdienste zu simultanen Ausfällen und Geschäftsausfällen bei vielen Kunden sowie zu vertraglichen und regulatorischen Konsequenzen für die darauf angewiesenen Anbieter führen können (Überblick über Cybersicherheitsrisiken in der Lieferkette). Anhang A.5.21 zielt genau auf diese kombinierten technischen und vertraglichen Auswirkungen ab und nicht nur auf isolierte Schwachstellen.

Die Sicherheitskennzahlen vieler Managed Service Provider (MSPs) hinken diesem Wandel hinterher. Teams erfassen zwar weiterhin Perimeterereignisse, Patch-Raten und Endpunktwarnungen, haben aber kaum Einblick in übernommene Schwachstellen oder durch Lieferanten verursachte Vorfälle. Ohne einen klaren Überblick über vorgelagerte Abhängigkeiten und deren Risikoprofile agieren Sie quasi im Blindflug an den Stellen, an denen Ausfälle am ehesten schwerwiegende Folgen haben. Deshalb benötigen Sie in Ihrem Informationssicherheitsmanagementsystem (ISMS) neben Netzwerkkennzahlen auch Einblicke in die gesamte Lieferkette.

Wo die Sichtverhältnisse wirklich zusammenbrechen

Die Transparenz bricht üblicherweise in der intransparenten Lieferkette zusammen: Tools, Dienstleistungen und Partner, die außerhalb des formalen Beschaffungswesens eingeschleust wurden. Diese Entscheidungen erscheinen oft zunächst einmalig, werden aber zu einem festen Bestandteil Ihrer permanenten Abhängigkeitsstruktur.

Die meisten Managed Service Provider (MSPs) können ihre wichtigsten Lieferanten auswendig aufzählen, doch nur wenige können ein vollständiges Bild davon zeichnen, auf wen und was sie sich tatsächlich verlassen. Freemium-Dienste, die von den Technikern genutzt werden, „temporäre“ Pilotprojekte, die nie abgeschlossen wurden, und vom Kunden vorgegebene Plattformen, deren Unterstützung man zugesagt hat, tragen alle zu dieser verborgenen Ebene bei.

Das Problem besteht darin, dass Angreifer und Aufsichtsbehörden sich nicht darum kümmern, ob eine Abhängigkeit formell genehmigt oder stillschweigend eingeführt wurde. Gelangt eine Sicherheitslücke über diese Abhängigkeit in Ihre verwalteten Umgebungen, erwarten Ihre Kunden dennoch Antworten von Ihnen. Anhang A.5.21 behandelt diese Beziehungen als relevant. Er sieht vor, dass Sie diese in Ihre Lieferkettenstruktur integrieren, klassifizieren und anhand des jeweiligen Risikos festlegen, was „ausreichend sicher“ für jede einzelne Abhängigkeit bedeutet.

Ein erster praktischer Schritt ist die Ermittlung des Gefahrenradius Ihrer wichtigsten gemeinsam genutzten Komponenten. Schätzen Sie für jedes wichtige Tool oder jede Plattform ab, wie viele Kunden, welche Datentypen und welche Dienste davon abhängen. Wenn Sie erkennen, dass ein zentraler Remote-Management-Stack einen erheblichen Teil Ihres Umsatzes sichert, wird das Lieferkettenrisiko oft konkret und erfordert strukturierte Kontrollmaßnahmen.

Warum sich Ihr Vorstand genauso dafür interessieren sollte wie Ihre Ingenieure

Ihr Vorstand und Ihre Geschäftsleitung müssen die Sicherheit der IT-Lieferkette als Governance-Thema und nicht nur als technische Angelegenheit für Ingenieure betrachten. Kunden, Versicherer und Aufsichtsbehörden fragen zunehmend, wie Risiken durch Drittanbieter und ausgelagerte IT-Dienstleistungen identifiziert, bewertet und kontrolliert werden, und erwarten schlüssige Antworten, die über das Sicherheitsteam hinausgehen. Branchenverbände, die Bedrohungen für Software und die IT-Lieferkette überwachen, stellen fest, dass externe Stakeholder verstärkt darauf achten, wie Unternehmen mit Drittanbieterrisiken umgehen, und nicht nur, welche Technologien sie einsetzen (zunehmende Bedrohung durch Angriffe auf die Software-Lieferkette).

Laut der ISMS.online-Umfrage 2025 erwarten Kunden zunehmend, dass Lieferanten sich an formalen Rahmenwerken wie ISO 27001, ISO 27701, DSGVO oder SOC 2 orientieren, anstatt sich auf allgemeine Aussagen zu bewährten Verfahren zu verlassen.

Wenn Stakeholder erkennen, dass Ihre Managed Services auf anderen Anbietern basieren, die selbst Ziel von Angriffen sein könnten, suchen sie nach Belegen dafür, dass Sie diese Verbindungen verstehen und managen. Lieferkettensicherheit wird zu einem Thema auf Vorstandsebene, da Fehler hier Betriebsunterbrechungen, behördliche Überprüfungen und Reputationsschäden gleichzeitig nach sich ziehen können.

Führungskräfte benötigen in der Regel die Gewissheit, dass:

  • Kritische vorgelagerte Tools und Partner werden identifiziert, einer Risikobewertung unterzogen und vertraglich an klare Sicherheitserwartungen gebunden.
  • Die Organisation versteht, welche Kunden und Dienstleistungen von bestimmten Ausfällen in der vorgelagerten Lieferkette betroffen wären.
  • Es gibt erprobte Handlungsanweisungen für Vorfälle mit Lieferanten, die die technische Reaktion, die Kommunikation und die vertraglichen Verpflichtungen abdecken.

Ohne diese Gewissheit landen schwierige Fragen im Vorstand genau dann, wenn es am ungünstigsten ist: bei einem Ausfall, einer Sicherheitslücke oder einer Prüfung. Wenn Sie Anhang A.5.21 als formale Grundlage für die Qualitätssicherung Ihrer ITK-Lieferkette nutzen, erhalten Führungskräfte eine standardisierte und verlässliche Grundlage anstelle von improvisierten Erklärungen unter Druck.

Kontakt


Anhang A.5.21 und die neue Definition der IKT-Lieferkettensicherung

Anhang A.5.21 fordert Sie auf, mit Ihren ITK-Lieferanten und -Kunden angemessene Erwartungen an die Informationssicherheit zu vereinbaren, zu dokumentieren und aufrechtzuerhalten. Konkret bedeutet dies, dass Sie wissen sollten, auf wen Sie sich verlassen, was Sie von ihnen erwarten, was sie von Ihnen erwarten und wie diese Erwartungen regelmäßig überprüft werden. Für einen Managed Service Provider (MSP) bedeutet dies, dass Sie sich bewusst sind, dass Sie in den ITK-Lieferketten vieler Kunden agieren und gleichzeitig Ihre eigene verwalten. Dies entspricht der Beschreibung von Kontrolle A.5.21 in ISO/IEC 27001:2022 im Katalog der Informationssicherheitskontrollen für ITK-Lieferketten (ISO/IEC 27001:2022 Übersicht).

Fast alle Organisationen, die an der ISMS.online-Umfrage 2025 teilnahmen, nannten das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 als eine ihrer obersten Prioritäten.

Ernst genommen, verlagert Anhang A.5.21 die Qualitätssicherung in der IKT-Lieferkette von einer intuitiven Vorgehensweise hin zu einer risikobasierten, dokumentierten Praxis. Er baut auf den umfassenderen Kontrollen des Anhangs A für Lieferantenbeziehungen, Verträge und Überwachung auf und wendet diese speziell auf IKT-Produkte und -Dienstleistungen an. Das Verständnis seiner Einordnung in das System neben A.5.19, A.5.20 und A.5.22 bietet Ihnen einen Rahmen, um dies umzusetzen, ohne Ihr gesamtes ISMS neu gestalten zu müssen.

Eine integrierte ISMS-Plattform wie ISMS.online kann Ihnen dabei helfen, den Überblick zu behalten, indem sie Lieferanten, Kunden, Dienstleistungen, Risiken und Annex-A-Kontrollen verknüpft, sodass diese im Zuge der Weiterentwicklung Ihres Unternehmens leicht überprüft und aktualisiert werden können.

Diese Informationen sind allgemeiner Natur und stellen keine Rechtsberatung dar; Organisationen sollten sich für regulatorische Entscheidungen entsprechend professionell beraten lassen.

Was Anhang A.5.21 tatsächlich erwartet

Anhang A.5.21 erwartet von Ihnen, dass Sie die Sicherheit der IKT-Lieferkette als kontinuierliche, gemeinsame Verantwortung und nicht als einmalige Vertragsklausel behandeln. Er bekräftigt die Auffassung, dass Erwartungen risikobasiert sein, dokumentiert und fortlaufend aktualisiert werden sollten, anstatt einmalig festgelegt und dann vergessen zu werden. Für Managed Service Provider (MSPs) bedeutet dies, Erwartungen für vorgelagerte und nachgelagerte Prozesse zu entwickeln und zu überprüfen, ob diese auch bei sich ändernden Diensten und Risiken weiterhin angemessen sind.

Anhang A.5.21 steht neben drei eng verwandten Kontrollmechanismen:

  • A.5.19, die Richtlinien für Lieferantenbeziehungen regelt.
  • A.5.20, die sich darauf konzentriert, sicherzustellen, dass die Informationssicherheit in Lieferantenverträgen berücksichtigt wird.
  • A.5.22, die sich mit der Überwachung, Überprüfung und dem Änderungsmanagement von Lieferantenleistungen befasst.

Zusammenfassend lassen sich diese Kontrollen wie folgt beschreiben: Identifizieren Sie Ihre IKT-Lieferkette, definieren Sie die von ihr erwarteten Informationssicherheitsanforderungen, integrieren Sie diese Anforderungen in die Auswahl, Vertragsgestaltung und Überwachung Ihrer Lieferanten und führen Sie die Überwachung auch bei sich ändernden Dienstleistungen fort. Anhang A.5.21 befasst sich konkret mit IKT-Dienstleistungen und -Produkten, sowohl in der vorgelagerten als auch in der nachgelagerten Wertschöpfungskette. Die Titel und Gruppierungen dieser Kontrollen entsprechen der in ISO/IEC 27001:2022 veröffentlichten Struktur. Diese Norm legt die Kontrollen des Anhangs A und ihre Schwerpunkte für die Sicherheit von Lieferanten und der IKT-Lieferkette fest (ISO/IEC 27001:2022 – Übersicht).

Für Managed Service Provider (MSPs) kommt eine zusätzliche Schwierigkeit hinzu. Sie sind sowohl Kunde als auch Lieferant. Sie sind auf vorgelagerte IT-Dienstleistungen angewiesen, um Ihre Angebote bereitzustellen, und spielen gleichzeitig eine entscheidende Rolle in den IT-Lieferketten Ihrer Kunden. Anhang A.5.21 erwartet von Ihnen, dass Sie beide Seiten konsequent und risikobasiert managen und dies in die täglichen Prozesse integrieren, anstatt es in isolierten Dokumenten zu regeln.

Standardtexte so umwandeln, dass sie jeder verstehen kann

Die Bereitschaft Ihrer Teams zur Mitarbeit steigt, wenn Sie die Sprache des Standards in wenige, klare und praktische Verpflichtungen übersetzen. Diese Verpflichtungen sollten beschreiben, was Sie tatsächlich tun – in einer Sprache, die Ingenieure, Account Manager und Rechtsabteilungen verstehen –, anstatt den Standard einfach zu zitieren.

Sie könnten Anhang A.5.21 beispielsweise wie folgt umformulieren:

  • „Wir prüfen und klassifizieren die IKT-Lieferanten und -Plattformen, auf die wir uns verlassen, und setzen sie ein, wenn sie die vereinbarten Sicherheitskriterien erfüllen.“
  • „Wir definieren und dokumentieren, wer in jedem von uns angebotenen Managed Service für welche Sicherheitsmaßnahmen verantwortlich ist.“
  • „Wir überwachen wichtige Lieferanten und Dienstleistungen im Laufe der Zeit und reagieren umgehend und transparent, wenn sich etwas ändert oder etwas schiefgeht.“

Sobald Ihnen diese Übersetzungen vorliegen, lässt sich viel leichter erkennen, wo Sie bereits Teile von Anhang A.5.21 implementiert haben, beispielsweise Lieferanten-Onboarding-Prüfungen, Vertragsvorlagen oder regelmäßige Überprüfungen. Außerdem wird deutlich, wo Vorgehensweisen ad hoc, nicht dokumentiert oder von einzelnen Mitarbeitern abhängig sind. Diese Übersicht dient als Ausgangspunkt für die anschließende detailliertere Gestaltung der vorgelagerten und nachgelagerten Prozesse.

Anhang A.5.21 verlangt, dass Ihre Anforderungen dem Risiko angemessen sind und nicht einfach von einer Geschäftsbeziehung auf eine andere übertragen werden. Lieferanten und Kunden mit hohem Einfluss erfordern in der Regel eine sorgfältigere Prüfung und stärkere Verpflichtungen als solche mit geringem Einfluss. Derselbe Grundsatz macht Ihre nachgelagerten Verträge gegenüber Aufsichtsbehörden und Wirtschaftsprüfern besser vertretbar.

Die Kontrolle bedeutet nicht, dass Sie an jeden Lieferanten oder Kunden identische, detaillierte Sicherheitsanforderungen stellen müssen. Sie verlangt vielmehr, dass Sie Ihre Erwartungen im Hinblick auf das Risiko begründen. Eine kritische Cloud-Plattform, die Kundendaten speichert, erfordert eine gründlichere Due-Diligence-Prüfung, strengere Vertragsklauseln und eine intensivere Überwachung als ein risikoarmes, nicht kritisches Tool.

Dasselbe Prinzip gilt auch für nachgelagerte Bereiche. Ein Managed Service für ein Krankenhaus oder ein Finanzinstitut unterliegt anderen Verpflichtungen und Kontrollen als ein Service für ein kleines, unreguliertes Unternehmen. Die Umsetzung von Anhang A.5.21 ist glaubwürdig, wenn diese Unterschiede in Ihren Risikobewertungen und der Gestaltung Ihrer Verträge sichtbar werden, nicht wenn in jeder Geschäftsbeziehung Formulierungen ohne Rücksicht auf die tatsächlichen Auswirkungen verwendet werden.

Die Angleichung von Anhang A.5.21 an bereits genutzte Rahmenwerke wie SOC 2, anerkannte Cybersicherheitsleitlinien oder nationale Empfehlungen für die Lieferkette kann hilfreich sein. Best-Practice-Leitlinien für die Lieferkette von Sicherheitsanbietern und -experten empfehlen, gemeinsame Kontrollziele über Standards wie ISO 27001, SOC 2 und nationale Cybersicherheitsrahmenwerke hinweg abzubilden, damit Teams nicht mehrere, sich widersprechende Anforderungssätze verwalten müssen (Überblick über Sicherheitspraktiken in der Lieferkette). „Tiering“ bedeutet hier lediglich, Lieferanten und Kunden anhand ihrer Auswirkungen in wenige Stufen einzuteilen, anstatt jede Beziehung als einzigartig zu behandeln.




ISMS.online verschafft Ihnen einen Vorsprung von 81 % ab dem Moment Ihrer Anmeldung

ISO 27001 leicht gemacht

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.




Upstream- vs. Downstream-Steuerungen im MSP-Kontext

In einem Managed Service Provider (MSP) umfasst „Upstream“ die Lieferanten, Plattformen und Subunternehmer, auf die Sie angewiesen sind, während „Downstream“ die Kunden und Mieter umfasst, die auf Sie angewiesen sind. Anhang A.5.21 lässt sich leichter umsetzen, wenn Sie diese Beziehungen als zwar getrennt, aber dennoch miteinander verbunden betrachten und klare Verantwortlichkeiten und Erwartungen in beide Richtungen definieren. Diese Struktur wandelt abstrakte Lieferkettenfragen in Verträge, Leitfäden und Dashboards um, auf deren Grundlage die Beteiligten handeln können.

Ein klares Upstream-/Downstream-Modell wandelt Standardtexte in praktikable Verträge, Betriebshandbücher und Dashboards um. Sie können definieren, wie Sie Lieferanten auswählen und überwachen, wie Sie die Verantwortung mit Kunden teilen und wie Sie auf Vorfälle in beiden Richtungen reagieren. Sobald diese Struktur schriftlich vorliegt, wird ihre Umsetzung in Tools und Verhaltensweisen deutlich einfacher.

Definition von Upstream-, Downstream- und Hybridbeziehungen

Ihre erste Aufgabe besteht darin, die externen Geschäftsbeziehungen, von denen Sie abhängig sind, zu benennen und zu klassifizieren, anstatt sie alle pauschal als „Lieferanten“ oder „Kunden“ zu behandeln. Diese Klassifizierung bestimmt, welche Teile von Anhang A.5.21 besonders relevant sind und worauf Sie Ihre Entwicklungsarbeit konzentrieren sollten. Sie schafft außerdem eine gemeinsame Sprache innerhalb Ihres Unternehmens, wenn Sie über Lieferkettenrisiken sprechen.

Beginnen Sie mit der Auflistung externer Parteien und klassifizieren Sie diese anhand zweier Kriterien: Liefern sie Ihnen Leistungen oder liefern Sie ihnen Leistungen? Und wie wichtig sind sie für Ihre Services? Ein vorgelagerter IT-Dienstleister könnte beispielsweise ein Cloud-Infrastrukturanbieter, ein Fernüberwachungstool, eine Backup-Plattform oder ein spezialisierter Sicherheitspartner sein. Nachgelagerte Parteien sind Ihre Managed-Service-Kunden, einschließlich derjenigen, bei denen Sie gemäß Datenschutzrecht als Auftragsverarbeiter fungieren.

Manche Geschäftsbeziehungen sind hybrid. Ein Managed Service Provider (MSP) im Rahmen einer Co-Managed-Vereinbarung stellt Ihnen bestimmte Funktionen zur Verfügung und ist im Gegenzug auf Ihre Dienste angewiesen. Ein Kunde, der seinen eigenen Cloud-Tenant hostet, Sie aber mit dessen Administration beauftragt, verwischt die Grenzen zwischen Kundenplattform und Upstream-Umgebung. Diese hybriden Beziehungen erfordern besondere Sorgfalt, da wichtige Verantwortlichkeiten leicht von beiden Seiten oder von keiner Seite übernommen werden können.

Sobald diese Rollen erfasst sind, können Sie festlegen, welche Kontrollkategorien für welche Rollen gelten. Bei vorgelagerten Geschäftsbeziehungen rücken Sorgfaltspflichten, sichere technische Integration, Meldung von Sicherheitsvorfällen und Kontrollen von Unterauftragnehmern in den Vordergrund. Bei nachgelagerten Geschäftsbeziehungen sind geteilte Verantwortung, grundlegende Sicherheitsanforderungen und Kundenpflichten wichtiger. Hybride Vereinbarungen erfordern eine Kombination verschiedener Ansätze und klare Abgrenzungen, um Sicherheitslücken zu vermeiden.

Nutzung risikobasierter Stufen zur Strukturierung

Risikobasierte Stufen machen aus einer langen Liste von Lieferanten und Kunden etwas, mit dem man arbeiten kann. Indem man Beziehungen in wenige wirkungsbasierte Klassen einteilt, kann man für jede Stufe Standard-Kontrollsets definieren, anstatt jede Beziehung von Grund auf neu zu gestalten.

Man könnte beispielsweise drei Stufen für vorgelagerte Lieferanten einrichten:

  • Tier 1: Kritische Plattformen mit privilegiertem Zugriff oder die Kundendaten hosten.
  • Tier 2: Wichtige Unterstützungsdienste mit eingeschränktem direktem Zugriff auf Kundensysteme.
  • Stufe 3: Tools mit geringem Risiko, die keinen Zugriff auf sensible Daten oder Produktionsumgebungen haben.

Im weiteren Verlauf könnten Sie je nach Sensibilität der Daten und den geschäftlichen Auswirkungen von Ausfällen verschiedene Stufen wie „reguliert“, „Hochverfügbarkeit“ und „Standard“ einführen.

Jede Kombination aus Upstream- und Downstream-Ebenen weckt unterschiedliche Erwartungen. Eine Upstream-Plattform der Stufe 1, die einen regulierten Kunden im Gesundheitswesen unterstützt, erfordert umfassendere Sicherheitsvorkehrungen und strengere Kontrollen als ein Tool der Stufe 2 für einen Standardkunden. Die Dokumentation dieser Kombinationen in einfachen Mustern – beispielsweise „MSP – Hyperscaler – regulierter Kunde“ versus „MSP – Distributor – MSP – Unternehmen“ – ermöglicht die Entwicklung standardisierter Kontrollsätze, anstatt für jede neue Beziehung von Grund auf neu beginnen zu müssen.

Eine prägnante Möglichkeit, dies zu veranschaulichen, bietet eine kleine Matrix, die zeigt, wie sich die Verantwortlichkeiten je nach Beziehungstyp unterscheiden.

Beziehungstyp Verantwortlichkeiten im Upstream-Bereich (Beispiele) Nachgelagerte Verantwortlichkeiten (Beispiele)
Managed Service Provider (MSP) – Cloud-Plattform – regulierter Kunde Zertifizierungen, Vorfallsmeldungen, Segmentierung, Zugriffsprotokolle Genehmigungen, Datenschutzpflichten, Kundensicherheitskommunikation
MSP – SaaS-Sicherheitstool – gemischte Kunden Sichere Integration, Rollengestaltung, Überwachung, Anbieterprüfung Kundenaufklärung über den Umfang des Werkzeugs, gegebenenfalls Zustimmung
MSP – Peer-MSP (gemeinsam verwaltet) – Kunde Abgrenzung, gemeinsame Vorfallbearbeitung, gemeinsamer Zugriff Der Kunde versteht die Aufgabenteilung und die Eskalationswege.

Wie die Tabelle zeigt, ändern sich die Verantwortlichkeiten beispielsweise zwischen einem Hyperscaler-Szenario und einer gemeinsam verwalteten MSP-Vereinbarung erheblich. In der Praxis können Sie damit beginnen, Ihre aktuellen Beziehungen einem dieser Muster zuzuordnen, die Zuständigkeiten festzulegen und anschließend Ihre Vertragsklauseln und internen Richtlinien entsprechend anzupassen.




Gestaltung von vorgelagerten Kontrollmechanismen für Lieferanten und Unterauftragnehmer

Die vorgelagerten Kontrollmechanismen definieren, wie Sie die von Ihnen genutzten Lieferanten und Plattformen auswählen, integrieren, überwachen und gegebenenfalls beenden. Ein einfacher, wiederholbarer Lebenszyklus wandelt das Vertrauen in Lieferanten von einer Annahme in einen durch Risikobewertungen, Verträge und Konfigurationen untermauerten Nachweis um. Anhang A.5.21 sieht vor, dass dieser Lebenszyklus dem Risiko angemessen ist und konsequent auf die wichtigsten Lieferanten angewendet wird.

Eine gute vorgelagerte Gestaltung wandelt Vertrauen von einer informellen Einschätzung in eine dokumentierte Entscheidung um. Das bedeutet, zu verstehen, was jeder Lieferant für Sie leistet, welche Risiken Sie übernehmen, welche Kontrollmechanismen er anwendet und welche Sie selbst implementieren müssen. Ein risikobasierter Lebenszyklus macht dies überschaubar und gibt den Prüfern die Gewissheit, dass Sie Lieferanten nicht als Blackbox behandeln.

Aufbau eines Lieferantenlebenszyklus, den Auditoren erkennen

Auditoren achten in der Regel auf einen klaren, risikobasierten Lebenszyklus für kritische Lieferanten: Wie Sie einen Lieferanten vor der Zusammenarbeit bewerten, wie Sie Kontrollen bei der Einführung implementieren, wie Sie die Überwachung aufrechterhalten und wie Sie die Zusammenarbeit sicher beenden. Wenn Sie diese Schritte und die dazugehörigen Nachweise darlegen können, wirkt Ihr Bericht gemäß Anhang A.5.21 glaubwürdig und vollständig. Leitlinien zum Lieferantenrisikomanagement von Instituten wie SANS beschreiben risikobasierte Lieferantenlebenszyklen – von der Auswahl über die Integration und die laufende Überwachung bis hin zum Ausstieg – als Kennzeichen eines ausgereiften Drittanbieter-Sicherheitsmanagements (SANS-Whitepaper zum Lieferantenrisikomanagement).

Der Bericht „State of Information Security 2025“ zeigt, dass die Mehrheit der Organisationen das Drittparteienrisikomanagement bereits gestärkt hat und plant, weiter darin zu investieren.

Ein praktischer Upstream-Lebenszyklus umfasst vier Phasen: Due-Diligence-Prüfung vor der Zusammenarbeit, Onboarding, laufende Überwachung und Ausstieg. Definieren Sie für jede Phase, was von den einzelnen Lieferantenstufen erwartet wird und welche Nachweise die Durchführung dieser Aktivitäten belegen sollen.

Schritt 1: Risikobasierte Due-Diligence-Prüfung durchführen

Risikobasierte Due Diligence dient dazu, ausreichend Informationen zu sammeln, um die Sicherheitslage eines Lieferanten zu verstehen und deren Übereinstimmung mit Ihren Anforderungen zu prüfen. Dies umfasst typischerweise unabhängige Zertifizierungen, allgemeine Sicherheitserklärungen, Zusammenfassungen von Tests, Informationen zu den Aufgaben bei der Verarbeitung personenbezogener Daten sowie zu Unterauftragnehmern. Das Ergebnis sollte ein vollständiger Bewertungsbericht sein, der erläutert, warum der Lieferant für die gewählte Stufe geeignet ist.

Schritt 2: Einbindung konkreter technischer und vertraglicher Kontrollen

Onboarding wandelt die Bewertung in konkrete Kontrollmaßnahmen um. Bei einer kritischen Plattform kann dies die Konfiguration einer starken Authentifizierung, die Beschränkung administrativer Rollen, die Aktivierung und Integration der Protokollierung sowie die Vereinbarung von Fristen und Ansprechpartnern für die Meldung von Vorfällen umfassen. Eine einfache Onboarding-Checkliste hilft sicherzustellen, dass diese Schritte nicht übersehen werden und für jeden Schritt eine klare Verantwortlichkeit festgelegt ist.

Schritt 3: Aufrechterhaltung der regulären Geschäftsaufsicht

Die routinemäßige Überwachung sollte unkompliziert, aber wirksam sein. Bei wichtigen Lieferanten sollten regelmäßige Überprüfungen durchgeführt werden, um sicherzustellen, dass Zertifizierungen gültig sind, Sicherheitszusagen weiterhin eingehalten werden und keine wesentlichen Änderungen ohne Ihr Wissen stattgefunden haben. Bei weniger wichtigen Lieferanten können Überprüfungen durch Ereignisse wie Serviceänderungen, neue Datenflüsse oder Vorfälle ausgelöst werden. Die Dokumentation dieser Überprüfungen, selbst wenn sie kurz ist, belegt, dass die Überwachung aktiv und nicht nur selbstverständlich ist.

Schritt 4: Sicher aussteigen und Ihre Lieferkettenkarte aktualisieren

Der Ausstieg wird oft übersehen, ist aber von entscheidender Bedeutung. Wenn Sie die Zusammenarbeit mit einem Lieferanten beenden oder zu einer neuen Plattform wechseln, sollte ein klar definierter Prozess für den Entzug von Zugriffsrechten, die Rückgabe oder sichere Löschung von Daten und die Aktualisierung Ihrer Dokumentation vorhanden sein, damit Ihre Lieferkettenübersicht weiterhin korrekt bleibt. Eine kurze Checkliste für den Ausstieg und ein aktualisierter Registereintrag belegen, dass Sie die Geschäftsbeziehung kontrolliert beendet haben.

Die Prüfer erwarten keine Perfektion, aber sie erwarten, dass ein solcher Lebenszyklus existiert, risikobasiert ist und in der Praxis für kritische Lieferanten eingehalten wird.

Kein Lieferant ist perfekt, und Anhang A.5.21 verlangt auch keine Perfektion. Er erwartet von Ihnen, dass Sie fundierte und dokumentierte Entscheidungen über die von Ihnen übernommenen Risiken und die angewandten kompensierenden Kontrollmaßnahmen treffen und diese Entscheidungen gegenüber Prüfern und Kunden erläutern können.

Nicht jeder Lieferant erfüllt alle idealen Kontrollanforderungen, und das muss auch nicht jeder. Entscheidend ist Ihre Fähigkeit, zu erklären, warum eine Geschäftsbeziehung angesichts des damit verbundenen Risikos akzeptabel ist. Eine gestaffelte Risikostruktur ist hilfreich, aber Sie benötigen auch Klarheit darüber, wann Sie die Kontrollen aus dem Sicherheitsrahmen eines Lieferanten übernehmen können und wann Sie kompensatorische Maßnahmen bevorzugen.

Wenn beispielsweise ein großer Cloud-Anbieter über anerkannte Zertifizierungen verfügt und hohe Sicherheitsstandards erfüllt, ist es in der Regel ratsam, sich bei vielen zugrunde liegenden Kontrollmechanismen darauf zu verlassen, vorausgesetzt, die Konfiguration wird sicher verwaltet. Bei einer kleineren, spezialisierten Plattform mit weniger formaler Zertifizierung kann man hingegen den Funktionsumfang einschränken, bestimmte vertragliche Verpflichtungen fordern oder eigene Überwachungs- und Testverfahren einführen.

Der Umgang mit Sicherheitsvorfällen verdient besondere Aufmerksamkeit. Für Kernplattformen sollten klare Zusagen darüber bestehen, wie schnell Sie über ein Sicherheitsproblem benachrichtigt werden, welche Informationen Sie erhalten und wie Sie die Maßnahmen zum Schutz Ihrer Kunden koordinieren können. Diese Erwartungen sollten am besten in Verträgen oder Servicevereinbarungen festgehalten werden, anstatt informelle Absprachen zu treffen.

Die Dokumentation dieser Beurteilungen in Ihrem Risikoregister und Ihrer Anwendbarkeitserklärung zeigt den Wirtschaftsprüfern, dass Anhang A.5.21 sorgfältig und nicht automatisch angewendet wird. Ihre Anwendbarkeitserklärung ist lediglich Ihre formale Liste der in Anhang A aufgeführten Kontrollen, in der Sie erläutern, welche Kontrollen anwendbar sind, wie und warum.




Klettern

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.




Gestaltung nachgelagerter Kontrollmechanismen für Kunden und deren Verpflichtungen

Downstream-Kontrollen definieren, wie Sie die Verantwortung mit Ihren Kunden teilen und was Sie von ihnen erwarten, um die Sicherheit der Dienste zu gewährleisten. Für Managed Service Provider (MSPs) verringern klare Downstream-Kontrollen das Risiko, für Sicherheitslücken verantwortlich gemacht zu werden, die beim Kunden liegen, und zeigen den Aufsichtsbehörden, dass Sie angemessene und dokumentierte Erwartungen formuliert haben. Anhang A.5.21 unterstreicht die Notwendigkeit, diese Erwartungen explizit, durchsetzbar und nachweisbar zu gestalten.

In der Praxis geht es bei der nachgelagerten Steuerung darum, Grenzen zu setzen und sicherzustellen, dass diese von allen verstanden werden. Sie definieren, was Sie standardmäßig tun, was Kunden tun müssen und wie Sie nachweisen, dass beide Seiten ihren Verantwortlichkeiten nachkommen. Wenn dies gut umgesetzt wird, basieren Gespräche über Vorfälle, neue Anforderungen oder zusätzliche Dienstleistungen auf einem gemeinsamen Verständnis und nicht auf Meinungsverschiedenheiten über die Verantwortlichkeit.

Entwicklung dienstleistungsspezifischer Modelle geteilter Verantwortung

Ein hilfreiches Modell geteilter Verantwortung erklärt Kunden in verständlicher Sprache, welche Sicherheitsaufgaben für einen bestimmten Dienst in Ihrer und welche in ihrer Verantwortung liegen. Da verschiedene Dienstfamilien unterschiedliche Aufteilungen aufweisen, benötigt jede ein eigenes, einfaches Modell, das die tatsächliche Gestaltung des Dienstes widerspiegelt. In diesem Kontext ist ein Modell geteilter Verantwortung schlichtweg eine klare Beschreibung der Aufteilung der Sicherheitsaufgaben zwischen Ihnen und dem Kunden.

Für jede Dienstfamilie soll ein Modell der gemeinsamen Verantwortung entwickelt werden, das drei Fragen beantwortet:

  • Welche Konfigurations- und Überwachungsfunktionen bieten Sie standardmäßig an?
  • Was muss der Kunde tun, damit dies gelingt?
  • Wie wollen Sie nachweisen, dass beide Seiten ihren Teil beitragen?

Bei einem verwalteten Microsoft 365-Dienst könnten Ihre Aufgaben beispielsweise die Konfiguration von Richtlinien für bedingten Zugriff, die Aktivierung der Protokollierung und die Überwachung wichtiger Warnmeldungen umfassen. Zu den Aufgaben des Kunden gehören die Pflege korrekter Benutzerdaten, die Durchsetzung von Nutzungsrichtlinien und die umgehende Reaktion auf Sicherheitsbenachrichtigungen. Die Einhaltung des Modells kann durch regelmäßige Konfigurationsberichte und dokumentierte Kundengenehmigungen nachgewiesen werden.

Diese Modelle sollten in verständlicher Sprache verfasst, in Verträgen und Angeboten wiederverwendet und durch interne Leitfäden ergänzt werden, die Ihren Teams zeigen, wie sie ihren Teil der Vereinbarung erfüllen können. Wenn Kunden das Modell von Anfang an verstehen, basieren spätere Gespräche über Sicherheitsvorfälle oder zusätzliche Verpflichtungen auf diesem gemeinsamen Verständnis und nicht auf spontanen Erwartungen.

Festlegung von Kundenpflichten und Umgang mit Nichteinhaltung

Kundenpflichten beschreiben, was Kunden tun müssen, damit Ihre Dienstleistungen effektiv genutzt werden und ihr eigenes Risiko in einem akzeptablen Rahmen bleibt. Anhang A.5.21 erwartet von Ihnen, dass Sie diese Pflichten klar definieren, deren Einhaltung nach Möglichkeit überwachen und im Voraus festlegen, wie Sie mit etwaigen Lücken umgehen.

Zu den nachgelagerten Kontrollmaßnahmen gehören häufig Verpflichtungen wie:

  • Wartung der unterstützten Betriebssysteme.
  • Sicherstellen, dass die Mitarbeiter eine Schulung zum Thema Sicherheitsbewusstsein absolvieren.
  • Aktivierung der Multi-Faktor-Authentifizierung auf den eigenen Systemen.
  • Wir werden Sie umgehend über relevante Änderungen in ihrem Umfeld informieren.

Diese Verpflichtungen sollten dem Dienstleistungs- und Risikoprofil angemessen sein, in Verträgen oder Sicherheitsplänen festgehalten und durch einfache Mechanismen zur Nachweiserhebung unterstützt werden. Dazu gehören beispielsweise regelmäßige Bestätigungen, technische Prüfungen (sofern einsehbar) oder Ergebnisse gemeinsamer Überprüfungen.

Es ist ebenso wichtig, im Voraus festzulegen, wie Sie mit Nichteinhaltung umgehen. Manche Verstöße lassen sich abmildern; andere können zu Ausnahmen, zusätzlichen Gebühren oder, im Extremfall, zur Verweigerung der Leistungserbringung führen.

Schritt 1: Definieren, wie Nichteinhaltung festgestellt wird

Entscheiden Sie, welche Verpflichtungen Sie technisch überprüfen können und welche auf Kundenbestätigungen oder Besprechungen angewiesen sind. Integrieren Sie die Prüfungen in Ihre Prozesse oder Tools, damit Verstöße sichtbar werden.

Schritt 2: Entscheiden Sie, wer Ausnahmen gewähren und genehmigen kann.

Dokumentieren Sie, welche Rollen unter welchen Bedingungen und für welchen Zeitraum befristete Ausnahmen genehmigen können. Dadurch werden spontane Kompromisse vermieden, die später dauerhaft werden.

Schritt 3: Restrisiko erfassen und überprüfen

Stellen Sie sicher, dass Ausnahmen und Fälle von Nichteinhaltung in Ihrem Risikoregister erfasst und in den entsprechenden Gremien geprüft werden. Dies zeigt, dass Sie das Restrisiko managen und nicht ignorieren.

Klare nachgelagerte Modelle und Verpflichtungen sind für erfahrene Kunden attraktiv. Sie zeigen, dass Sie deren Risiko ernst nehmen und bereit sind, sinnvolle Grenzen zu setzen und einzuhalten, anstatt vagen, nicht durchsetzbaren Versprechen zuzustimmen.




Governance, Rollen und Lebenszyklus für die Lieferkettenkontrolle

Die Sicherheit der Lieferkette ist nur dann skalierbar, wenn eine klare Verantwortlichkeit besteht und alle im Unternehmen ihren Beitrag dazu verstehen. Anhang A.5.21 wird nachhaltig, wenn er in die Unternehmensführung integriert wird – mit definierten Rollen, Verantwortlichkeiten und regelmäßigen Überprüfungen – und nicht als informelle Nebensache der Sicherheit behandelt wird. Effektive Unternehmensführung bedeutet weniger, neue Meetings anzusetzen, sondern vielmehr, in den bestehenden Meetings die richtigen Fragen zu stellen.

Wenn die Sicherheit der Lieferkette als „jemandes Problem“ ohne klare Vorgaben behandelt wird, verliert sie an Bedeutung. Es muss festgelegt werden, wer für die Kontrolle verantwortlich ist, wer Input liefert, wer bestimmte Aufgaben übernimmt und wie oft die Leistung überprüft wird. Gute Unternehmensführung basiert auf klaren Entscheidungen und regelmäßigem Feedback, nicht auf noch mehr Meetings.

Eine effektive Lieferkettensteuerung bedeutet, in bestehenden Meetings bessere Fragen zu stellen.

Zuweisung von Verantwortlichkeiten und RACI-Matrix im gesamten Unternehmen

Ein benannter Verantwortlicher gibt Anhang A.5.21 eine klare Zuständigkeit, doch der Erfolg hängt von der koordinierten Zusammenarbeit zwischen Einkauf, Betrieb, Rechtsabteilung und Kundenbetreuung ab. Ein einfaches RACI-Modell verdeutlicht, wer welche Aufgaben übernimmt, wer Genehmigungen erteilt und wer bei Änderungen der Lieferanten- oder Kundenrisiken informiert werden muss.

Ein praktischer erster Schritt ist die Benennung eines Verantwortlichen für die Kontrollmaßnahme gemäß Anhang A.5.21, häufig des Informationssicherheitsbeauftragten oder des virtuellen CISO. Diese Person ist dafür verantwortlich, dass die Kontrollmaßnahme konzipiert ist und funktioniert, kann sie aber nicht allein umsetzen. Einkauf, Rechtsabteilung, Betrieb und Kundenbetreuung spielen dabei eine wichtige Rolle.

Eine einfache RACI-Matrix (Verantwortlich, Rechenschaftspflichtig, Beratend, Informiert) ist hilfreich. Zum Beispiel für die Einarbeitung eines neuen Tier-1-Lieferanten:

  • Die Einkaufsabteilung ist dafür verantwortlich, dass die vereinbarten Sicherheitsklauseln im Vertrag enthalten sind.
  • Der Informationssicherheitsbeauftragte ist verantwortlich für die Genehmigung der Risikobewertung und der Einstufung des Lieferanten.
  • Bei komplexen Begriffen, Ausnahmen und Haftungsfragen wird die Rechtsabteilung konsultiert.
  • Die Bereiche Operations und Account Management werden über Verpflichtungen informiert, die sich auf die Art und Weise der Leistungserbringung auswirken.

Wenn diese Verteilung klar ist, hören die Kollegen auf, Anhang A.5.21 als „Problem der ISO-Person“ zu betrachten und beginnen, ihren eigenen Beitrag zur Erfüllung dieser Anforderung zu verstehen.

Auswahl von Governance-Rhythmen, die zu den Abläufen passen

Governance funktioniert am besten, wenn Fragen zur Lieferkette in ohnehin relevante Meetings integriert werden, beispielsweise in Risikoausschüsse, Managementbewertungen und Service-Reviews. Anhang A.5.21 erfordert keine neue Bürokratie; er verlangt lediglich, dass Sie die richtigen Fragen zu Lieferanten und Kunden zum richtigen Zeitpunkt stellen und die Antworten dokumentieren.

Kontrollmechanismen bleiben eher wirksam, wenn sie auf Rhythmen basieren, die die Organisation bereits respektiert. Für die Sicherheit der Lieferkette könnte dies Folgendes bedeuten:

  • Die Aufnahme wichtiger Lieferanten- und Kundenrisikothemen in die Tagesordnung bestehender Risiko- oder Serviceprüfungsausschüsse.
  • Regelmäßige Überprüfungen kritischer Lieferanten und Hochrisikokunden im Einklang mit Vertragszyklen oder wesentlichen Änderungen einplanen.
  • Überprüfung von Vorfällen und Beinaheunfällen im Zusammenhang mit der Lieferkette in Nachbesprechungen und Einbeziehung der gewonnenen Erkenntnisse in das Lieferanten- und Kundenmanagement.

Vermeiden Sie die Bildung gänzlich neuer Ausschüsse, es sei denn, diese sind unbedingt erforderlich. Integrieren Sie stattdessen Anhang A.5.21 in bestehende Governance-Gremien. Beispielsweise kann Ihre Managementbewertung nach ISO 27001 die Leistung anhand von Lieferkettenindikatoren explizit abdecken, etwa die Anzahl kritischer Lieferanten ohne aktuelle Bewertungen, die Häufigkeit lieferantenbezogener Vorfälle oder die Pünktlichkeit der Vorfallsmeldungen.

Die Governance sollte sich auch auf weniger sichtbare Beziehungen erstrecken, beispielsweise auf Subunternehmer für die Rufbereitschaft außerhalb der Geschäftszeiten oder White-Label-Anbieter, die Dienstleistungen unter Ihrer Marke erbringen. Ohne sie ist das Bild der Lieferkette unvollständig, und Vorfälle mit diesen Parteien können genauso schädlich sein. Sicherzustellen, dass sie in die Risikobewertung, die vertraglichen Kontrollen und die Aufsicht einbezogen werden, ist Teil einer glaubwürdigen Umsetzung von Anhang A.5.21.




ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.

ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.




Integration von A.5.19–A.5.22 mit Risiko-, Lieferanten- und Änderungsprozessen

Die Anhänge A.5.19–A.5.22 entfalten ihre volle Wirkung, wenn sie in Ihre bestehenden Prozesse für Risikomanagement, Lieferantenmanagement, Änderungsmanagement und Vorfallbearbeitung integriert werden. Anstatt als isolierte „ISO-Aufgaben“ zu fungieren, sollten sie in Ihr Risikoregister, Ihren Beschaffungsprozess, Ihr Änderungsmanagement und Ihre Nachbesprechungen von Vorfällen einfließen, damit die Lieferkettenstrategie Teil Ihrer täglichen Arbeit wird. Diese Integration führt dazu, dass Richtlinien in konsequentes Handeln umgesetzt werden.

Zwei Drittel der Organisationen, die an der Studie „State of Information Security 2025“ teilnahmen, gaben an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Einhaltung der Vorschriften zunehmend erschweren.

Die Entwicklung von Richtlinien und Modellen ist notwendig, aber nicht ausreichend. Lieferkettenkontrollen sind nur dann wirksam, wenn sie in die Formulare, Tickets und Arbeitsabläufe integriert sind, die Mitarbeiter bereits für Änderungsanforderungen, die Einführung neuer Tools, die Risikobewertung und die Reaktion auf Vorfälle nutzen. Die Anhänge A.5.19–A.5.22 sind am effektivsten, wenn sie sich in der Risikoerfassung, der Lieferantenentscheidung, der Genehmigung von Änderungen und der Auswertung von Vorfällen widerspiegeln.

Integration des Lieferkettendenkens in alltägliche Arbeitsabläufe

Der erste Schritt besteht darin, die Risiken der IKT-Lieferkette neben anderen Risiken sichtbar zu machen. Das bedeutet, explizite Risikoeinträge für kritische Dienstleistungen und Lieferanten zu erstellen und festzuhalten, wie Sie mit diesen Risiken umgehen wollen. Sobald dies umgesetzt ist, können Sie kleine, obligatorische Kontrollpunkte in die bestehenden Arbeitsabläufe Ihres Teams integrieren, sodass Entscheidungen über Lieferanten und Änderungen automatisch den Anforderungen von Anhang A entsprechen.

Stellen Sie zunächst sicher, dass Ihr zentrales Risikoregister die Risiken der IKT-Lieferkette explizit erfasst. Für jeden wichtigen Dienst und kritischen Lieferanten sollten Risikoeinträge vorhanden sein, die die potenziellen Auswirkungen eines Ausfalls oder einer Beeinträchtigung sowie die gewählten Gegenmaßnahmen widerspiegeln. Dadurch werden Lieferkettenrisiken anderen Schwachstellen gegenübergestellt und die Führungsebene kann die Abwägungen besser verstehen.

Als nächstes sollten Kontrollpunkte der Lieferkette in bestehende Arbeitsabläufe integriert werden:

  • Die Beschaffungsprozesse sollten Hinweise enthalten, um zu prüfen, ob ein vorgeschlagener Lieferant in eine bestimmte Risikokategorie fällt, ob die Sorgfaltsprüfung abgeschlossen wurde und ob die Vertragsvorlagen die erforderlichen Sicherheitsklauseln enthalten.
  • Änderungsanträge, die wichtige Werkzeuge oder Unterprozessoren einführen oder ersetzen, sollten automatisch eine Überprüfung der Auswirkungen auf vorgelagerte und nachgelagerte Systeme auslösen, nicht nur der technischen Kompatibilität.
  • Die Gestaltung von Dienstleistungen oder Onboarding-Prozessen für neue Kunden sollte Schritte beinhalten, um das geeignete Modell der geteilten Verantwortung anzuwenden und sicherzustellen, dass die nachgelagerten Verpflichtungen dokumentiert und akzeptiert werden.

Diese Eingabeaufforderungen lassen sich oft problemlos in Formulare und Ticketvorlagen integrieren, vorausgesetzt, sie sind für die relevanten Szenarien obligatorisch und die Antworten werden zentral erfasst, sodass sie in Ihre ISMS-Aufzeichnungen zurückfließen.

Leistungsmessung und Lernen aus Vorfällen

Man kann nicht verbessern, was man nicht sieht. Anhang A.5.21 gewinnt deutlich an Wert, wenn Sie die Wirksamkeit Ihrer Lieferkettenkontrollen überwachen und Erkenntnisse aus Vorfällen in Ihre Prozesse, Vorlagen und Handlungsanweisungen einfließen lassen. Ziel ist es nicht, alle Kennzahlen auf null zu reduzieren, sondern die größten Risiken in Ihrer Lieferkette zu identifizieren und nachzuweisen, dass Sie diese im Griff haben.

Sobald die Steuerungssysteme funktionieren, benötigen Sie Feedback, um sie zu verbessern. Sinnvolle Maßnahmen könnten beispielsweise sein:

  • Der Anteil kritischer Lieferanten mit aktuellen Risikobewertungen und dokumentierten Sicherheitsverpflichtungen.
  • Die Anzahl und Schwere der Vorfälle, deren Ursache in einer vorgelagerten oder nachgelagerten Beziehung lag.
  • Die Zeit, die benötigt wird, um über relevante Vorfälle bei Lieferanten informiert zu werden und mit den betroffenen Kunden zu kommunizieren.
  • Die Rate der Nichteinhaltung wichtiger nachgelagerter Verpflichtungen durch die Kunden und wie oft Ausnahmen gewährt werden.

Bei Vorfällen sollte die Ursachenanalyse gezielt zwischen Fehlern in vorgelagerten Prozessen, internen Problemen und Schwächen in nachgelagerten Prozessen unterscheiden. Diese Unterscheidung zeigt, wo Sie Erwartungen präzisieren, Ihre eigenen Vorgehensweisen verbessern oder Kundenverpflichtungen anpassen müssen. Indem Sie diese Erkenntnisse in die Lieferantenklassifizierung, Vertragsvorlagen und Handlungsanweisungen einfließen lassen, gestalten Sie die Umsetzung von Anhang A.5.21 iterativ und nicht statisch.

Eine dedizierte ISMS-Plattform hilft Ihnen, Lieferanten, Dienstleistungen, Kunden, Risiken und Kontrollen zentral zu verknüpfen, sodass sich eine einzelne Änderung oder ein Vorfall über alle betroffenen Beziehungen hinweg nachverfolgen lässt. Selbst wenn Sie noch nicht bereit sind, eine solche Plattform sofort einzuführen, ist die Gestaltung Ihrer Prozesse, um die notwendigen Daten später zentral erfassen zu können, ein pragmatischer Schritt hin zu einem stärker integrierten ISMS.




Buchen Sie noch heute eine Demo mit ISMS.online

ISMS.online unterstützt Sie dabei, die Anforderungen von Anhang A.5.21 von verstreuten Lieferantenlisten und Vertragsklauseln in ein einheitliches, dynamisches Bild Ihrer ITK-Lieferkette, -Kontrollen und -Nachweise zu überführen. Durch die Ersetzung von Tabellenkalkulationen, E-Mail-Verläufen und isolierten Dokumenten durch eine vernetzte Umgebung erhalten Sie einen besseren Überblick über vorgelagerte und nachgelagerte Beziehungen, können Verantwortlichkeiten nachverfolgen und schwierige Fragen von Kunden und Auditoren souveräner beantworten.

Wenn Sie vermuten, dass die Beantwortung eines komplexen Kundenfragebogens oder ein ISO 27001:2022-Audit immer noch zu Hektik führen würde, ist dies ein Hinweis darauf, einen strukturierteren Ansatz zu verfolgen. Eine klare Darstellung Ihrer vorgelagerten und nachgelagerten Beziehungen, in der Verantwortlichkeiten und Risiken auf einen Blick erkennbar sind, vermittelt Ihnen gegenüber Kunden, Auditoren und der Geschäftsleitung mehr Sicherheit.

Wie Sie A.5.21 in einem Teil Ihrer Lieferkette pilotieren

Ein fokussiertes Pilotprojekt ist der einfachste Weg, um zu sehen, wie Anhang A.5.21 aussieht, wenn er vollständig in ein ISMS integriert ist. Anstatt zu versuchen, Ihr gesamtes Umfeld auf einmal abzubilden, konzentrieren Sie sich auf einen kleinen, repräsentativen Ausschnitt Ihrer Lieferkette und testen, ob die Struktur und die Werkzeuge tatsächlich Aufwand und Unsicherheit reduzieren.

Ein praktisches Pilotprojekt könnte mit einer kritischen vorgelagerten Plattform und einem Hochrisikokunden beginnen. Diese Beziehungen lassen sich in ISMS.online importieren, den Anhängen A.5.19–A.5.22 zuordnen und die wichtigsten Dokumente erfassen: Lieferantenrisikobewertungen, Modelle zur gemeinsamen Verantwortung, Kundenverpflichtungen und Nachweise zur Überwachung. Innerhalb dieses begrenzten Rahmens lässt sich feststellen, ob die Plattform den Aufwand spürbar reduziert, die Verantwortlichkeiten klärt und die Vorbereitung auf Fragen von Auditoren und Kunden verbessert.

Durch die bewusst kleine Pilotphase behalten Sie die Kontrolle über den Umfang und vermeiden eine Überlastung der ohnehin schon ausgelasteten Teams. Gleichzeitig erhalten Sie konkrete Beispiele – beispielsweise einen ausgefüllten Eintrag im Risikoregister, einen dokumentierten Lieferantenlebenszyklus oder eine Matrix zur gemeinsamen Verantwortung –, die Sie Kollegen und der Führungsebene präsentieren können, um die Skalierung des Ansatzes zu besprechen.

Was Sie zu einem Gespräch auf ISMS.online mitbringen sollten

Sie profitieren am meisten von einem Gespräch über ISMS.online, wenn Sie mit einem kurzen Überblick über Ihre aktuelle Lieferkette und die damit verbundenen Herausforderungen kommen. Eine kurze Vorbereitung erleichtert es, zu erkennen, wie die Plattform Ihre spezifische Situation unterstützen kann und ob sie für Ihr Unternehmen geeignet ist.

Nützliche Eingaben sind typischerweise:

  • Eine Liste Ihrer wichtigsten vorgelagerten ICT-Lieferanten und der von ihnen unterstützten Dienstleistungen.
  • Eine Vorauswahl von Kunden mit hohem Einfluss, insbesondere solchen aus regulierten Sektoren.
  • Alle bestehenden Dokumente, die gemeinsame Verantwortlichkeiten, Kundenverpflichtungen oder Lieferantenerwartungen beschreiben.
  • Beispiele für kürzlich aufgetretene, schwer zu bewältigende Vorfälle im Zusammenhang mit Lieferanten oder Kunden.

Anhand dieser Informationen kann das ISMS.online-Team Ihnen veranschaulichen, wie Ihre realen Beziehungen innerhalb der Plattform aussehen würden und wie Anhang A.5.19–A.5.22 in der Praxis umgesetzt werden. Ziel ist es nicht, eine Standardlösung vorzuschlagen, sondern anhand Ihrer Beispiele zu zeigen, wie ein vernetztes ISMS Anhang A.5.21 vereinfachen und Ihre Lieferkettenstruktur verbessern kann.

Wenn Sie Ihre eigene Organisation in diesen Szenarien wiedererkennen und einen stärker integrierten Ansatz testen möchten, ist ISMS.online bereit, mit Ihnen ein gezieltes Pilotprojekt durchzuführen, bei dem Ihre tatsächlichen Lieferanten und Kunden zum Einsatz kommen, um herauszufinden, ob ein vernetztes ISMS der richtige nächste Schritt für Ihren MSP ist.

Kontakt



Häufig gestellte Fragen (FAQ)

Wie verändert Anhang A.5.21 der ISO 27001:2022 die Art und Weise, wie ein Managed Service Provider (MSP) über seine ICT-Lieferkette denken sollte?

Anhang A.5.21 erwartet von Ihnen, dass Sie Ihre ICT-Lieferkette als einheitliches, gesteuertes System von der Cloud-Plattform bis zum Kundenergebnis betreiben und nicht als eine Ansammlung voneinander unabhängiger Anbieter, Tools und Verträge. Für einen Managed Service Provider (MSP) bedeutet dies, dass Sie einen aktuellen und nachvollziehbaren Überblick darüber benötigen, wie vorgelagerte Anbieter, Ihre eigenen Services und nachgelagerte Kunden miteinander verknüpft sind und wie Sie die Risiken entlang dieser Kette managen.

Was bedeutet „durchgängige ICT-Lieferkette“ konkret für einen Managed Service Provider (MSP)?

End-to-End bedeutet, dass Sie mit einem einzelnen Dienst beginnen und diesen nachverfolgen können:

  • Welche IKT-Produkte und -Dienste Sie verlassen sich darauf, dass er es liefert.
  • Wie dein eigene Plattformen und Prozesse Setz dich in die Mitte.
  • Welche Kunden oder Kundensegmente sind betroffen, wenn etwas kaputt geht.

Anstatt „Wir nutzen Anbieter X und bedienen Kunde Y“ geht Anhang A.5.21 davon aus, dass Sie den gesamten Prozess verstehen und steuern: Cloud/Plattformen → MSP-Tools und -Prozesse → KundenumgebungenWenn eine Kernplattform ausfällt oder kompromittiert wird, sollten Sie bereits wissen, welche Dienste und Mandanten betroffen sind und was Sie dagegen unternehmen werden.

In der Praxis bedeutet das, dass Sie Folgendes können:

  • Verweisen Sie auf ein Lieferantenregister, das ICT-Anbieter Dienstleistungen und Risikoklassen zuordnet.
  • Erklären Sie in einfachen Worten, wer (Sie, der Lieferant, der Kunde) bei den einzelnen Dienstleistungsarten welche Aufgaben übernimmt.
  • Zeigen Sie, dass dieses Bild auch bei Änderungen von Dienstleistungen, Lieferanten oder Vorschriften aktuell bleibt.

Wenn Sie einen Prüfer anhand alltäglicher Aufzeichnungen und nicht anhand eines einmaligen „Prüfpakets“ durch diese Etage führen können, behandeln Sie Anhang A.5.21 als Teil Ihrer Geschäftstätigkeit, und genau das erwarten die Prüfer.


Wie baut Anhang A.5.21 auf den anderen Lieferantenkontrollen gemäß Anhang A.5 für einen Managed Service Provider auf?

Anhang A.5.21 greift die allgemeinen Lieferantenthemen aus A.5.19, A.5.20 und A.5.22 auf und wendet sie speziell auf die ITK-Infrastruktur an, die Ihren Managed Services zugrunde liegt. Es geht weniger um die Entwicklung neuer Prozesse, sondern vielmehr darum, Lieferantenauswahl, Verträge, Überwachung und Änderungsmanagement in einem kohärenten Ansatz für ITK-Produkte und -Dienstleistungen zu vereinen.

Wie fügen sich die Lieferantenkontrollen gemäß Anhang A.5 in die ICT-Lieferkette eines Managed Service Providers ein?

Man kann sich die vier Steuerungselemente als einen einzigen Ablauf vorstellen:

  • A.5.19 – Informationssicherheit in Lieferantenbeziehungen: Entscheiden Sie, wo Sicherheit in Ihrer Lieferantenlandschaft eine Rolle spielt und wie Sie diese bei Ihren Entscheidungen berücksichtigen.
  • A.5.20 – Berücksichtigung der Informationssicherheit in Lieferantenverträgen: Diese Erwartungen werden in klare Klauseln, Anhänge und Leistungsbeschreibungen umgewandelt.
  • A.5.21 – Management der Informationssicherheit in der IKT-Lieferkette: Wenden Sie diese Denkweise auf das spezifische Geflecht von ICT-Plattformen, Tools und Integrationen an, die unter Ihre Managed Services fallen.
  • A.5.22 – Überwachung, Überprüfung und Änderungsmanagement von Lieferantenleistungen: Lieferantenrisiken und -leistungen regelmäßig überprüfen und auf Vorfälle und Veränderungen reagieren.

Für einen Managed Service Provider (MSP) bedeutet dies in der Regel drei sichtbare Fähigkeiten:

  • A Zusammengeführtes Register wo ICT-Anbieter an Dienstleistungen, Risikobewertungen und vertragliche Verpflichtungen gebunden sind.
  • A konsistentes Muster für die Art und Weise, wie Sie ICT-Lieferanten einbinden, überwachen und beenden, und nicht für einmalige Entscheidungen per E-Mail.
  • A nachverfolgbare Verbindung von diesen Aktivitäten bis hin zu kundenorientierten Versprechen und Ihrem internen Risikoregister.

Die Nutzung einer Plattform wie ISMS.online erleichtert die Verknüpfung dieser Informationen, da Lieferanten, Verträge, Risiken und die Kontrollen gemäß Anhang A.5.19–A.5.22 zentral verwaltet werden können. So können Sie Prüfern und Kunden nachweisen, dass Sie eine ITK-Lieferkette managen und nicht nur eine Sammlung von Verträgen.


Wie sollte ein Managed Service Provider (MSP) einen vorgelagerten ICT-Anbieterlebenszyklus gestalten, der die Anforderungen von Anhang A.5.21 erfüllt, ohne das Team zu überlasten?

Die effektivste Methode, die Anforderungen von Anhang A.5.21 im Vorfeld zu erfüllen, besteht darin, einen einheitlichen, wiederholbaren Lieferantenlebenszyklus zu definieren und die Prüftiefe risikobasiert und nicht nach dem Prinzip „Vermutung“ anzupassen. Ihr Team muss nur ein einziges Muster erlernen, und die intensive Due-Diligence-Prüfung behalten Sie sich für die Lieferanten vor, die Ihnen oder Ihren Kunden wirklich schaden können.

Wie sieht ein praktischer, wiederholbarer ICT-Anbieterlebenszyklus für einen Managed Service Provider (MSP) aus?

Ein einfacher vierstufiger Lebenszyklus bringt in der Regel Aufwand und Sicherheit in Einklang:

  • Wähle bitte: Bevor Sie einen Vertrag abschließen, sollten Sie den Lieferanten nach seinen Auswirkungen einstufen. Eine Plattform, die Kundendaten verarbeitet oder zentraler Bestandteil Ihrer Remote-Management-Infrastruktur ist, erfordert eine gründlichere Prüfung als ein einfaches Hilfsprogramm.
  • Am Bord: Setzen Sie Ihre Erwartungen in konkrete Kontrollmechanismen um. Konfigurieren Sie Zugriffsrechte, Protokollierung, Änderungsbenachrichtigungen, Supportkanäle und Exit-Bedingungen, bevor Sie live gehen.
  • Operieren: Überprüfen Sie Leistung und Risiken in angemessenen Abständen. Planen Sie für kritische Plattformen mindestens eine jährliche Überprüfung sowie Kontrollen nach Sicherheitswarnungen, Vorfällen oder wesentlichen Serviceänderungen ein.
  • Exit: Planen Sie, wie Sie Daten entfernen oder migrieren, Zugriffsrechte entziehen, Abhängigkeiten ändern und Ihre eigene Dokumentation aktualisieren, wenn Sie einen Lieferanten verlassen oder dessen Leistung herabstufen.

Sie benötigen keine komplexen Tools, um nachzuweisen, dass Sie diesen Lebenszyklus einhalten. Ein gepflegtes Lieferantenregister, kurze Due-Diligence-Prüfungsberichte, einfache Checklisten für die Einarbeitung und grundlegende Prüfprotokolle signalisieren den Auditoren bereits deutlich, dass Sie ITK-Anbieter als Teil Ihres ISMS behandeln.

ISMS.online optimiert dies zusätzlich, indem es das Lieferantenregister, die Nachweise zum Produktlebenszyklus und die zugehörigen Kontrollen gemäß Anhang A.5.19–A.5.22 in einer zentralen Umgebung zusammenführt. So bleibt der Prozess für Ihr Team schlank und gleichzeitig wird Kunden, Auditoren und Partnern ein klares und einheitliches Bild vermittelt.


Wie kann ein Managed Service Provider (MSP) die nachgelagerten, gemeinsam mit den Kunden getragenen Verantwortlichkeiten so definieren, dass Anhang A.5.21 abgedeckt ist, ohne jeden Vertrag in einen juristischen Roman zu verwandeln?

Downstream, Anhang A.5.21 ist erfüllt, wenn Ihre Kunden in verständlicher Sprache erkennen können, welche Standardabsicherungen Sie gewährleisten, was sie selbst tun müssen und wie Sie bei Änderungen oder Problemen zusammenarbeiten. Sie benötigen keine individuell angepassten Rechtstexte für jedes Geschäft, aber einige wenige, von Ihren Teams verstandene und konsequent angewandte Muster für die gemeinsame Verantwortung.

Wie sieht ein praktikables Modell der geteilten Verantwortung für gängige MSP-Dienstleistungen aus?

Ein praktisches Vorgehen besteht darin, Modelle nach Servicefamilie zu standardisieren und die Struktur stets identisch zu halten. Definieren Sie für jede Familie vier Blöcke:

  • Leistungsumfang: Was dieser Managed Service umfasst und was nicht.
  • Deine Verantwortungen: Zum Beispiel: Basiskonfiguration, Protokollierung, Datensicherung, Überwachung, Umgang mit Sicherheitslücken und Koordination von Sicherheitsvorfällen.
  • Pflichten des Kunden: Zum Beispiel die Aufrechterhaltung der Unterstützung von Endpunkten, die Durchsetzung der Multi-Faktor-Authentifizierung, die Verwaltung von Neuzugängen und Abgängen sowie die Benachrichtigung über wichtige Änderungen.
  • Gemeinsame Verantwortlichkeiten: Beispiele hierfür sind Zugriffsüberprüfungen, die Genehmigung risikoreicher Änderungen oder die Durchführung von Störungsmeldungen.

Diese Modelle lassen sich dann auf verschiedene Weisen ausdrücken:

  • Kurz Verantwortungsmatrizen in Angeboten, Leistungsbeschreibungen und Einarbeitungsdokumenten.
  • Sicherheitszusätze: die an Verträge angehängt werden, ohne die gesamten Vertragsbedingungen neu zu formulieren.
  • Interne Runbooks: die Ihre Teams beim Onboarding, im Betrieb und bei der Bearbeitung von Vorfällen verwenden.

Wenn ein Kunde eine Ausnahme benötigt, dokumentieren Sie diese Abweichung explizit, anstatt das Modell stillschweigend zu erweitern. Sobald diese Muster und Ausnahmen in Ihrem ISMS erfasst und in Ihrem Risikoregister abgebildet sind, können Sie nachweisen, dass nachgelagerte Risiken gezielt und nicht informell behandelt werden. Genau das soll Anhang A.5.21 überprüfen.

ISMS.online bietet Ihnen einen zentralen Ort, um diese Modelle zu speichern und wiederzuverwenden, sie mit bestimmten Diensten und Kunden zu verknüpfen und Vertragstexte, interne Leitfäden und Risikoeinträge im Zuge des Wachstums Ihres Portfolios aufeinander abzustimmen.


Wie kann ein Managed Service Provider (MSP) ein komplexes Geflecht aus Anbietern, Plattformen und Kunden in eine übersichtliche Risikokarte der ICT-Lieferkette umwandeln, die den Prüfungen gemäß Anhang A.5.21 standhält?

Die einfachste Methode, eine aussagekräftige Risikokarte für die Lieferkette zu erstellen, besteht darin, von den tatsächlichen Abläufen Ihrer Dienstleistungen auszugehen, anstatt mit einer statischen Lieferantenliste. Wenn Sie Datenflüsse und Kontrollpunkte von links nach rechts verfolgen, werden die für Anhang A.5.21 relevanten Zusammenhänge in der Regel deutlich.

Welche praktischen Schritte erstellen eine ICT-Lieferkettenlandkarte, der Prüfer folgen können?

Sie können die Karte in drei unabhängigen Schritten erstellen, die sich gegenseitig verstärken:

  1. Serviceansicht: Listen Sie Ihre Managed Services auf (z. B. Managed Microsoft 365, Managed Endpoints, Managed Backup, Co-Managed Cloud) und vermerken Sie, von welchen Upstream-Plattformen, Tools und Integrationen jeder einzelne Service abhängt.
  2. Beziehungsansicht: Für jeden Dienst eine Liste erstellen:
  • Die flussaufwärts Unverzichtbare IKT-Anbieter und -Plattformen.
  • Die stromab Kunden oder Kundengruppen, die diesen Dienst in Anspruch nehmen.
  1. Risikoansicht: Für jeden wichtigen Lieferanten oder Kundensektor ist ein separates Risiko zu erfassen, das Folgendes besagt:
  • Was könnte vernünftigerweise schiefgehen (z. B. Ausfall, Datenleck, Lizenzänderung)?
  • Wie sich das auf Ihre Dienstleistungen und die Ergebnisse für Ihre Kunden auswirken würde.
  • Welche Kontrollmechanismen, Vertragsbedingungen und betrieblichen Vorgehensweisen verringern die Wahrscheinlichkeit oder die Auswirkungen?

Viele Managed Service Provider (MSPs) finden ein einfaches Diagramm hilfreich, selbst wenn man es nie extern zeigt: Cloud/Plattformen → MSP-Tools und -Prozesse → KundenumgebungenMithilfe von Farben oder Symbolen wird das relative Risiko dargestellt. Diese Darstellung hilft Ihnen bei der Entscheidung, wo Sie Ihre Ressourcen investieren sollten, und bietet Wirtschaftsprüfern und Kunden eine einfache Möglichkeit, Ihre Abhängigkeiten zu verstehen.

In ISMS.online können Sie diese Struktur abbilden, indem Sie Services, Lieferanten, Kunden und Risiken in einer zentralen Umgebung verknüpfen. Dadurch lässt sich deutlich einfacher darstellen, wie eine neue Plattform oder ein neuer Kunde in die Übersicht aufgenommen, klassifiziert und die zugehörigen Risiken und Verantwortlichkeiten konsistent aktualisiert werden.


Welche alltäglichen Aufzeichnungen überzeugen ISO 27001-Auditoren davon, dass ein Managed Service Provider (MSP) Anhang A.5.21 tatsächlich verwaltet und nicht nur in der Dokumentation erwähnt?

Prüfer legen in der Regel mehr Wert darauf, ob Ihre alltäglichen Aufzeichnungen ein schlüssiges Bild ergeben, als auf die Optik Ihrer Tools. Für Anhang A.5.21 möchten sie sehen, dass Sie die Ursachen von Risiken in der ITK-Lieferkette verstehen, ein wiederholbares Vorgehen anwenden und dieses nachweisen können, ohne ein separates Unternehmen für die Prüfungsdokumentation zu gründen.

Welche normalen Artefakte erfüllen üblicherweise die Anforderungen von Anhang A.5.21 für MSPs, ohne dass eine parallele „Auditindustrie“ aufgebaut werden muss?

Bei den meisten Managed Service Providern (MSPs) genügt ein kompakter Datensatz, sofern er vollständig und aktuell ist:

  • A Lieferantenregister Diese Liste stellt ICT-Anbieter bereit, verknüpft sie mit Dienstleistungen, zeigt ihre Risikoklassifizierung an und vermerkt das Datum der letzten Überprüfung.
  • kurz Due-Diligence-Notizen für Lieferanten mit höherem Risiko, wie z. B. Verweise auf Zertifizierungen, Antworten auf Fragebögen oder prägnante Risikobewertungen.
  • Verträge oder Sicherheitszusätze: darin werden Sicherheitserwartungen, Regeln für die Meldung von Vorfällen, Datenverarbeitung und Bedingungen für Unterauftragnehmer festgelegt.
  • Überwachungs- und Prüfprotokolle: wie beispielsweise Service-Review-Tickets, Protokolle von Lieferanten-Check-ins oder Nachbesprechungen von Vorfällen, aus denen hervorgeht, wie Sie reagiert haben.
  • Modelle der geteilten Verantwortung: und damit zusammenhängende Klauseln in Kundenverträgen sowie konkrete Beispiele dafür, wie Sie vorgehen sollten, wenn Verpflichtungen von einer der beiden Seiten nicht erfüllt werden.

Anstatt separate „Audit-Pakete“ zu erstellen, ist es in der Regel effizienter, sicherzustellen, dass Ihre normalen Dokumente – Checklisten für die Einarbeitung, Änderungsaufzeichnungen, Betriebshandbücher, Vorfall- und Problemberichte – automatisch die Nachweise liefern, die ein Auditor anfordern wird.

Wenn Sie diese Dokumente in ISMS.online zentralisieren und sie explizit mit den Kontrollen gemäß Anhang A und den relevanten Risiken verknüpfen, können Sie Prüfungsfragen und Kundenfragebögen schnell beantworten, indem Sie die Daten zentral filtern und exportieren. Das reduziert langfristig den Prüfungsstress, verkürzt die Vertriebszyklen und trägt dazu bei, dass Ihr Team für die Führung einer gut organisierten ITK-Lieferkette anerkannt wird, anstatt jedes Jahr aufs Neue die gleichen Daten von Grund auf neu zusammentragen zu müssen.


Wie kann ein Managed Service Provider (MSP) ISMS.online nutzen, um Anhang A.5.21 in die normale Lieferkettenarbeit zu integrieren, anstatt ihn als einmaliges Compliance-Projekt zu behandeln?

Anhang A.5.21 wird handhabbar, wenn er in Ihre Prozesse für Einkauf, Bereitstellung und Überprüfung von Dienstleistungen integriert wird und nicht als eigenständiger Standard behandelt wird, der lediglich abgehakt wird. ISMS.online unterstützt diesen Wandel, indem es Ihnen eine zentrale Plattform bietet, um Lieferanten, Dienstleistungen, Kunden, Risiken, Kontrollen und Nachweise zu verknüpfen. So trägt Ihr tägliches Handeln ganz natürlich dazu bei, dass Anhang A.5.21 stets aktuell ist.

Wie sieht es aus, wenn Anhang A.5.21 in ISMS.online tatsächlich umgesetzt wird?

Ein realistisches Muster für viele Managed Service Provider (MSPs) sieht folgendermaßen aus:

  • Sie pflegen eine Live-Lieferantenregister in ISMS.online, Klassifizierung der ICT-Anbieter nach ihrer Auswirkung und Verknüpfung jedes Anbieters mit den von ihm unterstützten Managed Services und den Kontrollen gemäß Anhang A.5.19–A.5.22.
  • Du eroberst Due-Diligence-Prüfung, Onboarding, Monitoring und Exit-Aktivitäten als normale Arbeitsvorgänge oder Aufgaben, sodass sich die für Anhang A.5.21 benötigten Nachweise automatisch ansammeln, während Ihr Team mit Lieferanten zusammenarbeitet.
  • Sie lagern und verwenden wieder Modelle der geteilten Verantwortung als strukturierte Inhalte, die Servicefamilien und Kundengruppen zugeordnet werden, damit Vertragstexte, Betriebshandbücher und Risikoeinträge aufeinander abgestimmt bleiben.
  • Du verlinkst Risiken Dies betrifft sowohl vorgelagerte Lieferanten als auch nachgelagerte Kunden, sodass eine Änderung in einem Teil der Kette unmittelbar Ihre Sicht auf das gesamte Lieferkettenrisiko verändert.

Ein risikoarmer Einstieg besteht darin, einen wichtigen Dienst, eine kritische vorgelagerte Plattform und einen repräsentativen Kunden auszuwählen, diese Kette in ISMS.online vollständig abzubilden und anschließend eine reale Änderung oder einen Vorfall im System zu simulieren. Wenn Ihre Teams und Ihr Auditor anhand dieses Beispiels Abhängigkeiten leichter erkennen, Verpflichtungen erläutern und Nachweise sammeln können, haben Sie intern eine starke Argumentation, denselben Ansatz auf weitere Bereiche Ihrer ITK-Lieferkette auszuweiten.

Mit der Zeit trägt diese Arbeitsweise dazu bei, dass Ihr Unternehmen nicht nur als Anbieter von IT-Lösungen wahrgenommen wird, sondern als Betreiber einer nachvollziehbaren und gut geführten IT-Lieferkette, die Kundenbefragungen und ISO-27001-Audits problemlos standhält und Ihren Arbeitsalltag deutlich weniger beeinträchtigt. Wenn Sie einem Kunden oder Auditor Ihre Erfolgsgeschichte präsentieren möchten, bietet Ihnen ISMS.online alle benötigten Informationen zentral an einem Ort – anstatt dass Sie diese unter Zeitdruck mühsam zusammentragen müssen.



Mark Sharron

Mark Sharron leitet die Strategie für Suche und generative KI bei ISMS.online. Sein Schwerpunkt liegt auf der Vermittlung der praktischen Umsetzung von ISO 27001, ISO 42001 und SOC 2 – der Verknüpfung von Risiken mit Kontrollen, Richtlinien und Nachweisen mit auditfähiger Rückverfolgbarkeit. Mark arbeitet mit Produkt- und Kundenteams zusammen, um diese Logik in Arbeitsabläufe und Webinhalte zu integrieren und Unternehmen dabei zu helfen, Sicherheit, Datenschutz und KI-Governance sicher zu verstehen und nachzuweisen.

Machen Sie eine virtuelle Tour

Starten Sie jetzt Ihre kostenlose 2-minütige interaktive Demo und sehen Sie
ISMS.online im Einsatz!

Plattform-Dashboard voll auf Mint

Wir sind führend auf unserem Gebiet

4 / 5 Sterne
Benutzer lieben uns
Leiter – Winter 2026
Regionalleiter – Winter 2026 (Großbritannien)
Regionalleiter – Winter 2026 EU
Regionalleiter – Winter 2026, Mittelstand EU
Regionalleiter – Winter 2026 EMEA
Regionalleiter – Winter 2026, Mittelstand EMEA

„ISMS.Online, herausragendes Tool zur Einhaltung gesetzlicher Vorschriften“

— Jim M.

„Macht externe Audits zum Kinderspiel und verknüpft alle Aspekte Ihres ISMS nahtlos miteinander“

— Karen C.

„Innovative Lösung zur Verwaltung von ISO- und anderen Akkreditierungen“

— Ben H.