SaaS Security Posture Management für Audits 2026

Die SaaS-Auditfeststellung, für die niemand verantwortlich war

Um 08:15 Uhr an einem Dienstag erhält der CISO eines schnell wachsenden Fintechs eine Nachricht vom Datenschutzbeauftragten: „Warum kann ein Kundenexport aus einem Kollaborationstool öffentlich freigegeben werden, und wer hat die OAuth-App genehmigt, die darauf Lesezugriff hat?“

Um 09:00 Uhr bestätigt die Finanzabteilung, dass das Tool über eine Abteilungskarte bezahlt wird und nicht über die zentrale Beschaffung. Um 10:30 Uhr stellt die IT fest, dass der Benutzer, der den öffentlichen Link erstellt hat, das Unternehmen vor drei Monaten verlassen hat. Gegen Mittag fragt die Rechtsabteilung, ob es sich um eine Verletzung des Schutzes personenbezogener Daten nach GDPR handelt. Um 14:00 Uhr fragt der Risikoausschuss, ob das Problem die NIS2-Cyberhygiene und das DORA-IKT-Drittparteienrisiko betrifft. Um 16:00 Uhr fordert der interne Auditor Baseline-Konfigurationen, Berechtigungsüberprüfungen für Administratoren, Verantwortlichkeiten für Cloud-Services, Protokolle und Lieferanten-Due-Diligence an.

Die schmerzhafte Wahrheit ist: Die Organisation hatte keinen klassischen SaaS-Ausfall und kein Lieferantenversagen. Sie hatte ein Governance-Versagen.

Dieses Szenario ist nicht mehr außergewöhnlich. Ein Marketingteam verbindet eine KI-Plattform mit einem CRM und gewährt weitreichende OAuth-Berechtigungen. HR kauft außerhalb der Beschaffung ein spezialisiertes Analysewerkzeug. Ein Kundensupport-Team aktiviert aus Bequemlichkeit öffentliche Ticketexporte. Engineering integriert eine Browsererweiterung in einen Entwicklungsworkflow. Jede Entscheidung mag klein erscheinen; zusammen erzeugen sie jedoch eine verteilte Kontrollfläche mit regulierten Daten, privilegierten Workflows und betrieblichen Abhängigkeiten.

SaaS Security Posture Management, kurz SSPM, ist die Disziplin, die diese verstreute SaaS-Realität in gesteuerte, geprüfte und auditierbare Kontrolle überführt. Richtig umgesetzt liefert SSPM CISOs, Compliance-Managern, Auditoren und Geschäftsverantwortlichen einen einheitlichen Nachweispfad für ISO/IEC 27001:2022, NIS2-Cyberhygiene, DORA-IKT-Risiken und Sicherheitsverantwortung nach GDPR.

Clarysecs Position ist klar: SSPM darf nicht als weiteres Dashboard behandelt werden. Es muss in das ISMS eingebettet, mit Risikoverantwortung verknüpft, auf rechtliche Verpflichtungen abgebildet, durch Richtlinien gestützt und anhand wiederkehrender Nachweise geprüft werden.

Hier werden Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls und Clarysec-Richtlinienvorlagen praktisch nutzbar. Sie helfen, SaaS-Wildwuchs in ein Kontrollmodell zu überführen, das ein Auditor nachvollziehen und ein Leitungsorgan überwachen kann.

Warum SaaS Security Posture Management zu einem Compliance-Thema wurde

SaaS wurde früher als „Software, die jemand anderes betreibt“ behandelt. Diese Sichtweise ist nicht mehr belastbar.

Unter NIS2 können viele Cloud-, SaaS-, digitale Infrastruktur-, Managed-Service- und Managed-Security-Anbieter je nach Branche, Größe, Rolle und Kritikalität unter regulierte Cybersicherheitserwartungen fallen. Noch wichtiger ist: Organisationen, die auf SaaS angewiesen sind, müssen SaaS als Teil ihrer eigenen Risikomanagementmaßnahmen steuern. NIS2 Artikel 20 macht Leitungsorgane dafür verantwortlich, Cybersicherheits-Risikomanagementmaßnahmen zu genehmigen, deren Umsetzung zu überwachen und Schulungen zu erhalten. Artikel 21 verlangt praktikable technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Richtlinien, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sicherer Beschaffung und Wartung, Wirksamkeitsprüfung, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und Mehrfaktor-Authentifizierung, soweit angemessen.

DORA legt für Finanzunternehmen die Messlatte höher. Seit dem 17. Januar 2025 gilt DORA für viele Organisationen des Finanzsektors als Rechtsrahmen für digitale operationale Resilienz. DORA verlangt IKT-Governance, Identifizierung und Klassifizierung von IKT-Assets und unterstützten Funktionen, Schutz- und Präventionsmaßnahmen, Vorfallmanagement, Kontinuität, Tests und Management von IKT-Drittparteienrisiken. SaaS-Anbieter, die kritische oder wichtige Funktionen unterstützen, werden Teil des DORA-Nachweisumfangs, während das regulierte Finanzunternehmen verantwortlich bleibt.

