Zero Trust Architecture 2026: auditfähige Nachweise

Das ungeplante Zero-Trust-Audit am Montagmorgen

Um 08:12 Uhr an einem Montag erhält der CISO eines europäischen SaaS-Fintechs innerhalb von fünf Minuten drei Nachrichten.

Die erste stammt von einem Bankkunden: „Bitte stellen Sie uns Ihr Nachweispaket zur Zero Trust Architecture für unsere jährliche IKT-Drittparteienprüfung bereit.“

Die zweite kommt aus der Rechtsabteilung: „Wir könnten in einem Mitgliedstaat als wichtige Einrichtung nach NIS2 eingestuft werden, und einige Kunden fragen, ob DORA auf uns als IKT-Dienstleister durchschlägt.“

Die dritte kommt vom Leiter der Entwicklung: „Wir haben MFA, SSO, EDR, Kubernetes-Netzwerkrichtlinien und SIEM-Warnmeldungen. Ist das Zero Trust?“

Genau hier geraten viele Organisationen ins Stocken. Sie verfügen über Sicherheitswerkzeuge, aber nicht über ein Zero-Trust-Betriebsmodell für Compliance. Sie können auf MFA-Screenshots verweisen, aber nicht erklären, wie Identität, Gerätezustand, Prinzip der geringsten Rechte, Segmentierung, Überwachung, Vorfallmeldung, Datenschutzmaßnahmen und Lieferantenabhängigkeiten zusammenwirken. Sie können Kontrollen zeigen, aber keine durchgängige Nachvollziehbarkeit.

Im Jahr 2026 muss Zero Trust Architecture auf Basis von NIST SP 800-207 mehr sein als „never trust, always verify“. Für CISOs, Compliance-Manager, Auditoren und Geschäftsverantwortliche lautet die praktische Frage präziser:

Wie überführen wir Zero Trust in Nachweise, die ISO/IEC 27001:2022, Erwartungen an Cyberhygiene nach NIS2, IKT-Risikomanagement nach DORA, GDPR Article 32 zur Sicherheit der Verarbeitung, Due-Diligence-Anforderungen von Kunden und die Aufsicht durch das Leitungsorgan erfüllen?

Die Antwort ist kein weiteres Werkzeug. Sie ist ein risikobasiertes Nachweismodell, das Richtlinien, Kontrollen, technische Umsetzung, Überwachung und Rechenschaftspflicht des Managements miteinander verbindet.

Zero Trust 2026: von der Sicherheitsstrategie zum Compliance-Nachweis

NIST SP 800-207 definiert Zero Trust als Satz von Grundsätzen für die Konzeption und den Betrieb sicherer Systeme, bei denen Vertrauen niemals implizit ist. Zugriff wird auf Grundlage von Identität, Kontext, Richtlinie, Asset-Zustand und kontinuierlicher Bewertung gewährt.

Die sieben NIST-Zero-Trust-Grundsätze sind besonders nützlich, weil sie ein vages Sicherheitsmotto in etwas überführen, das zugeordnet, getestet und auditiert werden kann:

1. Alle Datenquellen und Rechenressourcen gelten als Ressourcen.
2. Jede Kommunikation wird unabhängig vom Netzwerkstandort abgesichert.
3. Zugriff auf einzelne Unternehmensressourcen wird sitzungsbezogen gewährt.
4. Zugriff auf Ressourcen wird durch dynamische Richtlinien bestimmt, einschließlich Identitäts-, Geräte-, Anwendungs- und Verhaltensattributen.
5. Das Unternehmen überwacht und misst Integrität und Informationssicherheits-Risikoprofil aller eigenen und verbundenen Assets.
6. Authentifizierung und Autorisierung für alle Ressourcen erfolgen dynamisch und werden strikt durchgesetzt, bevor Zugriff erlaubt wird.
7. Das Unternehmen sammelt Informationen über Assets, Infrastruktur und Kommunikation und nutzt sie zur Verbesserung des Informationssicherheits-Risikoprofils.

Für einen modernen SaaS-Anbieter, eine digitale Bank, einen Managed Service Provider oder eine Cloud-native Plattform werden diese Grundsätze zu praktischen Kontrollbereichen:

• Identität wird geprüft und gesteuert.
• Geräte werden bewertet, bevor Zugriff gewährt wird.
• Privilegierter Zugriff wird minimiert und überprüft.
• Netzwerkpfade werden segmentiert und kontrolliert.
• Anwendungen, APIs und Datenspeicher setzen Autorisierung durch.
• Protokolle und Telemetrie unterstützen kontinuierliche Überwachung.
• Vorfälle lösen Eindämmung, Meldung und Wiederherstellung aus.
• Nachweise belegen, dass Kontrollen wirksam betrieben werden und nicht nur konzipiert sind.

An diesem letzten Punkt beginnt Compliance.

ISO/IEC 27001:2022 verlangt von Organisationen, Kontext, interessierte Parteien, anwendbare gesetzliche und vertragliche Anforderungen, Geltungsbereich, Schnittstellen und Abhängigkeiten zu definieren. Darüber hinaus sind Risikobeurteilung, Risikobehandlung, Erklärung zur Anwendbarkeit, Rechenschaftspflicht der Leitung, internes Audit, Managementbewertung und kontinuierliche Verbesserung erforderlich.

Zero Trust fügt sich natürlich in diese Struktur ein, wenn es als Kontrollsystem behandelt wird. Es darf nicht außerhalb des ISMS als reine Engineering-Initiative geführt werden. Es muss Teil von Risikobeurteilung, Kontrollauswahl, Richtlinien-Governance, Lieferantenmanagement, Datenschutz, Incident Response und Berichterstattung an das Leitungsorgan sein.

Der regulatorische Druck hinter Zero-Trust-Nachweisen

Der Druck, Zero-Trust-Nachweise vorzulegen, entsteht in der Regel aus überlappenden Verpflichtungen und nicht aus einem einzelnen Standard.

NIS2 kann für öffentliche oder private Einrichtungen in Sektoren nach Anhang I oder Anhang II gelten, sofern sie Größen- und Tätigkeitsschwellenwerte erfüllen; sie kann auch für bestimmte kleinere, aber kritische Einrichtungen gelten. Anhang I umfasst Anbieter von Cloud-Computing-Diensten, Rechenzentrumsdienste, Content-Delivery-Network-Anbieter, Vertrauensdiensteanbieter, Managed Service Provider, Managed Security Service Provider sowie Banken und Finanzmarktinfrastrukturen. Anhang II umfasst digitale Anbieter wie Online-Marktplätze, Suchmaschinen und Plattformen sozialer Netzwerke.

NIS2 Article 20 macht Cybersicherheit zur Verantwortung des Leitungsorgans. Das Leitungsorgan muss Maßnahmen zum Cybersicherheitsrisikomanagement genehmigen, deren Umsetzung überwachen und Schulungen zur Cybersicherheit erhalten. Article 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen für Risikoanalyse, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Entwicklung, Behandlung von Schwachstellen, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management und, soweit angemessen, MFA oder kontinuierliche Authentifizierung. Article 23 führt ein gestuftes Meldeverfahren für erhebliche Vorfälle ein, einschließlich Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und Abschlussbericht.

DORA gilt ab dem 17. Januar 2025 und schafft ein einheitliches Regime für digitale operationale Resilienz von Finanzunternehmen. Es umfasst IKT-Risikomanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der operationalen Resilienz, Austausch von Bedrohungsinformationen und IKT-Drittparteienrisiko. DORA Article 5 und Article 6 verlangen Governance und ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken. Article 9 behandelt Schutz und Prävention, einschließlich Richtlinien, Verfahren, Protokollen und Werkzeugen zum Schutz von IKT-Systemen. Article 17 verlangt einen Managementprozess für IKT-bezogene Vorfälle.

GDPR gilt für Verarbeitung im Kontext einer Niederlassung in der EU sowie für nicht in der EU ansässige Verantwortliche oder Auftragsverarbeiter, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten. GDPR Article 5 verlangt Rechenschaftspflicht. Article 32 verlangt geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau sicherzustellen. Article 33 verlangt die Meldung einer Verletzung des Schutzes personenbezogener Daten an die Aufsichtsbehörde unverzüglich und, soweit möglich, innerhalb von 72 Stunden nach Bekanntwerden der Verletzung.

