Die ENISA Threat Landscape 2026 liefert keine unternehmensspezifische Risikobewertung. Sie verdeutlicht jedoch, warum Cyberresilienz nicht bei einzelnen Systemen, Schwachstellen oder Lieferanten enden sollte. Ransomware, DDoS, unbefugte Zugriffe und Social Engineering treffen die Organisation dort besonders hart, wo sie die Erbringung kritischer Geschäftsservices unterbrechen: etwa durch den Ausfall eines Identitätsdienstes, einer Cloud-Plattform, eines Managed Service Providers oder einer zentralen Softwarekomponente.
Für die Steuerung bedeutet das einen Perspektivwechsel. Die zentrale Frage lautet nicht allein, welches technische Asset bedroht ist. Sie lautet: Welcher geschäftskritische Service fällt aus, welche Abhängigkeiten verursachen oder verlängern den Ausfall und wie lässt sich der Betrieb kontrolliert wiederherstellen oder vorübergehend fortführen?
Warum eine Serviceperspektive erforderlich ist
Die ENISA Threat Landscape 2026 analysiert 8.257 Vorfälle aus dem Kalenderjahr 2025. DDoS-Angriffe machten 51,3 Prozent der erfassten Vorfälle aus, unbefugter Zugriff 39,5 Prozent. Diese Anteile sagen allerdings nicht unmittelbar aus, welche Ereignisse die höchsten betriebswirtschaftlichen Schäden verursachen. ENISA bewertet insbesondere finanziell motivierte Aktivitäten wie Ransomware kurzfristig als besonders folgenreich.
Ransomware verbindet Betriebsunterbrechung, Datendiebstahl und Erpressung. Bei den von ENISA analysierten finanziell motivierten Aktivitäten im Jahr 2025 entfielen 40 Prozent auf Ransomware-Deployments. Gleichzeitig beobachtet die Agentur Angriffe auf digitale Abhängigkeiten: Software-Lieferketten, Drittanbieter und Cloud-Umgebungen. Ein Unternehmen kann daher erheblich betroffen sein, obwohl nicht seine eigene Umgebung, sondern ein gemeinsam genutzter Anbieter kompromittiert oder nicht verfügbar ist.
Eine serviceorientierte Betrachtung verbindet diese Ereignisse mit ihrer tatsächlichen Wirkung auf Kunden, Prozesse und Verpflichtungen. Sie hilft auch, DDoS nicht nur als Netzwerkthema und einen kompromittierten Administratorzugang nicht nur als IAM-Ereignis zu behandeln, sondern jeweils als mögliche Störung eines konkreten Geschäftsservices.
Bedrohungsdaten richtig einordnen
Die ENISA-Zahlen sind wertvolle Trendindikatoren, aber keine vollständige Prävalenzmessung und kein Ersatz für die eigene Risikoanalyse. Die Datenbasis beruht überwiegend auf offenen Quellen sowie anonymisierten Informationen von EU-Mitgliedstaaten und Teilnehmenden des ENISA Cyber Partnership Programme. Meldeverzögerungen, unterschiedliche Detailtiefe und Sektorzuordnungen beeinflussen die Auswertung. Auch die Threat Landscape Methodology weist darauf hin, dass das Lagebild eine Momentaufnahme vorherrschender Trends darstellt.
Besonders wichtig ist die korrekte Lesart einzelner Kennzahlen: ENISA konnte bei unbefugten Zugriffen nur in 5,2 Prozent der Fälle einen konkreten Initialzugriffsvektor bestimmen. Innerhalb dieser Teilmenge entfielen 60,4 Prozent auf die Ausnutzung von Schwachstellen. Daraus folgt nicht, dass Schwachstellen in 60,4 Prozent aller Fälle unbefugten Zugriffs der Eintrittsweg waren. Für Prioritäten im eigenen Unternehmen sind deshalb Servicekritikalität, konkrete Exponierung, Architektur, vorhandene Kontrollen, aktuelle Schwachstellenlage und Wiederanlauffähigkeit maßgeblich.
Kritische Geschäftsservices nachvollziehbar modellieren
Ausgangspunkt sollte ein begrenztes Portfolio kritischer Geschäftsservices sein. Für jeden Service empfiehlt sich eine Abhängigkeitskarte, die nicht nur Anwendungen und Infrastruktur enthält. Erforderlich sind mindestens der unterstützte Geschäftsprozess, ein fachlicher Service-Owner, relevante Daten, Anwendungen, Identitätsdienste, Plattformen, Betriebsorganisationen, externe Dienstleister sowie Kommunikationswege. Ergänzt werden sollte, welche Abhängigkeit den Service vollständig oder teilweise ausfallen lassen kann und welche Wiederanlaufziele gelten.
Diese Karte schafft eine gemeinsame Entscheidungsgrundlage für Fachbereich, IT Operations, Informationssicherheit, BCM, Einkauf und Incident Response. Sie verhindert zudem, dass ein Lieferantenregister, ein CMDB-Auszug und ein Notfallplan nebeneinander bestehen, ohne die Auswirkungen auf die Leistungserbringung zusammenzuführen.
Für jeden Service sollten auswirkungsorientierte Szenarien geprüft werden, beispielsweise:
- Kompromittierung eines privilegierten Administratorzugangs,
- Ausfall eines Identity Providers oder einer zentralen SaaS- beziehungsweise Cloud-Plattform,
- Ransomware in der Betriebsumgebung,
- Kompromittierung eines Managed Service Providers,
- Störung einer Software-Lieferkette oder
- DDoS auf einen extern erreichbaren Zugangspunkt.
Entscheidend ist jeweils nicht die technische Ursache allein, sondern die Frage, welche Servicefunktion ausfällt, welche Alternativen bestehen und wer die Wiederherstellung priorisiert.
Abhängigkeiten und Konzentrationsrisiken steuern
Third-Party-Risk-Management sollte über Fragebögen hinausgehen. Bei kritischen Dienstleistern sind insbesondere Zugriffsrechte, Datenflüsse, Subdienstleister, gemeinsame Konzentrationsrisiken, Melde- und Eskalationswege, Wiederanlaufzusagen, Exit-Optionen und Notbetriebsverfahren zu bewerten. Dabei ist zwischen einem direkten Lieferanten, einem geteilten Technologieanbieter und einer nicht substituierbaren Abhängigkeit zu unterscheiden.
Eine Cloud- oder Identitätsplattform kann mehrere kritische Services zugleich stützen. Der Ausfall wirkt dann nicht als isoliertes Lieferantenrisiko, sondern als serviceübergreifendes Konzentrationsrisiko. Praktisch relevant sind deshalb auch technische und organisatorische Substituierbarkeit: Gibt es alternative Betriebswege, lokale Notfallverfahren, verfügbare Zugänge außerhalb der üblichen Identitätskette oder klare Regeln zur Priorisierung knapper Wiederherstellungsressourcen?
Ransomwarefest wiederherstellen und weiterarbeiten
Ransomware-Resilienz umfasst mehr als Sicherungskopien. Organisationen benötigen eine Wiederherstellungsreihenfolge nach Geschäftsservice, getestete und gegen Manipulation geschützte Backups, saubere Wiederherstellungsumgebungen sowie klar definierte Kriterien für die Wiederinbetriebnahme. Neben der Verschlüsselung müssen Datenabfluss und Erpressung als eigenständige Schadensdimensionen behandelt werden.
Ebenso wichtig sind vorab vereinbarte Entscheidungen für den Notbetrieb: Welche Leistungen werden reduziert fortgeführt? Welche manuellen oder alternativen Verfahren sind tragfähig? Wer darf Systeme abschalten, externe Unterstützung beauftragen oder bei Ressourcenkonflikten über die Reihenfolge des Wiederanlaufs entscheiden? Solche Fragen lassen sich im akuten Vorfall nur eingeschränkt klären.
Identität gegen Social Engineering absichern
Phishing war mit 77,8 Prozent die häufigste in erfassten Fällen identifizierte Social-Engineering-Technik. ENISA verweist zusätzlich auf Phishing-Kits, Phishing-as-a-Service, Smishing und ClickFix. Bei ClickFix werden Betroffene dazu verleitet, zur scheinbaren Problemlösung schädliche Befehle auszuführen. KI unterstützt nach ENISA 2025 vor allem bestehende Angreiferfähigkeiten, etwa bei zielgerichteten Phishing-Nachrichten, Recherche, Skripterstellung und Post-Exploitation; ein genereller Nachweis neuartiger Durchbruchsfähigkeiten folgt daraus nicht.
Awareness bleibt wichtig, genügt aber nicht als alleinige Kontrolle. Für besonders schutzbedürftige Zugänge sind phishing-resistente MFA, restriktive Privilegienvergabe, Conditional Access, abgesicherte Administrationswege sowie die Erkennung ungewöhnlicher Authentifizierungen und Sessions geeignete kombinierte Ansätze. Handlungsorientierte Übungen sollten Mitarbeitende auf konkrete Interaktionen vorbereiten, statt nur allgemeine Phishing-Merkmale abzufragen.
Managementsteuerung, Übungen und regulatorische Einordnung
Managementtauglich sind Kennzahlen, die Servicewirkung und technische Exponierung verbinden: der Anteil kritischer Services mit vollständiger Abhängigkeitskarte, die Zahl nicht substituierbarer externer Abhängigkeiten, die Quote getesteter Wiederherstellungen und tatsächlich erreichte Wiederanlaufzeiten. Ergänzend eignen sich der Anteil privilegierter Zugänge mit phishing-resistenter MFA, der Anteil kritischer internetexponierter Schwachstellen innerhalb des festgelegten Risikofensters sowie die Zahl ungeübter Krisenentscheidungs- und Kommunikationsszenarien.
Krisenübungen sollten servicebezogen klären, wer Wiederanläufe priorisiert, Dienstleister steuert und die Kommunikation mit Kunden, Behörden, Beschäftigten oder Medien verantwortet. Sie testen damit nicht nur Technik, sondern auch Entscheidungs- und Kommunikationsfähigkeit.
Die ENISA-Lageanalyse begründet selbst keine Rechtspflichten. Für Einrichtungen im jeweiligen Anwendungsbereich nennt Artikel 21 der NIS2-Richtlinie unter anderem Incident Handling, Business Continuity einschließlich Backup-Management und Disaster Recovery, Krisenmanagement, Lieferkettensicherheit, Schwachstellenmanagement, Schulungen, Zugriffskontrolle und Asset Management. Artikel 20 weist Leitungsorganen Genehmigungs- und Überwachungsaufgaben zu. Die unmittelbare Rechtslage richtet sich jedoch nach der anwendbaren nationalen Umsetzung und sektoralen Vorgaben. Für Finanzunternehmen im DORA-Anwendungsbereich gelten die spezifischen Anforderungen der DORA-Verordnung, einschließlich regelmäßig getesteter ICT-Business-Continuity-Pläne für kritische oder wichtige Funktionen und relevante ICT-Drittdienstleister.
Service-Mapping, Kennzahlen und Übungen sind damit keine pauschalen Einzelpflichten. Sie sind jedoch praxisnahe Mittel, um Cyberrisiken, externe Abhängigkeiten, Wiederherstellbarkeit und Managementverantwortung in einer nachvollziehbaren Steuerung zusammenzuführen.