GDPR ergänzt eine Datenschutz-Nachweisebene. Artikel 5 verlangt Integrität, Vertraulichkeit und Rechenschaftspflicht. Artikel 32 verlangt angemessene Sicherheit der Verarbeitung. Praktisch muss eine Organisation wissen, welche personenbezogenen Daten vorhanden sind, wo sie verarbeitet werden, wer darauf zugreifen kann, welche Lieferanten sie verarbeiten und welche Schutzmaßnahmen sie schützen. Eine SaaS-Fehlkonfiguration macht aus diesen Fragen dringende Fragen zur Bewertung einer Datenschutzverletzung.

ISO/IEC 27001:2022 bildet die Brücke. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation Kontext, Anforderungen interessierter Parteien, Geltungsbereich, Schnittstellen und Abhängigkeiten definiert. Klausel 5 verlangt Führung, Richtlinie, Rollen und Rechenschaftspflicht. Die Klauseln 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, die Anwendbarkeitserklärung und Entscheidungen zum Restrisiko. Die Klauseln 8.1, 8.2 und 8.3 verlangen operative Planung, Risikobeurteilung und Risikobehandlung. Die Klauseln 9 und 10 verlangen Überwachung, internes Audit, Managementbewertung und Verbesserung.

Wenn Sie nicht beantworten können, welche SaaS-Tools regulierte Daten verarbeiten, wer sie verantwortet, wie sie konfiguriert sind, wer Administratorzugriff hat, welche Integrationen aktiv sind und welche Nachweise die Wirksamkeit der Kontrollen belegen, ist Ihre Compliance-Position fragil.

Das Clarysec-SSPM-Modell: Inventar, Verantwortung, Baseline, Nachweise

Clarysec behandelt SaaS Security Posture Management als wiederholbaren Kontrollzyklus, nicht als einmaliges Bereinigungsprojekt.

1. Jeden SaaS-Service ermitteln, einschließlich Shadow SaaS.
2. Einen fachlichen Verantwortlichen und einen technischen Verantwortlichen zuweisen.
3. Daten, Benutzer, Integrationen und betriebliche Kritikalität klassifizieren.
4. Sichere Baseline-Konfigurationen anwenden.
5. Benutzer, Administratoren, Gäste, Servicekonten und OAuth-Berechtigungsumfänge überprüfen.
6. Protokollierung, Alarmierung und Aufbewahrung aktivieren.
7. Öffentliche Freigaben und Datenexposition überwachen.
8. Lieferanten, Verträge, Auftragsverarbeitungsverträge und Exit-Planung verknüpfen.
9. Nachweise in einem definierten Rhythmus sammeln.
10. Feststellungen in Risikobehandlung, Managementbewertung und Verbesserung einspeisen.

Dieses Modell ist eng an die Maßnahmen aus ISO/IEC 27002:2022 ISO/IEC 27002:2022 ausgerichtet, insbesondere 5.9 Inventar von Informationen und anderen zugehörigen Assets, 5.15 Zugriffskontrolle, 5.18 Zugriffsrechte, 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.20 Behandlung von Informationssicherheit in Lieferantenvereinbarungen, 5.21 Management der Informationssicherheit in der IKT-Lieferkette, 5.23 Informationssicherheit bei der Nutzung von Cloud-Services, 8.2 privilegierte Zugriffsrechte, 8.3 Einschränkung des Informationszugriffs, 8.9 Konfigurationsmanagement, 8.15 Protokollierung, 8.16 Überwachungstätigkeiten und 8.32 Änderungsmanagement.

Der Zenith Blueprint führt in der Phase „Controls in Action“, Schritt 23 zu organisatorischen Maßnahmen, aus:

Die Cloud ist kein Ziel mehr, sondern der Standard. Von Speicher bis Zusammenarbeit, von Infrastruktur bis maschinellem Lernen: Organisationen werden zunehmend auf Schichten von Drittparteien-, abstrahierten und remote verwalteten Umgebungen aufgebaut. Maßnahme 5.23 erkennt diese Realität an und verlangt, dass Informationssicherheit bei Auswahl, Nutzung und Management von Cloud-Services ausdrücklich berücksichtigt wird – nicht als nachträglicher Gedanke, sondern von Beginn an als Gestaltungsprinzip.

Das ist der Kern von SSPM. Es geht nicht nur darum, Fehlkonfigurationen nachträglich zu erkennen. SaaS-Auswahl, Onboarding, Betrieb, Überwachung und Exit müssen Teil des Managementsystems werden.

Derselbe Abschnitt des Zenith Blueprint erläutert die Realität geteilter Verantwortung in einer Sprache, die jedes Leitungsorgan hören sollte:

Cloud-Anbieter sichern die Infrastruktur, aber Sie bleiben für Ihre Daten, Ihre Konfigurationen, Ihre Zugriffsrichtlinien und Ihre Vorfallsbereitschaft verantwortlich. Ein falsch konfigurierter Storage Bucket, ein öffentlich exponiertes Dashboard oder übermäßige Berechtigungen in einer Cloud-IAM-Konfiguration sind keine Cloud-Ausfälle. Es sind Governance-Versagen.

Ihr Anbieter kann die Plattform betreiben, aber Sie bleiben für Mandantenkonfiguration, Identitäten, Zugriffsgenehmigungen, exponierte Daten, Integrationen, Incident-Workflows und Compliance-Nachweise verantwortlich.

Maßnahme 5.23 ist der Anker, aber SSPM braucht eine Kontrollfamilie

In Zenith Controls wird ISO/IEC 27002:2022 Maßnahme 5.23, Informationssicherheit bei der Nutzung von Cloud-Services, als präventive Kontrolle kategorisiert, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Ihr Cybersicherheitskonzept ist Protect, mit operativer Fähigkeit im Bereich Sicherheit von Lieferantenbeziehungen und Domänen über Governance, Ökosystem und Schutz hinweg.

Das ist wichtig, weil SSPM keine einzelne Kontrolle ist. Es ist eine kontrollübergreifende Disziplin.

Zenith Controls verknüpft 5.23 mit Lieferantenbeziehungen unter 5.19, weil SaaS-Anbieter kritische Lieferanten sind; 5.23 ergänzt jedoch SaaS-spezifische Aspekte wie Mandantenfähigkeit, Transparenz über Datenstandorte und geteilte Verantwortung. 5.23 wird mit Informationsübertragung verknüpft, weil APIs, Integrationen und SaaS-übergreifende Workflows Daten laufend bewegen. 5.23 wird mit Asset-Inventar verknüpft, weil Organisationen aktuelle Transparenz über in der Cloud gespeicherte Daten und SaaS-Ressourcen benötigen. Außerdem verbindet die Maßnahme Cloud-Governance mit Überwachung, Zugriffsbeschränkung, Konfigurationsmanagement und Lieferantenaufsicht.

Für Zugriffsrechte bildet Zenith Controls 5.18 auf 5.15 Zugriffskontrolle, 5.16 Identitätsmanagement, 5.3 Funktionstrennung, 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit sowie 8.2 privilegierte Zugriffsrechte ab. Für SSPM bedeutet das: Die Berechtigungsüberprüfung ist nicht nur eine Tabellenübung. Sie ist ein operativer Nachweis, dass Identitätslebenszyklus, Prinzip der minimalen Berechtigung, Funktionstrennung und Governance für privilegierten Zugriff innerhalb von SaaS-Anwendungen funktionieren.

Richtlinienfundament: erst gute Praxis definieren, dann Werkzeuge kaufen

Viele SaaS-Fehler beginnen mit vager Richtliniensprache. „Genehmigte Tools sicher verwenden“ reicht nicht aus. Clarysec-Richtlinien definieren konkrete Erwartungen an Register, Zugriff, Protokollierung, Konfiguration und Lieferantenprüfung.

Für KMU bietet die KMU-Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten - KMU einen praktikablen Einstieg. Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3:

Ein Register für Cloud-Services muss vom IT-Dienstleister oder von der Geschäftsführung geführt werden. Es muss erfassen: 5.3.1 Name und Zweck jedes genehmigten Cloud-Service 5.3.2 Die verantwortliche Person oder das verantwortliche Team (Anwendungsverantwortlicher) 5.3.3 Die Arten der gespeicherten oder verarbeiteten Daten 5.3.4 Das Land oder die Region, in dem bzw. der die Daten gespeichert werden 5.3.5 Benutzerzugriffsberechtigungen und Administratorkonten 5.3.6 Vertragsdetails, Verlängerungstermine und Supportkontakte

Diese Klausel ist der operative Kern von SSPM. Sie liefert Auditoren das erste Nachweisobjekt: ein Register, das SaaS-Nutzung mit Verantwortlichen, Daten, Geografie, Zugriff und Verträgen verbindet.

Dieselbe KMU-Richtlinie zur Nutzung von Cloud-Diensten definiert im Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2, Baseline-Einstellungen:

Anforderungen an die Sicherheitskonfiguration 6.2.1 Folgendes muss auf allen Cloud-Plattformen aktiviert sein: 6.2.2 Multi-Faktor-Authentifizierung (MFA) für administrative und Benutzerkonten 6.2.3 Einstellungen zur Passwortkomplexität (mindestens 10 Zeichen, keine Wiederverwendung) 6.2.4 Aktivitätsprotokollierung für Anmeldeversuche und Datenzugriffe 6.2.5 Zugriffsbeschränkungen (z. B. IP-Positivlisten, sofern unterstützt) 6.2.6 Administrativer Zugriff muss auf benannte Personen oder autorisierte Support-Dienstleister beschränkt sein. 6.2.7 Öffentlich freigegebene Inhalte müssen regelmäßig überwacht werden, um Datenabfluss zu verhindern. 6.2.8 Wenn Benutzerkonten nicht mehr erforderlich sind, muss der Zugriff unverzüglich entzogen werden; verbleibende Daten müssen überprüft und archiviert oder gelöscht werden.