Ein Zero-Trust-Nachweismodell hilft, weil dieselbe Kontrolle mehrere Rahmenwerke unterstützen kann. MFA kann die Zugriffskontrolle nach ISO/IEC 27001:2022, Authentifizierungsmaßnahmen nach NIS2, Schutzanforderungen nach DORA und die Sicherheit der Verarbeitung nach GDPR unterstützen. Das gilt jedoch nur, wenn die Organisation Geltungsbereich, Verantwortlichkeit, Umsetzung, Überwachung und Überprüfung nachweisen kann.

Zuordnung der NIST-Zero-Trust-Grundsätze zu ISO/IEC 27001:2022-Kontrollen

Die Maßnahmen aus ISO/IEC 27001:2022 Anhang A, unterstützt durch die Umsetzungshinweise aus ISO/IEC 27002:2022, liefern die Auditsprache, die die meisten Organisationen benötigen. Die folgende Tabelle überführt NIST-Zero-Trust-Grundsätze in ISO-Kontrollbereiche, die Auditoren wiedererkennen.

Diese Zuordnung ist nicht nur eine technische Designübung. Sie wird zur Struktur für Risikoregister, Erklärung zur Anwendbarkeit, Nachweispaket und Agenda der Managementbewertung.

Ein Risikoszenario wie „kompromittiertes Entwicklerkonto ändert Produktivcode und greift auf Kundendaten zu“ sollte beispielsweise Identitätsmanagement, MFA, privilegierten Zugriff, Netzwerksegmentierung, Protokollierung, Überwachung, sichere Entwicklung, Änderungsmanagement und Incident Response abdecken. Dieses einzelne Szenario kann ISO/IEC 27001:2022, NIS2 Article 21, IKT-Risikomanagement nach DORA und GDPR Article 32 unterstützen.

Der Clarysec-Zero-Trust-Kontrollstack

Clarysec strukturiert Zero Trust entlang von fünf Nachweisbereichen: Identität, Gerät, Netzwerk, Anwendung und Daten; Überwachung und Governance wirken über alle fünf Bereiche hinweg.

Die Grundlage bilden Zugriffskontrolle und Identitätsmanagement. In Zenith Controls: The Cross-Compliance Guide wird ISO/IEC 27002:2022 Control 5.15, Access control, als präventive Kontrolle zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit eingestuft, ausgerichtet am Cybersicherheitskonzept Protect und an der Fähigkeit Identity and Access Management. Control 5.16, Identity management, ist ebenfalls präventiv und denselben CIA-Eigenschaften sowie der IAM-Fähigkeit zugeordnet. Control 8.16, Monitoring activities, wird als aufdeckend und korrektiv eingestuft und unterstützt Detect und Respond durch Management von Informationssicherheitsereignissen.

Diese Kombination ist entscheidend. Zero Trust ist nicht nur Zugriffskontrolle. Es ist Zugriffskontrolle plus Identitätslebenszyklus plus Gerätezustand plus Netzwerksegmentierung plus Überwachung plus Reaktion.

Clarysec-Richtlinienklauseln überführen dieses Modell in durchsetzbare Governance.

Aus der unternehmensweiten Zugriffskontrollrichtlinie, Abschnitt Ziele, Klausel 3.4:

Unterstützung von Zero-Trust-Grundsätzen durch standardmäßige Verweigerung des Zugriffs, sofern der Zugriff nicht ausdrücklich genehmigt und begründet wurde.

Aus der unternehmensweiten Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen, Abschnitt Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.1:

Allen Benutzern muss das Mindestmaß an Zugriff zugewiesen werden, das zur Ausübung ihrer Aufgaben erforderlich ist.

Aus der unternehmensweiten Netzwerksicherheitsrichtlinie, Abschnitt Governance-Anforderungen, Klausel 5.2:

Der gesamte Datenverkehr zwischen Zonen muss durch Firewalls oder softwaredefinierte Perimeterlösungen kontrolliert werden; Default-Deny-Konfigurationen sind ausdrücklich umzusetzen.

