Insider- und Admin-Kontrollen beim Filesharing im Unternehmen: Was CISOs und Datenschutzbeauftragte bewerten sollten

Insider-Bedrohungen und der Missbrauch privilegierter Zugriffsrechte sind für einen unverhältnismäßig großen Anteil an Datenschutzverstößen in regulierten Umgebungen verantwortlich – und häufig für die schwerwiegendsten. Im Gegensatz zu externen Angriffen nutzen Insider-Vorfälle bereits vertrauenswürdige Zugangsdaten, erreichbare Systeme und Personen, die genau wissen, wo sich wertvolle Inhalte befinden. Speziell beim Filesharing in Unternehmen reicht das Problem über einzelne Mitarbeiter in betrügerischer Absicht hinaus: Das größere Risiko liegt oft in unzureichend abgegrenzten administrativen Zugriffsrechten, fehlender Funktionstrennung und der unbeachteten Frage, was passiert, wenn Mitarbeitende des Plattformanbieters auf ein System mit regulierten Daten zugreifen müssen.

Dieser Beitrag richtet sich an CISOs und DPOs, die Filesharing-Plattformen im Unternehmen im Hinblick auf Insider-Risiken bewerten. Er behandelt die wichtigsten Kontrollmechanismen: rollenbasierte und attributbasierte Zugriffskontrolle, Funktionstrennung, das Vier-Augen-Prinzip als Bewertungskriterium, Privileged Access Management, umfassendes Audit-Logging von Administratoraktionen sowie die oft übersehene Grenze beim Support-Zugriff des Anbieters. Es wird erläutert, welche dokumentierten Kontrollen existieren, wo typischerweise Lücken zwischen internen Prozessen und veröffentlichter Kundendokumentation bestehen und welche Fragen Sie stellen sollten, bevor Sie sich bei regulierten Workloads auf eine Plattform verlassen.

Executive Summary

Kernaussage: Insider- und Administrationskontrollen beim Filesharing im Unternehmen erfordern zwei getrennte Bewertungsebenen. Die erste betrifft die Kundenseite: Welche Kontrollen regeln, was Administratoren tun dürfen, ob sie ihre Rechte selbst erweitern können, ob sensible Aktionen eine doppelte Autorisierung erfordern und ob alle Admin-Aktivitäten protokolliert und exportierbar sind. Die zweite betrifft die Anbieterseite: Unter welchen Bedingungen haben Support-Mitarbeiter des Anbieters Zugriff auf die Kundenumgebung, wer genehmigt diesen Zugriff, wie ist er zeitlich begrenzt und wird jede Sitzung in einem für den Kunden einsehbaren Protokoll erfasst? Die meisten Plattformen verfügen über angemessene Kundenseiten-Kontrollen, lassen aber die Frage des Anbieterzugriffs entweder undokumentiert oder verstecken sie in Lizenzvereinbarungen, die nicht öffentlich einsehbar sind.

Warum das relevant ist: NIS 2 Artikel 21 verlangt angemessene Maßnahmen zum Management von Insider-Risiken. BSI C5 (IDM-Domain: Identity and Access Management) und ISO 27001:2022 (A.5.18 Zugriffsrechte, A.8.5 Privileged Access Management, A.8.15 Logging) bewerten unabhängig Privileged Access Management und Insider-Kontrollen. Ist das Support-Zugriffsverfahren des Anbieters nicht in einer für den Kunden zugänglichen Form dokumentiert, besteht eine Lücke im Compliance-Nachweis – unabhängig davon, was der Anbieter im Audit-Fragebogen behauptet.

5 wichtige Erkenntnisse