Für Unternehmensumgebungen weist die Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten eine stärkere zentrale Governance zu. Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3:

Jeder Cloud-Service muss einen zugewiesenen Serviceverantwortlichen haben, der für das Management des Informationswert-Lebenszyklus, die Nutzungs-Governance, die Budgetverfolgung und die laufende Compliance-Überwachung verantwortlich ist.

Dieser Satz schließt eine häufige Audit-Lücke. Wenn niemand einen SaaS-Service verantwortet, verantwortet auch niemand Abweichungen von der Baseline-Konfiguration, Berechtigungsrezertifizierung, Datenexposition, Verlängerungsentscheidungen, Vorfallkontakte oder Exit-Planung.

Governance für Berechtigungen muss ebenfalls ausdrücklich geregelt sein. Die KMU-Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen - KMU legt im Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4, fest:

Berechtigungsüberprüfungen und Protokollierung 6.4.1 Eine Überprüfung aller Benutzerkonten und Berechtigungen muss alle sechs Monate durchgeführt werden. 6.4.2 Während der Überprüfungen muss die IT-Leitung prüfen, ob jedes Konto weiterhin aktiv, erforderlich und mit den korrekten Berechtigungen versehen ist. 6.4.3 Protokolle zur Kontobereitstellung, Kontodeaktivierung und zu Berechtigungsänderungen müssen mindestens 12 Monate sicher aufbewahrt werden.

Für SaaS benötigt jede kritische Plattform einen definierten Zyklus für Berechtigungsüberprüfungen, selbst wenn die Plattform von einem Fachbereich statt von der zentralen IT administriert wird.

Auch Protokollierung muss ausdrücklich geregelt sein. Die KMU-Richtlinie zur Protokollierung und Überwachung Richtlinie zur Protokollierung und Überwachung - KMU legt im Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.5, fest:

Cloud-Services und Protokollierung durch Dritte 5.5.1 Für Plattformen, bei denen die Protokollierung nicht unter direkter IT-Kontrolle steht (z. B. SaaS-E-Mail), gelten die folgenden Anforderungen: 5.5.1.1 Protokollierung muss aktiviert und konfiguriert werden, soweit verfügbar 5.5.1.2 Warnmeldungen müssen an den IT-Support-Dienstleister weitergeleitet werden 5.5.1.3 Verträge müssen Anbieter verpflichten, Protokolle mindestens 12 Monate aufzubewahren und auf Anfrage Zugriff bereitzustellen

Schließlich muss die SaaS-Lieferanten-Governance dokumentiert werden. Die KMU-Richtlinie zur Lieferanten- und Drittparteiensicherheit Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU legt im Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3, fest:

Laufende Überwachung der Lieferantensicherheit 6.3.1 Kritische Lieferanten oder Lieferanten mit hohem Risiko müssen mindestens jährlich überprüft werden. Die Überprüfung muss verifizieren: 6.3.1.1 Fortgesetzte Nutzung sicherer Zugriffsmethoden 6.3.1.2 Gültige Sicherheitszertifizierungen oder aktualisierte Kontrollnachweise 6.3.1.3 Vorfallhistorie oder gemeldete Probleme 6.3.1.4 Einhaltung vertraglicher Anforderungen an Sicherheitsklauseln 6.3.2 Diese Überprüfungen müssen dokumentiert und zusammen mit dem Lieferantendatensatz aufbewahrt werden. Folgemaßnahmen müssen eindeutig nachverfolgt werden. 6.3.3 Wenn Lieferanten IT-Infrastruktur oder Anwendungen verwalten, kann die Überwachung Folgendes umfassen: 6.3.3.1 Anforderung von Audit-Protokollen 6.3.3.2 Überprüfung der Kontoaktivität 6.3.3.3 Bestätigung, dass kein nicht autorisierter Zugriff erfolgt ist

Zusammen überführen diese Richtlinien SSPM von einem Sicherheitsanspruch in ein verbindliches Betriebsmodell.

Ein 30-tägiger SSPM-Nachweissprint

Ein praxisorientierter CISO oder Compliance-Manager kann mit einem 30-tägigen Nachweissprint beginnen. Wählen Sie die fünf SaaS-Plattformen aus, die für regulierte Daten oder kritische Abläufe am wichtigsten sind. Typische Kandidaten sind Microsoft 365 oder Google Workspace, CRM, Ticketsystem, HRIS, Finanzautomatisierung, Kundensupport und Analytik.

Woche 1: Das SaaS-Register erstellen

Nutzen Sie die Felder aus Klausel 5.3 der KMU-Richtlinie zur Nutzung von Cloud-Diensten als Mindestregister. Erfassen Sie für jeden SaaS-Service:

• Servicename und geschäftlicher Zweck
• Anwendungsverantwortlicher und technischer Verantwortlicher
• Datenarten, einschließlich personenbezogener Daten und besonderer Kategorien personenbezogener Daten, soweit anwendbar
• Land oder Region der Datenspeicherung
• Benutzergruppen und Administratorkonten
• OAuth-Apps und Drittanbieter-Integrationen
• Vertragsverantwortlicher, Verlängerungstermin und Supportkontakt
• Kritikalität für den Betrieb
• Anwendbare Verpflichtungen, etwa NIS2, DORA, GDPR oder Kundenverträge

Dies unterstützt ISO/IEC 27001:2022 Klauseln 4.2 und 4.3, weil regulatorische, vertragliche und Drittparteienabhängigkeiten den ISMS-Geltungsbereich prägen müssen. Es unterstützt außerdem die Identifizierung und Klassifizierung IKT-gestützter Geschäftsfunktionen, Informations-Assets, IKT-Assets und Abhängigkeiten im Sinne von DORA Artikel 8.

Woche 2: Sichere Baseline-Konfigurationen definieren

Definieren Sie für jede ausgewählte SaaS-Plattform 10 bis 15 Baseline-Kontrollen.

• MFA für alle Benutzer durchgesetzt, mit phishing-resistenter MFA für Administratoren, soweit möglich
• Externe Freigabe standardmäßig deaktiviert oder auf genehmigte Domänen beschränkt
• Öffentliche Links deaktiviert oder zeitlich begrenzt
• Gastkonten monatlich überprüft
• Administratorrollen benannten Personen zugewiesen
• Legacy-Authentifizierung deaktiviert
• Genehmigungs-Workflow für OAuth-Apps aktiviert
• Risikobehaftete OAuth-Berechtigungsumfänge blockiert oder nur mit Sicherheitsfreigabe zulässig
• Audit-Protokollierung aktiviert
• Berechtigungen für Datenexport eingeschränkt
• Aufbewahrungseinstellungen an rechtlichen und geschäftlichen Anforderungen ausgerichtet
• API-Token überprüft und rotiert
• Sicherheitswarnmeldungen an IT oder SOC weitergeleitet
• Data Loss Prevention (DLP)-Einstellungen aktiviert, sofern unterstützt
• Break-Glass-Konten dokumentiert und überwacht

Der Zenith Blueprint erläutert in der Phase „Controls in Action“, Schritt 19, Maßnahme 8.9 Konfigurationsmanagement, warum dies relevant ist:

Viele Verstöße entstehen nicht durch Softwarefehler, sondern durch schlechte Konfigurationsentscheidungen. Unveränderte Standardpasswörter, aktivierte unsichere Dienste, unnötig offene Ports oder ohne Begründung im Internet exponierte Systeme. Maßnahme 8.9 stellt sicher, dass jedes System auf einer sicheren Baseline-Konfiguration aufgebaut und regelmäßig überprüft wird, um Abweichungen im Zeitverlauf zu verhindern.

Für SaaS umfasst Abweichung von der Baseline-Konfiguration etwa einen Geschäftsverantwortlichen, der öffentliche Freigabe aktiviert, einen Administrator, der weitreichenden Drittparteienzugriff genehmigt, oder einen Anbieter, der nach einem Funktions-Release Standardeinstellungen ändert.

Woche 3: Zugriff und Integrationen überprüfen

Exportieren Sie Benutzer, Gruppen, Administratoren und verbundene Anwendungen. Bestätigen Sie für jedes Administratorkonto die benannte Person, geschäftliche Begründung, MFA-Status, letzte Anmeldung, Berechtigungsstufe, Backup-Abdeckung, mögliche Konflikte zur Funktionstrennung und Genehmigungsnachweise.

Bestätigen Sie für OAuth-Apps und Integrationen den App-Verantwortlichen, die zugänglichen Daten, die angeforderten Berechtigungen, den Lieferantenrisikostatus, das Datum der letzten Nutzung, den fortbestehenden Bedarf und ob die Zustimmung durch Benutzer erteilt oder durch Administratoren genehmigt wurde.

Der Zenith Blueprint formuliert in der Phase „Controls in Action“, Schritt 19, Maßnahme 8.3 Einschränkung des Informationszugriffs, das operative Prinzip:

Zugriff auf Informationen sollte so offen wie nötig, aber so eingeschränkt wie möglich sein.

Das gilt nicht nur für Personen, sondern auch für Anwendungen, Dienste und APIs. Eine inaktive OAuth-Integration kann Zugriff behalten, lange nachdem der Mitarbeitende oder das Projekt, das sie erstellt hat, verschwunden ist.

Woche 4: Auditbereite Nachweise und Risikobehandlung erstellen

Speichern Sie für jede SaaS-Plattform den Registereintrag, die Baseline-Konfiguration, Screenshots oder Exporte zum Nachweis zentraler Einstellungen, die Freigabe der Berechtigungsüberprüfung, Nachweise zur Administratorüberprüfung, Nachweise zur OAuth-Überprüfung, Nachweise zu Protokollierung und Alarmierung, den Nachweis zur Lieferantensicherheitsüberprüfung, offene Feststellungen und Maßnahmen zur Risikobehandlung.