Aus der unternehmensweiten Richtlinie zur Protokollierung und Überwachung, Abschnitt Ziele, Klausel 3.4:

Zentrale Protokollierungs- und Warnsysteme (z. B. SIEM) sind einzurichten, um verdächtige Aktivitäten nahezu in Echtzeit zu aggregieren, zu korrelieren und zu eskalieren.

Aus der unternehmensweiten Informationssicherheitsleitlinie, Abschnitt Anforderungen an die Umsetzung der Richtlinie, Klausel 6.6.1:

Alle umgesetzten Kontrollen müssen auditierbar sein, durch dokumentierte Verfahren unterstützt werden und durch aufbewahrte Betriebsnachweise belegt sein.

Für KMU kann dieselbe Governance-Absicht mit schlankerer Richtliniendokumentation umgesetzt werden. Die Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen – KMU, Abschnitt Ziele, Klausel 3.2, legt fest:

Das Prinzip der geringsten Rechte ist durchzusetzen, sodass Benutzern nur das Mindestmaß an Zugriff gewährt wird, das zur Ausübung ihrer Aufgaben erforderlich ist.

Die Zugriffskontrollrichtlinie – KMU, Abschnitt Governance-Anforderungen, Klausel 5.4.3, ergänzt:

Privilegierte Konten müssen, sofern unterstützt, Multi-Faktor-Authentifizierung (MFA) verwenden.

Die Netzwerksicherheitsrichtlinie – KMU, Abschnitt Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.3, legt fest:

Datenverkehr zwischen Segmenten muss gefiltert werden, und segmentübergreifender Zugriff muss dem Prinzip der geringsten Rechte folgen.

Die Richtlinie zur Protokollierung und Überwachung – KMU, Abschnitt Zweck, Klausel 1.3, erläutert:

Protokollierung und Überwachung unterstützen Bedrohungserkennung, Einhaltung regulatorischer Anforderungen, Vorfallmeldung und -management sowie forensische Analyse.

Für datenschutzgetriebenes Zero Trust legt die Richtlinie zu Datenschutz und Privatsphäre – KMU, Abschnitt Governance-Anforderungen, Klausel 5.3.2, fest:

Benutzerzugriff auf personenbezogene Daten muss auf Rollen mit dokumentiertem geschäftlichem Bedarf beschränkt werden.

Diese Klauseln schaffen Audit-Anker. Ein Auditor kann prüfen, ob Zugriff standardmäßig verweigert wird, Berechtigungen minimiert sind, Datenverkehr zwischen Zonen kontrolliert wird, Protokolle zentralisiert sind und Nachweise aufbewahrt werden.

Rahmenwerksübergreifende Nachweiskarte für Zero Trust

Ein belastbares Zero-Trust-Nachweismodell sollte fragmentierte Screenshots vermeiden. Nachweise müssen Governance, Design, Umsetzung, Überwachung und Überprüfung zeigen.

Diese Tabelle ist der Kern eines Zero-Trust-Programms, das dem Leitungsorgan vorgelegt werden kann. Sie zeigt, wie ein Kontrollumfeld mehrere Assurance-Anforderungen unterstützen kann, ohne für jedes Rahmenwerk separate Nachweispakete zu erzeugen.

Mit Zenith Blueprint Nachvollziehbarkeit schaffen

Zenith Blueprint: An Auditor’s 30-Step Roadmap von Clarysec ist darauf ausgelegt, zu verhindern, dass Zero Trust zu einer undokumentierten Engineering-Philosophie wird. In der Phase Risikomanagement, Schritt 13, Planung der Risikobehandlung und Erklärung zur Anwendbarkeit, heißt es:

Die SoA ist faktisch ein Brückendokument: Sie verknüpft Ihre Risikobeurteilung und -behandlung mit den
tatsächlich vorhandenen Kontrollen. Durch ihre Fertigstellung prüfen Sie zugleich, ob Kontrollen übersehen wurden.

Derselbe Schritt empfiehlt, Kontrollen Risiken zuzuordnen, Referenzen auf Anhang-A-Kontrollen zu Risikobehandlungseinträgen hinzuzufügen und Vorschriften wie GDPR, NIS2 oder DORA querzuverweisen, wenn Kontrollen zur Erfüllung dieser Verpflichtungen umgesetzt werden.