1. Die entscheidende Frage ist nicht „Wer hat Admin-Zugriff?“, sondern „Was können Admins unbeaufsichtigt tun?“ Plattformen mit einer einzigen Super-Admin-Rolle, die alle Rechte bündelt, können keine sinnvolle Funktionstrennung gewährleisten. Entscheidend ist, ob Security-, Compliance- und Betriebsadministration als getrennte Rollen zugewiesen werden können, die nicht von einer Person kombiniert werden dürfen.
2. Selbst-Eskalation ist ein Designfehler, keine Fehlkonfiguration. Admins, die sich selbst zusätzliche Rechte einräumen können, unterlaufen jegliche Insider-Kontrolle. Gut konzipierte Plattformen machen Privilegien-Eskalation architektonisch unmöglich, ohne dass eine zweite autorisierte Person beteiligt ist – und zwar nicht nur als Richtlinie, sondern technisch erzwungen. Das Vier-Augen-Prinzip bei sensiblen Admin-Aktionen ist ein struktureller Schutz, kein Audit-Check. Fragen Sie explizit, welche Aktionen auf Ihrer Zielplattform eine doppelte Autorisierung erfordern und ob dies architektonisch durchgesetzt wird.
3. Ein Audit-Log mit 632 Ereignissen ist nur dann nützlich, wenn es in Echtzeit exportierbar ist und die relevanten Ereignisse abdeckt. Admin-Logging ist Standard. Wichtiger ist, ob Audit-Events in Echtzeit an Ihr SIEM übertragen werden, ob das Protokoll manipulationssicher und kundengesteuert ist und ob Support-Sitzungen des Anbieters so protokolliert werden, dass der Kunde sie einsehen und prüfen kann – für überprüfbare Kontrolle sowohl interner Admin-Aktionen als auch externer Support-Sitzungen.
4. Kundeninitiierter Support-Zugriff ist ein wesentliches Architekturmerkmal. Plattformen, bei denen der Anbieter eigenständig Support-Sitzungen starten kann – ohne Kundenaktion – bergen ein grundsätzlich anderes Risiko als Plattformen, bei denen der Kunde den Zugriff aktiviert, die Sitzung genehmigt und der Anbieter ohne diese Freigabe keinen Zugang erhält. Ersteres erfordert Vertrauen in die internen Kontrollen des Anbieters. Letzteres gibt dem Kunden strukturelle Kontrolle über die Zugriffsschnittstelle.
5. Veröffentlichte Dokumentation und interne Prozesse sind nicht dasselbe. Ein Anbieter kann ein robustes, intern dokumentiertes Support-Zugriffsverfahren mit doppelter Genehmigung, Zeitbegrenzung und vollständigem Logging haben – und dennoch keine für den Kunden zugängliche Version dieser Prozedur veröffentlichen. Für regulierte Unternehmen ist „Wir haben eine Richtlinie“ kein Compliance-Nachweis. Ein zitierbares, prüfbares Dokument schon. Fragen Sie, wo das Support-Zugriffsverfahren des Anbieters veröffentlicht ist, bevor Sie sich auf mündliche Zusagen verlassen.

Kundenseitige Insider-Kontrollen: RBAC, ABAC und Funktionstrennung

Kundenseitige Insider-Kontrollen regeln, was Administratoren innerhalb des eigenen Unternehmens auf der Plattform tun dürfen. Der Bewertungsrahmen umfasst drei Ebenen: Rollendefinition (welche Rechte existieren und wie sie strukturiert sind), Rollentrennung (ob Rechte unabhängig zugewiesen werden können, damit keine Einzelperson übermäßigen Zugriff erhält) und Aktionssteuerung (ob risikoreiche Admin-Aktionen eine doppelte Autorisierung erfordern und vollständig protokolliert werden).

Rollenbasierte Zugriffskontrolle und Trennung administrativer Funktionen

RBAC ist allgegenwärtig – nahezu jede Unternehmensplattform behauptet, sie zu unterstützen. Der Unterschied liegt in der Granularität: Trennen die Rollendefinitionen die Funktionen, die für den Schutz vor Insider-Risiken wirklich getrennt werden müssen? Besonders relevant sind Security-Administration (Verwaltung von Authentifizierungsrichtlinien, Zugriffsregeln und Sicherheitskonfiguration), Compliance-Administration (Zugriff auf Audit-Logs, Verwaltung von Aufbewahrung und Legal Hold, Erstellung von Compliance-Berichten) und Betriebsadministration (Verwaltung von Anwendern, Ordnern und Integrationen). Werden diese Funktionen in einer einzigen Rolle gebündelt, kann ein kompromittierter oder böswilliger Administrator gleichzeitig Sicherheitskontrollen manipulieren, Spuren im Audit-Log verwischen und auf sämtliche Inhalte der Plattform zugreifen.

Kiteworks implementiert klar getrennte, unabhängig zuweisbare Rollen wie System Administrator, Compliance Administrator, CISO Administrator, Policy Manager und Auditor. Diese Rollen sind keine Unterberechtigungen eines einzelnen Admin-Kontos, sondern separat zuweisbar. So kann ein Unternehmen sein Admin-Team so strukturieren, dass niemand gleichzeitig Security- und Compliance-Administration innehat. Dadurch wird es architektonisch deutlich schwerer, dass ein Insider eine privilegierte Aktion sowohl ausführt als auch verschleiert, da die Person mit Zugriff auf Sicherheitskontrollen nicht dieselbe ist wie die mit Zugriff auf das Audit-Log-Management.