Erstellen Sie anschließend eine einseitige Management-Zusammenfassung mit kritischen Feststellungen, überfälligen Verantwortlichen, ungelösten risikobehafteten Konfigurationslücken, nicht genehmigten Integrationen, Protokollierungslücken, Ausnahmen und erforderlichen Entscheidungen. Dies unterstützt ISO/IEC 27001:2022 Klausel 9.1 Überwachung, Klausel 9.2 internes Audit und Klausel 9.3 Managementbewertung. Es schafft zudem eine praktische Brücke zu NIS2 Artikel 20 Management-Rechenschaftspflicht und DORA-Aufsicht durch das Leitungsorgan.

Cross-Compliance-Abbildung: ein SSPM-Nachweispaket, viele Verpflichtungen

Der geschäftliche Nutzen von SSPM liegt nicht nur in besserer Sicherheit. Er liegt auch in reduzierter Mehrfacharbeit bei der Compliance.

NIS2 Artikel 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen. Ein SaaS-Inventar unterstützt Asset-Management. Baseline-Konfigurationen unterstützen Cyberhygiene. MFA und Berechtigungsüberprüfungen unterstützen Zugriffskontrolle. Protokollierung unterstützt den Umgang mit Informationssicherheitsvorfällen. Lieferantenprüfung unterstützt Sicherheit der Lieferkette. Ein Nachweisrhythmus unterstützt Richtlinien und Verfahren zur Bewertung der Wirksamkeit.

DORA verlangt von Finanzunternehmen, IKT-gestützte Funktionen, Informations-Assets, IKT-Assets und Drittparteienabhängigkeiten zu identifizieren und zu klassifizieren. Es verlangt außerdem Schutz- und Präventionsmaßnahmen, Zugriffskontrollen, starke Authentifizierung, Verschlüsselung, Kontinuität, Tests, Vorfallmanagement und Governance für IKT-Drittparteienrisiken. Ein SaaS-SSPM-Nachweispaket kann DORA-Register, Abhängigkeitskartierung, Vertragsaufsicht, Auditrechte und Exit-Planung unterstützen.

GDPR verlangt von Verantwortlichen, die Einhaltung von Integrität, Vertraulichkeit und Rechenschaftspflicht nachzuweisen. SaaS-Register zeigen, wo personenbezogene Daten verarbeitet werden. Baseline-Konfigurationen reduzieren unbefugte Offenlegung. Berechtigungsüberprüfungen unterstützen das Prinzip der minimalen Berechtigung. Protokollierung unterstützt die Untersuchung von Datenschutzverletzungen. Lieferantenaufzeichnungen unterstützen Auftragsverarbeiter-Governance und Rechenschaftspflicht.

NIST CSF 2.0 ergänzt eine nützliche Kommunikationsebene. Die GOVERN-Funktion verlangt, dass gesetzliche, regulatorische und vertragliche Cybersicherheitsanforderungen verstanden und gesteuert werden. Die Ergebnisse zur Lieferkette verlangen Lieferantenrollen, Verträge, gebotene Sorgfalt, Überwachung und Aktivitäten nach Beendigung der Geschäftsbeziehung. Die Funktionen IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER lassen sich natürlich auf SaaS-Inventar, Zugriffskontrolle, Datenschutz, Protokollierung, Incident Response und Wiederherstellung abbilden.

COBIT 2019- und ISACA-orientierte Auditoren betrachten SSPM in der Regel über Governance, Managementziele, Risikoverantwortung, Kontrollbetrieb und Assurance. Sie fragen, ob SaaS-Entscheidungen an Unternehmenszielen ausgerichtet sind, ob Risikobehandlungen dokumentiert sind, ob Verantwortlichkeiten zugewiesen wurden und ob Assurance-Aktivitäten belegen, dass Kontrollen wirksam sind.

Die Audit-Perspektive: Wie unterschiedliche Auditoren die SaaS-Sicherheitslage prüfen

Ein starkes SSPM-Programm hält unterschiedlichen Audit-Stilen stand, weil es Nachweise auf der richtigen Ebene liefert.

Ein ISO/IEC 27001:2022-Auditor beginnt mit Geltungsbereich, interessierten Parteien, Risikobeurteilung, Anwendbarkeitserklärung und operativen Nachweisen. Wenn Maßnahme 5.23 enthalten ist, erwartet er Nachweise zu Auswahl, Nutzung, Management und Exit von Cloud-Services. Wenn Kontrollen zu Zugriffsrechten enthalten sind, wird er Benutzer stichprobenartig prüfen und fragen, ob Eintritts-, Wechsel- und Austrittsprozesse in SaaS-Berechtigungen abgebildet sind.