Für Zero Trust ist dies die fehlende Brücke. Wenn ein Auditor fragt, warum kontextabhängige Zugriffssteuerung umgesetzt wurde, sollte die Antwort nicht lauten: „weil Zero Trust das fordert“. Eine bessere Antwort lautet:

• Das Risikoszenario ist unbefugter Zugriff auf Kundendaten über kompromittierte Zugangsdaten.
• Risikoverantwortlicher ist der CTO oder der Leiter der Entwicklung.
• Die Behandlung umfasst SSO, MFA, kontextabhängige Zugriffssteuerung, Prüfung des Endgerätezustands, Prinzip der geringsten Rechte, Segmentierung und Überwachung.
• Die SoA ordnet die Behandlung Zugriffskontrolle, Identitätsmanagement, Protokollierung, Überwachung, Kryptografie, Schwachstellenmanagement und Cloud-Service-Management zu.
• Dieselbe Behandlung unterstützt NIS2 Article 21, IKT-Risikomanagement nach DORA und GDPR Article 32.
• Nachweise umfassen Richtlinienklauseln, Berechtigungsüberprüfungen, SIEM-Warnmeldungen, EDR-Zustandsberichte, Firewall-Regeln, IAM-Exporte, Incident-Response-Übungen und Protokolle der Managementbewertung.

So wird Zero Trust Architecture auditfähig.

Vertrauen in Endpunkte, APIs und Netzwerksegmentierung in der Praxis

Zero Trust scheitert häufig, weil Organisationen sich auf Identität konzentrieren und Geräte-, Workload-, Daten- und Netzwerkkontext vernachlässigen.

Zenith Blueprint Schritt 19, Technische Maßnahmen I, beschreibt die Anforderung an den Endgerätezustand klar:

Zugriff auf Informationen über Endpunkte muss kontextbezogen sein. Erfüllt das Gerät beispielsweise
Mindestsicherheitsstandards, bevor es auf Unternehmensressourcen zugreift? Wurde kürzlich
ein Malware-Scan erfolgreich durchgeführt? Erfolgt die Verbindung von einem ungewöhnlichen Standort oder Netzwerk? In Verbindung mit Zero-
Trust-Grundsätzen kann der Endgerätezustand in die kontextabhängige Zugriffssteuerung einfließen und den Zugriff verweigern, bis
das Gerät seine Sicherheit nachweist.

Damit wird das Gerät Teil der Autorisierungsentscheidung. Ein gültiges Passwort von einem nicht verwalteten Laptop darf nicht genauso behandelt werden wie eine gültige Anmeldung von einem konformen, verschlüsselten und überwachten Unternehmensendgerät.

Derselbe Schritt betont, dass Zugriffsbeschränkungen auch für Anwendungen, Dienste und APIs gelten und nicht nur für Personen:

Zugriffsbeschränkungen sollten auch auf Anwendungen, Dienste und APIs angewendet werden, nicht nur auf Personen.
Ein Microservice benötigt beispielsweise möglicherweise nur Lesezugriff auf eine Datenbanktabelle, nicht vollständige CRUD-
Rechte. Ein Backup-Werkzeug benötigt möglicherweise nur Zugriff auf bestimmte Storage Buckets, nicht auf alle Mandantenressourcen.

Diese Leitlinien sind für Cloud-native Umgebungen kritisch. API-Scopes, Servicekonten, Workload-Identitäten, Kubernetes-Rollen und Cloud-IAM-Richtlinien müssen alle dem Prinzip der geringsten Rechte folgen. Menschlicher Zugriff ist nur ein Teil der Kontrollfläche.

Schritt 20 von Zenith Blueprint behandelt Netzwerksegmentierung:

Segmentierung ist eines der ältesten und wirksamsten Prinzipien der Cybersicherheit: Ausbreitung begrenzen,
Risiko reduzieren und Schaden eindämmen. Control 8.22 konzentriert sich auf Netzwerk-
segmentierung, also die Trennung von Systemen, Diensten und Benutzern in verschiedene logische oder
physische Zonen, um unbefugten Zugriff zu verhindern und seitliche Bewegung im Fall einer
Kompromittierung einzuschränken.