Für DPOs besonders relevant ist die Rolle des Data Leak Investigator (DLI) Administrator. Diese Rolle ist bewusst isoliert – Systemadministratoren haben keinen Zugriff auf die DLI-Konsole, und der Zugriff des DLI-Administrators beschränkt sich auf eDiscovery Berichte zu allen Aktivitäten, E-Mails und Dateien, auf die bestimmte Anwender zugegriffen haben. Für Unternehmen mit Legal Hold-Pflichten oder Prozessen zu Auskunftsersuchen bietet die DLI-Rolle einen zweckgebundenen Zugriff, ohne umfassende Admin-Rechte vergeben zu müssen.

Ein oft übersehener Kontrollmechanismus: Administratoren können auf keiner Ebene ihre eigenen Rechte eskalieren. Privilegien-Eskalation – also sich selbst zusätzliche Zugriffsrechte zu gewähren – erfordert immer eine Aktion einer anderen autorisierten Person. Dies ist ein strukturelles Merkmal des Rollenmodells, keine Richtlinie, die von der Konfigurationsdisziplin abhängt.

Attributbasierte Zugriffskontrolle: Inhaltsbasierte Einschränkung für Administratoren

RBAC beantwortet die Frage, welche Aktionen ein Administrator ausführen darf. Attributbasierte Zugriffskontrolle (ABAC) beantwortet die ergänzende Frage, auf welche Inhalte ein Administrator bei diesen Aktionen zugreifen kann. In regulierten Umgebungen sollte selbst ein privilegierter Administrator nicht als Nebeneffekt seiner Tätigkeit auf klassifizierte, sensible oder besonders geschützte Inhalte zugreifen können.

Kiteworks setzt ABAC-Richtlinien ein, die den Zugriff von Administratoren auf Inhalte anhand von Datenklassifizierungs attributen beschränken. Ein Administrator, der Benutzerkonten verwaltet, erhält dadurch keinen Lesezugriff auf Ordner mit einer höheren Klassifizierung als seiner eigenen Zugriffsberechtigung. Diese Trennung von Aktions- und Inhaltsprivilegien ist besonders relevant für Organisationen, die Inhalte mit unterschiedlichen Schutzstufen verarbeiten – etwa Rüstungsunternehmen, Finanzinstitute mit Retail- und Institutionaldaten oder Gesundheitsorganisationen mit gemischten klinischen und administrativen Inhalten.

Das Vier-Augen-Prinzip: Doppelte Autorisierung für Support-Zugriffe des Anbieters

Das Vier-Augen-Prinzip verlangt, dass bestimmte risikoreiche Aktionen nicht von einer einzelnen autorisierten Person abgeschlossen werden können – sie erfordern eine zweite Bestätigung, bevor die Aktion wirksam wird. Diese Kontrolle ist im Finanzsektor etabliert (z. B. bei Zahlungsfreigaben) und wird zunehmend auch in regulierten Datenumgebungen erwartet.

Im Kontext von Kiteworks gilt die doppelte Autorisierung für den Support-Zugriff des Anbieters: Eine Support-Sitzung erfordert die Freigabe sowohl auf Kundenseite als auch auf Seiten von Kiteworks, bevor sie startet. Dies ist die dokumentierte Anwendung des Vier-Augen-Prinzips in der Kiteworks-Architektur. Ob die doppelte Autorisierung zusätzlich auf der Plattformebene für bestimmte kundenseitige Admin-Aktionen – wie Massenexporte oder Änderungen an Sicherheitsrichtlinien – durchgesetzt wird, sollte für Ihr Einsatzszenario direkt mit Kiteworks geklärt werden. Die Anwendung für Support-Zugriffe ist strukturell dokumentiert; der Umfang für kundenseitige Admin-Aktionen sollte vorab bestätigt werden.

Zu prüfen: Fragen Sie Ihren Anbieter, für welche Aktionskategorien eine doppelte Autorisierung auf Plattformebene erforderlich ist, ob diese Anforderung technisch erzwungen wird (nicht nur als Richtlinie existiert) und ob doppelte Autorisierungen im Audit-Log eindeutig protokolliert werden – sodass sowohl die initiierende als auch die bestätigende Aktion nachvollziehbar sind.