Ein DORA-Prüfer fokussiert auf kritische oder wichtige Funktionen, IKT-Drittparteienabhängigkeit, Registervollständigkeit, Verträge, Vorfallklassifizierung, Tests und Exit-Planung. Wenn eine SaaS-Plattform Zahlungsverkehr, Kunden-Onboarding, Handel, Risikoanalytik oder Kundenkommunikation unterstützt, steigt der Nachweisstandard.

Ein GDPR-Auditor oder Datenschutzprüfer wird fragen, wo personenbezogene Daten gespeichert sind, wer darauf zugreifen kann, welche Exporte und Freigabeeinstellungen existieren, ob Auftragsverarbeiter gesteuert werden, ob Protokolle die Bewertung von Datenschutzverletzungen unterstützen und ob Kontrollen dem Risiko angemessen sind.

Lieferantenrisiko, geteilte Verantwortung und Vorfallsbereitschaft

SSPM beginnt häufig mit Konfiguration, darf dort aber nicht enden. SaaS ist auch ein Thema von Lieferantenrisiko und Vorfallsbereitschaft.

DORA verlangt von Finanzunternehmen, Register zu IKT-Serviceverträgen zu führen, Vereinbarungen zu unterscheiden, die kritische oder wichtige Funktionen unterstützen, Konzentrationsrisiken zu bewerten, die Eignung von Anbietern zu beurteilen und Exit-Strategien aufrechtzuerhalten. Verträge sollten Leistungsbeschreibungen, Datenstandort, Schutz von Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit, Datenzugriff, Wiederherstellung und Rückgabe, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Kündigungsrechte, Sicherheitsanforderungen, Auditrechte und Unterstützung beim Übergang behandeln.

NIS2 Artikel 21 umfasst ebenfalls Sicherheit der Lieferkette und verlangt, dass Einrichtungen spezifische Schwachstellen direkter Lieferanten und Dienstleister, die Qualität von Produkten und die Cybersicherheitspraktiken von Lieferanten berücksichtigen.

In der Praxis sollte eine kritische SaaS-Überprüfung Nachweise aus Sicherheitsfragebögen, Vertragsprüfung, Status des Auftragsverarbeitungsvertrags, Vorfallhistorie, Service-Level-Zusagen, Zugriff auf Protokolle, Auditberichte, Konfigurationsnachweise und Exit-Fähigkeit kombinieren.

Die Lücke der geteilten Verantwortung entsteht, wenn Teams annehmen, die Zertifizierung des Lieferanten decke die Mandantenkonfiguration ab. Das tut sie nicht. Ein Lieferant kann eine sichere Plattform betreiben, während der Kunde öffentliche Freigabe aktiviert, inaktive Administratorkonten bestehen lässt oder übermäßige API-Berechtigungsumfänge gewährt. SSPM schließt diese Lücke.

Vorfallsbereitschaft ist ebenso wichtig. Die NIS2-Meldung erheblicher Sicherheitsvorfälle umfasst eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht spätestens einen Monat nach der 72-Stunden-Meldung. DORA verlangt Management IKT-bezogener Vorfälle mit Erkennung, Aufzeichnung, Klassifizierung, Eskalation, Kommunikation und Meldung. Auch die Bewertung einer Verletzung des Schutzes personenbezogener Daten nach GDPR hängt davon ab, zeitnah zu verstehen, was passiert ist, welche Daten betroffen waren und wer betroffen war.

Wenn eine verdächtige OAuth-App auf Kundendateien zugegriffen hat, müssen Sie wissen, wann die App autorisiert wurde, welcher Benutzer sie autorisiert hat, welche Berechtigungsumfänge gewährt wurden, auf welche Daten zugegriffen wurde, ob Daten heruntergeladen oder freigegeben wurden, welche Benutzer oder Kunden betroffen waren, ob der Zugriff weiterhin aktiv ist und welche Eindämmungsmaßnahmen ergriffen wurden.

Ohne Protokollierung und Aufbewahrung kann die Organisation gezwungen sein, Worst-Case-Annahmen zu treffen. Das erhöht rechtliche Exponierung, Druck in der Kundenkommunikation und regulatorische Unsicherheit. Wenn ein SaaS-Anbieter für Audit-Protokolle zusätzliche Gebühren verlangt, sollte der Risikoverantwortliche das Restrisiko ausdrücklich akzeptieren oder die erforderliche Lizenzstufe genehmigen. Diese Entscheidung gehört in die Aufzeichnung zur Risikobehandlung und in die Managementbewertung.

Häufige SSPM-Fehlermuster

Dieselben Fehlermuster treten branchenübergreifend auf.

Erstens wird Shadow SaaS über Rechnungen, Browserverlauf oder SSO-Protokolle entdeckt statt über die Beschaffung. Die Lösung besteht nicht nur darin, Tools zu blockieren. Erforderlich ist ein schlanker Aufnahmeprozess, den Fachbereiche nutzen können.