Dies ist entscheidend für Resilienz nach DORA und NIS2. Ein Zero-Trust-Netzwerk muss davon ausgehen, dass ein Konto, eine Workload oder ein Endpunkt kompromittiert werden kann. Segmentierung verhindert, dass aus einem lokalen Ereignis ein systemischer Vorfall wird.

Ein 10-Tage-Nachweispaket für Zero Trust

Stellen Sie sich ein SaaS-Fintech vor, das Banken Betrugsanalysen bereitstellt. Es verarbeitet personenbezogene Daten, nutzt Cloud-Infrastruktur, stützt sich auf verwaltetes Kubernetes, integriert Kunden-APIs und verwendet einen Drittanbieter als Identitätsanbieter. Ein Kunde fordert Zero-Trust-Nachweise an, und das Unternehmen hat zehn Arbeitstage Zeit.

Ein praxisnaher Clarysec-Nachweis-Sprint sähe wie folgt aus.

Das Ziel ist nicht, vorzugeben, die Organisation habe in zehn Tagen perfektes Zero Trust erreicht. Ziel ist es, eine belastbare Nachweiskette für die wichtigsten Risiken zu schaffen und zu belegen, dass das Programm gesteuert, messbar und verbesserungsfähig ist.

Wie unterschiedliche Auditoren Zero Trust prüfen

Ein häufiger Fehler besteht darin, eine einzige technische Darstellung vorzubereiten und anzunehmen, alle Auditoren würden dieselben Fragen stellen. Das werden sie nicht.

Ein ISO/IEC 27001:2022-Auditor wird auf das Managementsystem achten. Er wird fragen, ob Zero-Trust-Risiken in der Risikobeurteilung enthalten sind, ob Behandlungen genehmigt wurden, ob die SoA vollständig ist, ob Richtlinien gelenkte Dokumente sind, ob Berechtigungsüberprüfungen stattfinden, ob interne Audits die Kontrollen testen und ob Managementbewertungen die Leistung verfolgen.

Ein DORA-Prüfer wird fragen, ob Zero-Trust-Kontrollen Teil des dokumentierten Rahmenwerks für das Management von IKT-Risiken sind. Erwartet werden Inventare von Assets und Abhängigkeiten, Zuordnung kritischer oder wichtiger Funktionen, Vorfallklassifizierung, Eskalation an das Leitungsorgan, Tests, vertragliche Anforderungen an Drittparteien, Auditrechte, Exit-Strategien und Nachverfolgung von Abhilfemaßnahmen.

Ein NIS2-Bewerter wird den Fokus auf die Rechenschaftspflicht des Leitungsorgans, Maßnahmen zum Cybersicherheitsrisikomanagement nach Article 21 und die Bereitschaft zur Vorfallmeldung nach Article 23 legen. Außerdem wird er Nachweise erwarten, dass Sicherheit der Lieferkette, Aufrechterhaltung des Geschäftsbetriebs, Behandlung von Schwachstellen, Zugriffskontrolle und Cyberhygiene gesteuert werden.

Ein GDPR-Prüfer oder Datenschutzauditor wird fragen, ob Zugriff auf personenbezogene Daten erforderlich, dokumentiert, beschränkt, überwacht und auf die Verarbeitungszwecke ausgerichtet ist. Er wird Rollen von Verantwortlichem und Auftragsverarbeiter, Erkennung von Verletzungen des Schutzes personenbezogener Daten, rollenbasierten Zugriff, Verschlüsselung, Pseudonymisierung, soweit angemessen, Aufbewahrung und Rechenschaftspflicht prüfen.

Dieselbe Kontrolle kann mehrere Fragen beantworten, aber nur, wenn die Nachweise strukturiert sind.

Lieferanten-, Cloud- und IKT-Drittparteienrisiko

Zero Trust endet nicht an der Firewall; in Cloud-Umgebungen gibt es unter Umständen gar keine klassische Firewall-Grenze mehr. Identitätsanbieter, Cloud-Plattformen, CI/CD-Werkzeuge, Anbieter für Managed Detection, Zahlungsabwickler, API-Gateways und ausgelagerte Entwicklungsteams werden alle Teil des Vertrauensgefüges.

