
June 16, 2026 • 12 min read
Die MCP-Governance-Checkliste für CISOs: Skalierbares Management von Integrationsrisiken

Richard Marcus
Gespräche mit anderen CISOs über das Model Context Protocol (MCP) beginnen fast immer an demselben Punkt: Jemand aus dem Engineering- oder Produktteam hat bereits eine Verbindung zu einem neuen Server hergestellt und das Sicherheitsteam erfährt erst im Nachhinein davon. Auch dieser Artikel setzt dort an – und nicht bei der Frage, ob man MCP überhaupt einführen soll. Es geht vielmehr darum, wie das, was bereits in Gang ist, gesteuert werden kann.
MCP entwickelt sich rasant weiter, und zwar nicht nur im Engineering-Bereich. Auch Finanz-, Betriebs- und HR-Teams, um nur einige zu nennen, entwickeln KI-Workflows und binden diese in die Unternehmenssysteme ein. Für sie alle ist der Business Case bereits Realität. Dasselbe gilt für die damit verbundenen Risiken. Daher stellt sich die Frage, ob Ihre Governance-Strategie mit der Einführung in allen Funktionsbereichen Schritt halten kann. In den meisten Unternehmen ist dies nicht der Fall.
MCP ist eine Integrationsschicht. Das bedeutet, dass das Risiko dort besteht, wo Integrationsrisiken schon immer vorhanden waren: an den Schnittstellen zwischen Systemen, bei der Weitergabe von Authentifizierungsdaten sowie bei Datenberechtigungen, die ursprünglich nicht für eine gemeinsame Nutzung in diesem Umfang ausgelegt waren. Noch schwieriger wird die Erkennung dieser Risiken dadurch, dass MCP-Aktivitäten in Sicherheitsüberwachungsumgebungen standardmäßig häufig nicht sichtbar sind. Gleichzeitig ist Schatten-KI bereits ein bekanntes Problem: 35 % der Unternehmen beschreiben sie als allgegenwärtig oder weit verbreitet..
Im Kern handelt es sich hierbei um ein Connected-Risk-Problem. Der Zweck von MCP besteht darin, Daten zwischen Systemen auszutauschen, damit KI-Agenten einen umfassenderen Kontext für ihre Entscheidungen erhalten. Alle Grundsätze, die eine wirksame Connected-Risk-Governance ausmachen – gemeinsamer Kontext, einheitliche Kontrollen, klare Zuständigkeiten – lassen sich unmittelbar auf MCP übertragen. Gleichzeitig wird jede Lücke in Ihrem Connected-Risk-Profil zu einer potenziellen MCP-Schwachstelle.
Die folgende Checkliste ist nach den fünf Governance-Bereichen gegliedert, in denen ich die größten Risiken sehe. Innerhalb jedes Bereichs unterscheide ich zwischen zwei Arten von Aufgaben: solchen, die menschliches Urteilsvermögen erfordern und nicht an Software delegiert werden können, und solchen, bei denen eine integrierte GRC-Plattform den manuellen Aufwand erheblich reduziert. Beide sind gleichermaßen wichtig. Werden diese beiden Aspekte nicht klar voneinander getrennt, geraten Governance-Programme ins Stocken. Entweder unterschätzen Teams die Aufgaben, für die sie selbst verantwortlich sind, oder sie übernehmen sich, indem sie versuchen, manuell zu erledigen, was eine Plattform übernehmen könnte.
1. Bestandsaufnahme und Transparenz
- Das muss abgewägt werden:: Legen Sie fest, welches Maß an MCP-gestütztem Zugriff für jedes System bzw. jede Datenkategorie akzeptabel ist, und definieren Sie die Kriterien, die eine Überprüfung auslösen. Diese Entscheidungen können nicht von einem Tool übernommen werden.
- Hier ist Integration hilfreich:: Die Pflege eines aktuellen, genauen Bestandsverzeichnisses aller aktiven MCP-Server, der jeweils zugänglichen Daten sowie der verbundenen KI-Modelle und Agenten ist ohne ein zentralisiertes System auf Dauer kaum praktikabel. Eine GRC-Plattform kann als zentrales Register dienen, das Bestandsverzeichnis auf dem neuesten Stand halten und Änderungen aufzeigen, ohne dass ein manueller Prüfzyklus erforderlich ist.
2. Authentifizierung und Zugriffskontrolle:
- Das muss abgewägt werden: Legen Sie Ihre Authentifizierungsstandards für MCP-Verbindungen fest und entscheiden Sie, in welchen Fällen Ausnahmen zulässig sind. Die Beschränkung von Zugriffsrechten auf das für den jeweiligen Anwendungsfall erforderliche Minimum ist eine Governance-Entscheidung und keine reine Konfigurationsfrage.
- Hier ist Integration hilfreich:: Die Überwachung von MCP-Verbindungen hinsichtlich der Einhaltung genehmigter Authentifizierungsstandards in einer komplexen Unternehmensumgebung sowie die Erkennung von Abweichungen sind typische Anwendungsfälle für Continuous Monitoring und Automatisierung. Manuelle Überprüfungen im vierteljährlichen Rhythmus sind hierfür zu langsam, da sich diese Integrationen sehr schnell weiterentwickeln.
3. Schutz sensibler Daten und Minderung von Drittparteien-Risiken
- Das muss abgewägt werden: Bei jeder MCP-Integration mit Drittparteien müssen Sie festlegen, welcher Datenaustausch für den jeweiligen Anwendungsfall tatsächlich erforderlich ist. An dieser Grenze müssen Sie festhalten, wenn Teams auf einen umfassenderen Zugriff drängen. Diese Einschätzung erfordert ein Verständnis der Geschäftsbeziehung, der betroffenen Daten und der Risikobereitschaft. Außerdem bedarf es einer ehrlichen Betrachtung der Auswirkungen im ungünstigsten Fall. Eine schreibgeschützte MCP-Integration birgt ein relativ geringes Risiko. Eine Integration, die einem Agenten die autonome Durchführung eines Massenlöschvorgangs ermöglicht, gehört hingegen in eine völlig andere Risikokategorie. Bevor Sie eine Integration genehmigen, sollten Sie die auf dem MCP-Server oder dem zu verbindenden System verfügbaren Kontrollen bewerten: den Umfang der Berechtigungen, die Prüfprotokollierung, die Überwachungsfunktionen sowie alle sonstigen nativen Konfigurationen. Diese Kontrollen entscheiden darüber, ob das Risiko beherrschbar ist, und nicht nur, ob der Anwendungsfall legitim ist.
- Hier ist Integration hilfreich: Bewertungen von Drittparteien-Risiken, die Nachverfolgung des Compliance-Status und Anbieterzugriffsprüfungen lassen sich zentral in einer GRC-Plattform bündeln. Wenn bei einer neuen MCP-Integration eine Drittparteibeteiligt ist, sollten Sie auf deren vorhandenes Risikoprofil zurückgreifen können, anstatt den Bewertungsprozess von Grund auf neu beginnen zu müssen. Genau bei dieser Verknüpfung versagen fragmentierte Einzellösungen, während vernetzte Plattformen ihre Vorteile ausspielen.
4. KI-Inventar und funktionsübergreifende Governance
- Das muss abgewägt werden: Legen Sie fest, welche über MCP-Verbindungen angebundenen KI-Systeme einer formellen Governance-Regelung unterliegen, ab welchem Schwellenwert dies gilt und wer außerhalb des InfoSec-Bereichs in die Entscheidungsfindung eingebunden werden sollte. Dies ist eine Grundsatzfrage und solche Entscheidungen erfordern menschliche Verantwortung.
- Hier ist Integration hilfreich: Ein KI-Inventar muss auf dem neuesten Stand gehalten und mit den Kontrollen und den Compliance-Vorgaben für jedes einzelne System verknüpft werden. Diese Informationen müssen den zuständigen Audit-, Risiko- und Compliance-Teams zugänglich gemacht werden – insgesamt ein Koordinationsaufwand, der manuell kaum zu bewältigen ist. Wenn Ihr KI-Inventar und Ihre GRC-Umgebung auf derselben Datengrundlage basieren, bleibt der Risikokontext mit dem jeweiligen Asset verknüpft und muss nicht mehr in Tabellenkalkulationen erfasst werden, die von mehreren Teams parallel gepflegt werden.
An dieser Stelle ein Hinweis: Betrachten Sie die KI-Governance niemals als alleinige Aufgabe des InfoSec-Bereichs. MCP-Integrationen sind der Mechanismus, durch den sich KI-Risiken funktionsübergreifend ausbreiten. Wenn die Teams, die für das Drittparteien-Risikomanagement, die Compliance-Überwachung und das unternehmensweite Risikomanagement zuständig sind, nicht erkennen können, was aus welchem Grund miteinander verbunden ist, weist Ihr Governance-Programm eine strukturelle Lücke auf.
5. Verantwortlichkeiten und Eskalation
- Das muss abgewägt werden: Die Zuweisung eines namentlich benannten Verantwortlichen für jeden MCP-Server in Ihrer Umgebung sowie die Festlegung der Kriterien für das Aussetzen einer Verbindung sind Governance-Entscheidungen, die Befugnis in Organisationsfragen erfordern. Software kann keine Verantwortung übernehmen.
- Hier ist Integration hilfreich: Eskalationspfade sind nur so zuverlässig wie die Transparenz, auf die sie sich stützen. Wenn Ihre Audit-, Risiko- und Compliance-Teams darauf warten müssen, dass das InfoSec-Team ein Problem aufdeckt, bevor sie handeln können, richtet sich die Reaktionszeit nach dem langsamsten Kommunikationskanal. Eine gemeinsame GRC-Umgebung sorgt dafür, dass Aktivitäten auf der Integrationsebene für die relevanten Stakeholder kontinuierlich sichtbar sind – und nicht erst dann, wenn Ihr SOC einen Alarm auslöst.
Ein Hinweis zum Tempo
MCP wird bleiben und den Teams die Nutzung zu verbieten, ist kaum eine realistische Position. Unternehmen, die in dieser Beziehung erfolgreich sind, haben bereits vor der Einführung – oder zumindest parallel dazu – eine Governance-Infrastruktur aufgebaut, statt diese erst im Nachhinein einzurichten.
Die zweigeteilte Struktur dieser Checkliste spiegelt eine Unterscheidung wider, die meiner Meinung nach in vielen Diskussionen zum Thema Governance untergeht: Die eigentliche Herausforderung im Bereich der MCP-Governance ist nicht in erster Linie technologischer Natur. Vielmehr geht es um das Abwägen der Zuständigkeiten, des Umfangs des Zugriffs, des akzeptablen Risikos und der Verantwortlichkeit. Was Technologie leisten kann, ist die Beseitigung des Koordinationsaufwands, der eine solche Abwägung in großem Maßstab nahezu unmöglich macht.
Darin liegt das zentrale Argument für eine einheitliche GRC-Lösung für die MCP-Governance. Zwar werden Ihnen die Entscheidungen damit nicht abgenommen, aber Sie erhalten die operative Grundlage, um sie konsistent in einer sich schnell verändernden Integrationslandschaft zu treffen – ohne dass Teams durch den Versuch, alles manuell nachzuverfolgen, überlastet werden. Genau hier setzt die Connected Risk Plattform von Optro an – und genau hier vergrößert sich meiner Erfahrung nach die Kluft zwischen den Unternehmen mit guter MCP-Governance und solchen mit Defiziten in diesem Bereich.
Governance beginnt bereits, bevor die Bereitstellung erfolgen kann. Sind Sie bereit für den nächsten Schritt? Dann holen Sie sich unsere Checkliste für GRC-Verantwortliche zur Bereitstellung eines MCP-Servers.
About the authors

Richard Marcus, CISA, CRISC, CISM, TPECS, is the CISO at Optro, where he is focused on product, infrastructure, and corporate IT security, as well as leading the charge on Optro’s own internal compliance initiatives. In this capacity, he has become an Optro product power user, leveraging the platform’s robust feature set to satisfy compliance, risk assessment, and audit use cases. Connect with Richard on LinkedIn.
You may also like to read

Richtlinie für verantwortungsvolle KI: Ein Leitfaden zur ethischen Governance