Zweitens ist die SaaS-Verantwortung unklar. Das CRM wird „vom Vertrieb verantwortet“, aber niemand im Vertrieb kann Administratorrollen, API-Token, Datenexporte oder Aufbewahrungseinstellungen erklären. Weisen Sie Anwendungsverantwortliche und technische Verantwortliche getrennt zu.

Drittens sind Berechtigungsüberprüfungen zu generisch. Ein Prüfer zeichnet „alle Benutzer genehmigt“ ab, ohne risikobehaftete Rollen, inaktive Benutzer, Gäste, externe Mitwirkende oder Servicekonten zu prüfen. Die SSPM-Berechtigungsüberprüfung muss risikobasiert erfolgen.

Viertens werden OAuth-Apps ignoriert. Viele Organisationen überprüfen menschliche Benutzer, aber keine App-zu-App-Berechtigungen. In modernen SaaS-Umgebungen können Integrationen mächtiger sein als Benutzer.

Fünftens existieren Baseline-Konfigurationen nur als Screenshots aus dem Zertifizierungsprojekt. Sie werden nicht auf Abweichungen überwacht. Richten Sie SSPM am Konfigurationsmanagement aus, damit Baseline-Prüfungen zu wiederkehrenden Nachweisen werden.

Sechstens sind Lieferantenprüfung und SaaS-Sicherheitslagenprüfung getrennt. Die Beschaffung hat den Vertrag, die IT die Administrationskonsole, Datenschutz den Auftragsverarbeitungsvertrag und Security das Risikoregister. Der Auditor sieht Fragmente. SSPM führt sie zusammen.

Managementberichterstattung: SaaS-Risiken für das Leitungsorgan sichtbar machen

NIS2 und DORA machen IKT- und Cybersicherheits-Governance beide zu einem Managementthema. ISO/IEC 27001:2022 verlangt ebenfalls Führung, Ressourcen, Rollenzuweisung, Überwachung und Managementbewertung.

Ein wirksamer SSPM-Managementbericht sollte beantworten:

• Welche kritischen SaaS-Services sind im Geltungsbereich?
• Welche regulierten Prozesse hängen von ihnen ab?
• Welche enthalten personenbezogene Daten oder sensible Geschäftsdaten?
• Bei welchen sind Berechtigungsüberprüfungen überfällig?
• Welche haben ungelöste risikobehaftete Konfigurationslücken?
• Welche haben nicht genehmigte OAuth-Apps oder Integrationen?
• Für welche Lieferanten fehlen aktuelle Sicherheitsnachweise?
• Welche Protokollierungslücken beeinträchtigen die Vorfallmeldung?
• Welche Ausnahmen erfordern Risikoakzeptanz?
• Welche Investitionen oder Entscheidungen sind erforderlich?

Damit wird SSPM von einem technischen Bereinigungsprojekt zu einem Governance-Input. Zugleich wird der CISO wirksamer, weil Risikoakzeptanz auf die richtige Ebene verlagert wird.

SaaS-Sicherheitslage in auditbereite Nachweise überführen

Wenn Ihre Organisation SaaS für regulierte Daten, Finanzabläufe, Kundensupport, HR, Zusammenarbeit, Engineering oder Analytik nutzt, ist SSPM nicht mehr optional. Es ist Teil von Cyberhygiene, IKT-Risikomanagement, Datenschutz-Rechenschaftspflicht und Auditbereitschaft.

Clarysec kann Ihnen helfen, verstreute SaaS-Feststellungen in ein strukturiertes, nachweisgetriebenes Programm zu überführen, indem Sie Folgendes nutzen:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, um die Umsetzung über Cloud-Nutzung, Zugriffsbeschränkung und Konfigurationsmanagement hinweg zu strukturieren.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, um ISO/IEC 27002:2022-Maßnahmen auf NIS2, DORA, GDPR, NIST CSF 2.0 und Auditerwartungen abzubilden.
• Clarysec-Richtlinienvorlagen wie Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten, KMU-Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten - KMU, KMU-Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen - KMU, KMU-Richtlinie zur Protokollierung und Überwachung Richtlinie zur Protokollierung und Überwachung - KMU und KMU-Richtlinie zur Lieferanten- und Drittparteiensicherheit Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU, um durchsetzbare Betriebsregeln zu schaffen.

Beginnen Sie mit Ihren fünf SaaS-Plattformen mit dem höchsten Risiko. Weisen Sie Verantwortliche zu. Erfassen Sie Daten, Zugriff, Konfiguration, Integrationen, Protokolle und Lieferantennachweise. Überführen Sie Feststellungen in Maßnahmen zur Risikobehandlung und Managemententscheidungen.

So wird SaaS Security Posture Management mehr als eine Werkzeugkategorie. Es wird zu einer belastbaren Compliance-Disziplin für 2026.

Laden Sie die Clarysec-Richtlinienvorlagen herunter, nutzen Sie Zenith Blueprint, um Ihren 30-tägigen SSPM-Nachweissprint zu planen, und bilden Sie Ihre SaaS-Kontrollen mit Zenith Controls ab, bevor Ihr nächstes Audit die Lücken für Sie findet.