NIS2 Article 21 umfasst ausdrücklich Sicherheit der Lieferkette für direkte Lieferanten und Dienstleister, einschließlich Schwachstellen bei Lieferanten, Resilienz von Produkten und Diensten, Cybersicherheitspraktiken von Lieferanten und Verfahren für sichere Entwicklung.

DORA verlangt, dass IKT-Drittparteienrisiko als Teil des Rahmenwerks für das Management von IKT-Risiken gesteuert wird – mit einem Register der IKT-Serviceverträge, gebotener Sorgfalt vor Vertragsabschluss, Kritikalitätsbewertung, Konzentrationsrisiko, vertraglichen Sicherheitsanforderungen, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Auditrechten, Kündigungsrechten, Exit-Strategien und Übergangsplänen.

Für Zero Trust ist die praktische Regel einfach: Vertrauen Sie einer Lieferantenverbindung nicht nur deshalb, weil sie vertraglich geregelt ist. Fordern Sie technische Kontrollen und Nachweise.

Eine Kunden-API-Integration sollte begrenzte Token, Ratenbegrenzung, Überwachung, Rotation, Verantwortlichkeit und Widerruf vorsehen. Ein Managed Service Provider sollte MFA, personenbezogene Benutzerkonten, Prinzip der geringsten Rechte, Sitzungsprotokollierung und zeitlich begrenzten Zugriff verwenden. Eine Beziehung zu einem Cloud-Anbieter sollte Zuordnung der geteilten Verantwortung, Verschlüsselungskonfiguration, Protokollaufbewahrung, Backup-Tests und Exit-Planung umfassen.

Deshalb gehören Lieferanten- und Cloud-Nachweise in das Zero-Trust-Modell und nicht in einen separaten Beschaffungsordner.

Kennzahlen, die den Betrieb von Zero Trust belegen

Leitungsorgane und Auditoren wollen nicht nur Architekturdiagramme sehen. Sie erwarten Betriebsnachweise und Verbesserungstrends.

Nützliche Zero-Trust-Kennzahlen sind:

• Anteil privilegierter Konten, die durch MFA geschützt sind.
• Anteil der Benutzer, die durch kontextabhängige Zugriffssteuerung abgedeckt sind.
• Anzahl dauerhaft bestehender privilegierter Konten im Vergleich zu Just-in-time-Konten.
• Anzahl überfälliger Berechtigungsüberprüfungen.
• Anteil der Endpunkte, die Anforderungen an den Gerätezustand erfüllen.
• EDR-Abdeckung über kritische Assets hinweg.
• Anzahl verweigerter Zugriffsversuche aufgrund von Geräte- oder Standort-Risiko.
• Mean Time to Detect (MTTD) verdächtiger privilegierter Aktivität.
• Mittlere Zeit bis zum Entzug von Zugriff nach Austritt.
• Anteil der Firewall-Regeln zwischen Zonen, die im letzten Quartal überprüft wurden.
• Anzahl kritischer Lieferanten mit aktuellen Sicherheitsnachweisen.
• Anzahl von Zero-Trust-Ausnahmen, deren Frist zur Mängelbehebung überschritten ist.
• Anteil kritischer Anwendungen, die Protokolle an das SIEM senden.
• Ergebnisse von Vorfallsimulationen zu kompromittierten Zugangsdaten.

Diese Kennzahlen unterstützen kontinuierliche Verbesserung nach ISO/IEC 27001:2022, Wirksamkeitsbewertung nach NIS2, Test- und Mängelbehebungserwartungen nach DORA sowie Rechenschaftspflicht nach GDPR.

Häufige Fehler bei Zero-Trust-Nachweisen

Die häufigsten Fehler entstehen nicht durch fehlende Werkzeuge. Sie entstehen durch schwache Nachvollziehbarkeit.

Erstens setzen Organisationen MFA um, können aber nicht nachweisen, dass privilegierte Konten vollständig abgedeckt sind. Servicekonten, Break-Glass-Konten und lokale Administratorkonten bleiben häufig außerhalb der Kontrolle.