Privileged Access Management und Audit-Logging

Privileged Access Management (PAM) bezeichnet die Gesamtheit der Kontrollen, die regeln, wie privilegierte Konten – also solche mit erhöhten Zugriffsrechten – vergeben, genutzt, überwacht und deaktiviert werden. PAM wird in allen relevanten Sicherheitszertifizierungen für Filesharing-Lösungen unabhängig geprüft: BSI C5 Typ 2 (IDM-Domain – Identity and Access Management), ISO 27001:2022 (A.8.5 – Privileged Access Management) und SOC 2 Typ II. Die Existenz von Zertifizierungen belegt, dass PAM-Kontrollen geprüft wurden – Umfang und Tiefe der Prüfung variieren jedoch, und Zertifikate garantieren nicht, dass die Kontrollen in jeder Bereitstellung wie geprüft konfiguriert sind.

Admin-Kontrollen und erweitertes Monitoring

Administratorkonten auf der Kiteworks-Plattform unterliegen erweiterten Kontrollen, die über das Standard-User-Management hinausgehen. Admin-Konten müssen strengere Authentifizierungsanforderungen, Inaktivitätsrichtlinien und Sitzungsmanagement erfüllen. Der Lebenszyklus von Admin-Konten – Erstellung, Änderung und Deaktivierung – wird durch dieselbe SCIM-basierte Automatisierung gesteuert wie bei Benutzerkonten. Das bedeutet, dass ein Administrator, der das Unternehmen verlässt oder die Rolle wechselt, automatisch über das Verzeichnis entzogen wird – nicht über einen separaten manuellen Offboarding-Prozess, der leicht übersehen werden kann.

Das Logging von Admin-Aktivitäten ist umfassend. Das Kiteworks-Audit-Log erfasst 632 verschiedene Ereignistypen und deckt sämtliche Admin-Operationen ab: Richtlinienänderungen, Benutzerverwaltung, Konfigurationsänderungen, Anpassungen der Zugriffskontrolle und Änderungen an Sicherheitseinstellungen. Jede Admin-Aktion wird mit Benutzeridentität, Zeitstempel, Quell-IP, Aktionstyp und Ergebnis protokolliert. Das Protokoll ist manipulationssicher – Administratoren mit Compliance-Admin-Rolle können das Audit-Log einsehen, aber nicht verändern oder Einträge löschen. Spezielle Compliance-Berichte zu Insider- und Outsider-Bedrohungen ermöglichen Compliance-Administratoren mit Advanced Governance-Lizenz eine detaillierte Analyse der Aktivitäten einzelner Anwender.

SIEM-Integration und Echtzeit-Export

Ein Ereignis, das nur in der Plattformoberfläche einsehbar ist, hat für Security-Teams begrenzten Wert. Entscheidend ist, ob Admin-Audit-Events in Echtzeit an die SIEM-Infrastruktur des Unternehmens exportiert werden können – zur Korrelation mit anderen Systemen, für automatisierte Alarme bei Anomalien und für die Protokollaufbewahrung nach den eigenen Richtlinien, nicht nach denen des Anbieters.

Kiteworks unterstützt den Echtzeit-Syslog-Export von Admin-Events, auch an gängige SIEM-Plattformen. Es gibt eine native Integration mit Splunk (On-Premises und Splunk Cloud). Dadurch kann eine anomale Admin-Aktion – etwa eine unerwartete Konfigurationsänderung, ein Massenexport durch ein Admin-Konto oder eine Rechteänderung – innerhalb von Sekunden einen Alarm im SOC auslösen, statt erst bei einer periodischen Log-Überprüfung entdeckt zu werden. Für Unternehmen, die NIS 2 Artikel 21 oder DORA-Vorgaben zur Vorfallserkennung erfüllen müssen, ist diese Echtzeit-Transparenz kein Nice-to-have, sondern eine grundlegende Anforderung.

Audit von Support-Sitzungen des Anbieters: Support-Aktivitäten werden an zwei Stellen protokolliert: im Kiteworks-Support-Service und direkt in den System-Logs auf der Kundeninfrastruktur. Diese Logs sind per System-Log-Dump exportierbar und verbleiben beim Kunden – nicht ausschließlich beim Anbieter. Echtzeit-Transparenz über Support-Sitzungen ist auf Anfrage verfügbar. Für regulierte Unternehmen, die eine einheitliche Audit-Sicht über Admin- und Support-Aktivitäten benötigen, sollten die verfügbaren Log-Formate, Exportmechanismen und Monitoring-Optionen mit dem Kiteworks-Account-Team besprochen werden.

