Warum Sie möglicherweise mehrere Interaktionen mit einer einzigen Drittpartei haben
Beim Onboarding einer bestimmten Drittpartei führen Sie möglicherweise für jede Art von Beziehung, die Sie zu der Drittpartei haben, eine separate Interaktion durch. Ein Projekt besteht in der Bewertung des Risikos, das mit der Entwicklung von Software durch eine Drittpartei für Ihre Organisation verbunden ist, und ein anderes Projekt bezieht sich auf den Facility-Management-Service, den die Drittpartei bereitstellt.
Verschiedene Interaktionen derselben Drittpartei erfordern möglicherweise unterschiedliche Risikobewertungen
Verschiedene Interaktionen derselben Drittpartei können unterschiedliche Ebenen der Risikobewertung erfordern, aufgrund von Unterschieden bei der Art der bereitgestellten Services, der Zugriffsebene auf vertrauliche Daten oder kritische Systeme und den potenziellen Auswirkungen auf die Infrastruktur Ihrer Organisation. Indem Sie für jede Interaktion eine separate Risikobewertung durchführen, können Sie Ihre Risikomanagementstrategien und -kontrollen anpassen, um die mit jeder Interaktion verbundenen Risiken effektiv anzugehen.
Beispiel: Die Drittpartei stellt zwei unterschiedliche Services bereit
- Service: Software Development Engagement
- Die Drittpartei ist für die Entwicklung einer benutzerdefinierten Softwareanwendung für das Finanzinstitut verantwortlich. Diese Interaktion beinhaltet den Zugriff der Drittpartei auf vertrauliche Kundendaten und deren Verarbeitung, die Integration kritischer Systeme und die potenzielle Implementierung von Changes an der Infrastruktur des Unternehmens.
- Service: Facility Management
- Die Drittpartei ist auch für die Verwaltung der physischen Sicherheit und die Wartung der Bürogebäude des Finanzinstituts verantwortlich. Diese Interaktion umfasst die Bereitstellung von Sicherheitspersonal, die Verwaltung von Zugangskontrollsystemen und die Bestätigung der allgemeinen Sicherheit und Wartung der Einrichtungen.
- Interaktion für den Software-Entwicklungsservice
Diese Interaktion beinhaltet aufgrund der folgenden Faktoren ein höheres Risiko:
- Zugriff auf vertrauliche Daten: Die Drittpartei hat Zugriff auf Kundendaten, was strenge Datenschutzkontrollen erfordert, um nicht autorisierten Zugriff oder Datenschutzverletzungen zu verhindern.
- Systemintegration: Die Software der Drittpartei muss in kritische Systeme integriert werden, was sich möglicherweise auf die Stabilität, Verfügbarkeit oder Sicherheit dieser Systeme auswirkt. Richtige Test- und Qualitätssicherungsverfahren sind entscheidend, um das Risiko von Systemfehlern oder Schwachstellen zu minimieren.
- Change-Management: Die Einführung neuer Software oder Änderungen an vorhandenen Systemen kann Risiken wie Kompatibilitätsprobleme, Systemunterbrechungen oder Softwareschwachstellen mit sich bringen. Um diese Risiken zu minimieren, sind robuste Change-Management-Praktiken und Codeüberprüfungsprozesse erforderlich.
- Interaktion für den Facility Management-Service
Obwohl an dieser Interaktion auch dieselbe Drittpartei beteiligt ist, ist das Risikoprofil im Vergleich zur Softwareentwicklungsinteraktion niedriger:
- Physische Sicherheit: Der Schwerpunkt liegt auf der Verwaltung physischer Sicherheitsmaßnahmen wie Zugriffskontroll- und Überwachungssystemen. Die mit der physischen Sicherheit verbundenen Risiken sind zwar immer noch wichtig, doch im Vergleich zu den Cybersicherheitsrisiken sind sie in der Regel einfacher und leichter zu verwalten.
- Wartung und Sicherheit: Die Verantwortung der Drittpartei bezieht sich in erster Linie auf die allgemeine Wartung und die Förderung einer sicheren Arbeitsumgebung. Zwar sind mit der Wartung von Gebäuden immer noch Risiken verbunden (z. B. Sicherheitsrisiken), aber im Vergleich zu den komplexen Cybersicherheitsrisiken bei der Softwareentwicklung sind sie möglicherweise besser vorhersehbar und überschaubar.