Zweitens werden Berechtigungsüberprüfungen manuell durchgeführt, aber nicht mit Geschäftsrollen, Datensensitivität oder Risikoverantwortlichen verknüpft. Der Nachweis zeigt, dass jemand auf „reviewed“ geklickt hat, nicht dass unnötige Zugriffe entfernt wurden.

Drittens existiert Netzwerksegmentierung in Diagrammen, aber nicht in getesteten Regeln. Auditoren werden fragen, ob segmentübergreifender Zugriff standardmäßig verweigert wird und ob Ausnahmen genehmigt sind.

Viertens werden Protokolle gesammelt, sind aber nicht handlungsfähig. Ein SIEM ohne definierte Anwendungsfälle, Triage von Warnmeldungen und Reaktionsverfahren belegt keine kontinuierliche Überwachung.

Fünftens ist Lieferantenzugriff nicht gesteuert. Lieferanten verwenden möglicherweise gemeinsame Konten, dauerhaften VPN-Zugriff oder weitreichende Cloud-Rollen ohne Sitzungsüberwachung.

Sechstens sind Datenschutznachweise von Sicherheitsnachweisen getrennt. GDPR verlangt nachweisbaren Schutz personenbezogener Daten; daher müssen Identitäts- und Zugriffskontrollen mit Datenkategorien und Verarbeitungszwecken verbunden sein.

Schließlich sind Ausnahmen undokumentiert. Zero Trust kann Ausnahmen tolerieren, wenn sie risikobewertet, genehmigt, zeitlich befristet und überwacht sind. Unsichtbare Ausnahmen kann es nicht tolerieren.

Erstellen Sie Ihr Zero-Trust-Nachweispaket mit Clarysec

Zero Trust Architecture im Jahr 2026 ist kein Slogan. Sie ist ein Compliance-Betriebsmodell, das Identität, Geräte, Anwendungen, Netzwerksegmentierung, Prinzip der geringsten Rechte, kontinuierliche Überwachung, Lieferantenkontrolle und Datenschutzmaßnahmen zu einem auditierbaren System verbindet.

Wenn Sie sich auf eine ISO/IEC 27001:2022-Zertifizierung vorbereiten, auf NIS2-Kundenanfragen antworten, sich am IKT-Risikomanagement nach DORA ausrichten oder die Sicherheit der Verarbeitung nach GDPR Article 32 nachweisen, beginnen Sie mit Nachvollziehbarkeit.

Nutzen Sie Zenith Blueprint: An Auditor’s 30-Step Roadmap, um Zero-Trust-Risiken in Ihr Risikoregister, Ihren Behandlungsplan und Ihre SoA zu überführen. Nutzen Sie Zenith Controls: The Cross-Compliance Guide, um Zugriffskontrolle, Identitätsmanagement und Überwachung mit rahmenwerksübergreifenden Erwartungen abzugleichen. Nutzen Sie die Clarysec-Richtlinienbibliothek, einschließlich unternehmensweiter Zugriffskontrollrichtlinie, unternehmensweiter Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen, unternehmensweiter Netzwerksicherheitsrichtlinie, unternehmensweiter Richtlinie zur Protokollierung und Überwachung, unternehmensweiter Informationssicherheitsleitlinie und Richtlinie zu Datenschutz und Privatsphäre – KMU, um Architektur in durchsetzbare Governance zu überführen.

Ihr nächster praktischer Schritt besteht darin, ein Hochrisikoszenario auszuwählen, etwa kompromittierten privilegierten Zugriff auf Kundendaten, und darum eine vollständige Zero-Trust-Nachweiskette aufzubauen. Wenn Sie dieses Szenario durchgängig belegen können, verfügen Sie über die Grundlage für ein skalierbares, auditierbares und regulatorisch belastbares Zero-Trust-Programm.

Laden Sie die Clarysec-Richtlinienpakete herunter oder vereinbaren Sie ein Strategiegespräch, um zu sehen, wie Zenith Blueprint und Zenith Controls Zero Trust von einem Auditrisko in einen Compliance-Vorteil verwandeln können.