Support-Zugriff des Anbieters: Die entscheidende Grenze

Die Grenze für Support-Zugriffe des Anbieters ist die Insider-Risiko-Frage, die bei den meisten Filesharing-Evaluierungen zu wenig betrachtet wird. Das Szenario ist klar: Support-Mitarbeiter des Anbieters müssen auf die Kundenumgebung zugreifen, um ein Problem zu diagnostizieren oder Wartungsarbeiten durchzuführen. Die daraus folgenden Fragen entscheiden, ob „On-Premises“ oder „Private Cloud“ wirklich kundenkontrolliert bedeutet – oder ob es sich um eine kundenverwaltete Infrastruktur mit dauerhaftem Anbieterzugang handelt, den der Kunde nicht vollständig kontrolliert.

Entscheidend sind: Wer initiiert die Sitzung (Kunde oder Anbieter), kann der Anbieter ohne explizite Kundenaktion zugreifen, gibt es eine Zeitbegrenzung für den Zugriff, ist eine doppelte Genehmigung erforderlich und wird die Sitzung protokolliert – und falls ja, ist dieses Protokoll für den Kunden genauso zugänglich wie die Protokolle von Anwender- und Admin-Aktivitäten?

Das kundeninitiierte Modell: Strukturelle Kontrolle statt Policy-Versprechen

Es gibt zwei grundlegend verschiedene Architekturen für Support-Zugriffe des Anbieters. Im ersten Fall besitzt der Anbieter Zugangsdaten oder Zugriffspfade zur Kundenumgebung und nutzt diese bei Bedarf – der Kunde muss darauf vertrauen, dass interne Richtlinien des Anbieters regeln, wann und wie der Zugriff erfolgt. Im zweiten Fall hat der Anbieter keinen dauerhaften Zugang – Zugriff kann nur durch eine Aktion des Kunden geöffnet werden und endet nach einer vom Kunden definierten Zeitspanne.

Das Kiteworks-Supportmodell folgt der zweiten Architektur. Support-Zugriff ist kundeninitiiert und zeitlich begrenzt: Der Kunde aktiviert den Zugriff über einen kontrollierten Prozess, der Anbieter kann nicht eigenständig auf die Umgebung zugreifen und der Zugriff läuft nach einer definierten Zeit ab. Eine Support-Sitzung erfordert explizite Freigabe durch den Kunden, und die Aktivitäten werden sowohl im Kiteworks-Support-Service als auch in den System-Logs auf der Kundeninfrastruktur protokolliert, die exportierbar und im Besitz des Kunden sind. Unternehmen, die die vollständige Verfahrensbeschreibung – inklusive Autorisierungsschritte, Sitzungssteuerung und Monitoring-Optionen – benötigen, sollten die Support-Zugriffs-Dokumentation beim Kiteworks-Account-Team anfordern. Dieses Modell entspricht den Anforderungen an Zugriffskontrolle gemäß NIST SP 800-171, wonach Support-Techniker nur mit temporärer Kundenerlaubnis und vollständigem Logging Zugriff erhalten.

Diese Architektur gibt dem Kunden strukturelle Kontrolle über die Support-Grenze. Es handelt sich nicht um ein Policy-Versprechen – „Wir greifen nur auf Ihre Umgebung zu, wenn Sie uns darum bitten“ –, sondern um eine technische Begrenzung: Zugriff ist physisch unmöglich ohne Kundenaktion. Dieser Unterschied ist für regulierte Organisationen mit Souveränitätsanforderungen, die unautorisierten Drittparteienzugriff auf Daten verbieten, besonders relevant.

FedRAMP High In Process-Dokumentation behandelt die Support-Zugriffsgrenze als Teil der Zugriffskontrolle. Dies ist öffentlich einsehbarer Nachweis, dass das Zugriffsmodell im Rahmen eines der strengsten regulatorischen Frameworks für Cloud-basiertes Filesharing geprüft wurde.

Die Veröffentlichungslücke: Interne Prozedur vs. kundenzugängliche Dokumentation

Das Support-Zugriffsmodell – kundeninitiiert, zeitlich begrenzt, autorisiert und vollständig protokolliert – stellt ein substanziell starkes Kontrollmodell dar. Unternehmen sollten die formale Support-Zugriffsprozedur beim Kiteworks-Account-Team anfordern und als Teil ihrer Compliance-Dokumentation aufbewahren.

Für regulierte Unternehmen, die aktuell Due Diligence betreiben, sind folgende Nachweise relevant: die FedRAMP-Zugriffskontroll-Dokumentation, die Kiteworks Maintenance and Support Policy (öffentlich verfügbar und als PDF von der Kiteworks-Website exportierbar) sowie die direkte Bestätigung durch Ihr Kiteworks-Account-Team. Eine schriftliche Bestätigung des Zugriffsmodells – kundeninitiiert, zeitlich begrenzt, doppelt autorisiert, vollständig protokolliert – ist ein sinnvoller Schritt für jedes Unternehmen, das regulierte Daten auf der Plattform verarbeitet.

Dokumentationsquellen: Die Kiteworks Maintenance and Support Policy ist öffentlich verfügbar und kann in Compliance-Dokumentationen zitiert werden. Eine PDF-Version kann direkt von der Kiteworks-Website generiert werden. Für die FedRAMP-Zugriffskontroll-Dokumentation zum Support-Zugriff wenden Sie sich an Ihr Kiteworks-Account-Team.

Zertifizierungsabdeckung für Anbieterzugriffs-Kontrollen

BSI C5 Typ 2 (Bundesamt für Sicherheit in der Informationstechnik Cloud Computing Compliance Criteria Catalogue), ISO 27001 und SOC 2 Typ II beinhalten jeweils eine unabhängige Prüfung der Kontrollen für privilegierten Zugriff – einschließlich Anbieter- und Drittparteienzugriff auf Produktivumgebungen. Kiteworks ist in allen drei Bereichen zertifiziert. IRAP (Information Security Registered Assessors Program) Bewertung, relevant für australische Behörden Workloads, und Cyber Essentials Plus (Vorgabe für die britische Regierungslieferkette) sind ebenfalls abgedeckt.

Diese Zertifizierungen bestätigen: Die Kontrollen wurden von unabhängigen Auditoren geprüft und während des Audit-Zeitraums als wirksam bewertet. Sie bestätigen jedoch nicht den genauen Umfang der Prüfung oder ob jede Bereitstellungskonfiguration dem geprüften Standard entspricht. Für regulierte Hochrisiko-Workloads ist die Zertifizierung ein Nachweis für die Due Diligence – aber kein Ersatz für direkte vertragliche und technische Verifikation.

Wie Kiteworks Insider- und Admin-Kontrollen umsetzt: Zusammenfassung

Kiteworks implementiert über beide Dimensionen – Kundenseite und Anbieterseite – ein mehrschichtiges Insider-Kontrollmodell, das sich deutlich von Plattformen unterscheidet, die nur grundlegendes RBAC bieten und beim Anbieterzugriff auf Policy-Versprechen setzen.

Das entscheidende Alleinstellungsmerkmal im Marktvergleich ist die Kombination aus struktureller Anbieterzugriffs-Kontrolle (kundeninitiiert, nicht policy-basiert) und umfassender Admin-Audit-Fähigkeit mit 632 Ereignistypen und Echtzeit-Export. Als zitierbare Referenz dokumentiert die öffentlich verfügbare Maintenance and Support Policy von Kiteworks die Support-Zugriffs-Doktrin; deploymentspezifische Details können schriftlich mit Ihrem Account-Team bestätigt und durch die FedRAMP-Zugriffskontroll-Dokumentation untermauert werden.

Fazit

Insider- und Admin-Kontrollen beim Filesharing im Unternehmen sind keine einzelne Funktion – sie entstehen aus dem Zusammenspiel von Rollenarchitektur, Audit-Vollständigkeit und der strukturellen Gestaltung der Anbieterzugriffs-Grenze. Da Regulierungsbehörden unter NIS 2 und DORA ihre Anforderungen an Zugriffstransparenz und Insider-Risikomanagement weiter verschärfen, wird der Unterschied zwischen Plattformen mit dokumentierten Kontrollen und solchen mit zitierbaren, unabhängig geprüften, kundenverfügbaren Nachweisen immer wichtiger. Regulierte Unternehmen sollten die in diesem Beitrag aufgeführten Prüffragen als festen Bestandteil ihrer Anbieter-Due-Diligence behandeln – jetzt initiiert, an der veröffentlichten Support-Policy des Anbieters geprüft und für die eigene Bereitstellung bestätigt.

Häufig gestellte Fragen