Zuletzt aktualisiert: 6. August 2026

IT-Risikoanalyse durchführen: Ablauf, Datenquellen und Ergebnis

Das Wichtigste in Kürze

• Eine IT-Risikoanalyse beginnt mit einer klaren Entscheidungsfrage, einem abgegrenzten Scope und benannten Verantwortlichen.
• Interne Inventar-, Prozess- und Kontrolldaten beantworten andere Fragen als eine externe Outside-in-Analyse. Beide Perspektiven ergänzen sich.
• Ein technischer Befund wird erst durch Asset-Zuordnung, Bedrohung, Auswirkung und vorhandene Kontrollen zu einem bewertbaren Risiko.
• Die Priorisierung sollte Evidenz, Unsicherheit, Geschäftskritikalität und Behebbarkeit sichtbar machen.
• Das Ergebnis ist kein statischer Bericht, sondern eine dokumentierte Entscheidung mit Maßnahme, Eigentümer, Termin und Nachprüfung.

Was eine IT-Risikoanalyse leisten muss

Eine IT-Risikoanalyse unterstützt eine konkrete Entscheidung über digitale Risiken. Sie verbindet schützenswerte Geschäftsleistungen, mögliche Bedrohungen, technische oder organisatorische Schwächen, bestehende Kontrollen und denkbare Auswirkungen. Das Ergebnis soll zeigen, welche Risiken zuerst behandelt, akzeptiert, vermieden oder übertragen werden und wer die Entscheidung verantwortet.

Der Begriff wird in der Praxis unterschiedlich weit verwendet. Eine Analyse kann ein einzelnes System, einen Geschäftsprozess, die externe Angriffsfläche oder ein Lieferantenportfolio betrachten. NIST SP 800-30 Rev. 1 beschreibt einen flexiblen Prozess aus Vorbereitung, Durchführung und Pflege der Bewertung. Der BSI-Standard 200-3 ordnet die Risikoanalyse in die IT-Grundschutz-Vorgehensweise ein und verbindet Gefährdungen, Eintrittshäufigkeit, Schadenshöhe und Risikobehandlungsoptionen.

Keines dieser Modelle verlangt eine bestimmte Software. Methodik und Datenquellen müssen zur Frage passen. Wer die öffentliche Exposition einer Organisation beurteilen will, benötigt andere Evidenz als ein Team, das Berechtigungen in einer Fachanwendung untersucht. Eine externe Analyse kann schnell eine Outside-in-Sicht liefern. Sie sieht jedoch keine internen Rollen, Prozesse oder nicht erreichbaren Systeme.

Dieser Beitrag beschreibt den praktischen Ablauf und ergänzt damit die Leistungsübersicht zur IT-Risikoanalyse von LocateRisk. Der Schwerpunkt liegt auf Entscheidungen, Datenqualität und Grenzen der jeweiligen Perspektive.

Schritt 1: Auftrag, Scope und Bewertungskriterien festlegen

Formulieren Sie zuerst die Entscheidung, die am Ende getroffen werden soll. Beispiele sind die Freigabe eines neuen Internetdienstes, die Priorisierung externer Expositionen oder die Bewertung einer kritischen Lieferantenleistung. Eine allgemeine Frage wie „Wie sicher sind wir?“ ist zu offen. Besser ist: „Welche öffentlich erreichbaren Systeme unterstützen das Kundenportal, welche relevanten Schwächen sind erkennbar und welche Maßnahmen benötigen innerhalb des nächsten Planungszyklus einen Owner?“

Der Scope benennt Geschäftsleistung, Organisationseinheiten, technische Assets, Standorte, Lieferanten und Zeitraum. Für eine externe Analyse können bekannte Domains, IP-Bereiche und organisatorische Zuordnungen als Ausgangspunkte dienen. Das interne Team ergänzt Anwendungen, Datenflüsse, Identitäten und Verantwortliche. Kandidaten aus einer automatischen Discovery müssen geprüft werden, bevor sie als eigene Assets gelten.

Definieren Sie außerdem Bewertungsskalen und Risikotoleranz. Welche Auswirkungen unterscheiden niedrig, mittel und hoch? Welche Arten von Evidenz gelten als bestätigt, wahrscheinlich oder ungeklärt? Wann braucht eine Ausnahme die Freigabe des Managements? Vorab definierte Regeln vermeiden, dass dasselbe Signal je nach Bearbeiter unterschiedlich behandelt wird.

Zum Auftrag gehören rechtliche und betriebliche Grenzen. Aktive Tests benötigen eine klare Autorisierung, Prüfzeit und Abbruchkriterien. Eine nicht invasive Outside-in-Analyse hat eine andere Eingriffstiefe, verlangt aber ebenfalls eine saubere Zuordnung und einen verantwortlichen Umgang mit Befunden. Der Scope sollte ausdrücklich festhalten, was nicht untersucht wird.

Schritt 2: Interne und externe Datenquellen verbinden

Interne Daten schaffen Geschäftskontext. Dazu gehören Asset-Inventar, Servicekatalog, Architektur, Schutzbedarfsfeststellung, Identitäts- und Berechtigungsdaten, Schwachstellenscanner, Cloud-Konfigurationen, Vorfälle und offene Maßnahmen. Ihre Qualität hängt von Pflege, Aktualität und Abdeckung ab. Ein Eintrag in einer CMDB beweist nicht, dass das Asset noch aktiv ist; ein fehlender Eintrag beweist nicht, dass es nicht existiert.

Eine externe Analyse betrachtet erreichbare Infrastruktur aus der Perspektive außerhalb des Unternehmensnetzes. External Attack Surface Management kann bekannte Ausgangspunkte mit beobachteten Beziehungen verbinden und Hinweise auf weitere Domains, Hosts, IP-Netze oder Webinfrastruktur liefern. Diese Outside-in-Sicht hilft besonders bei dezentral bereitgestellten Cloud-Ressourcen, historischen Systemen und öffentlich sichtbaren Abhängigkeiten.

Öffentlich beobachtbare Merkmale können DNS- und Zertifikatsinformationen, erreichbare Dienste, TLS-Konfigurationen, E-Mail-Schutzmerkmale und Technologiehinweise umfassen. Sie zeigen Exposition und mögliche Prüfbedarfe. Sie belegen nicht automatisch eine konkrete verwundbare Version. Für eine belastbare Bestätigung können interne Versionsdaten, Herstellerinformationen, authentifizierte Scans oder ein autorisierter Test nötig sein.

Schritt 3: Befunde validieren und Risiken formulieren

Rohdaten sind noch keine Risiken. Beginnen Sie mit der Asset-Zuordnung: Gehört das beobachtete System zur Organisation, zu einem Dienstleister oder zu einer geteilten Plattform? Unterstützt es die betrachtete Geschäftsleistung? Ist der Befund aktuell und reproduzierbar? Eine falsche Zuordnung muss korrigiert werden, bevor sie in einen Score oder eine Eskalation einfließt.

Formulieren Sie anschließend ein nachvollziehbares Risikoszenario. Es verbindet Ursache, Ereignis, betroffenes Schutzgut und mögliche Auswirkung. „TLS auffällig“ ist nur ein Befund. Ein Szenario beschreibt, welcher öffentlich erreichbare Dienst betroffen ist, welche Kommunikationsbeziehung geschützt werden soll und welche Folgen eine plausible Beeinträchtigung für Vertraulichkeit, Integrität oder Verfügbarkeit hätte.

Prüfen Sie vorhandene Kontrollen und kompensierende Maßnahmen. Eine externe Beobachtung erkennt etwa keine Netzwerksegmentierung hinter einem Gateway und keine internen Überwachungsregeln. Umgekehrt kann eine interne Dokumentation einen inzwischen öffentlich erreichbaren Dienst übersehen. Der Abgleich beider Perspektiven verhindert voreilige Schlussfolgerungen.

Halten Sie Unsicherheit offen fest. Mögliche Stufen sind bestätigt, plausibel, unklar und widerlegt. Eine unklare Versionszuordnung darf nicht als bestätigte Schwachstelle erscheinen. Sie kann dennoch eine zeitnahe Prüfung rechtfertigen, wenn das Asset kritisch und öffentlich erreichbar ist. Preemptive Intelligence kann frühe Hinweise aus mehreren Quellen mit der Angriffsfläche abgleichen, auch wenn noch keine abschließende NVD-Bewertung vorliegt. Die anschließende Validierung bleibt erforderlich.

Schritt 4: Priorisieren und Maßnahmen auswählen

Eine brauchbare Priorisierung kombiniert technische Schwere, reale Exposition, Geschäftsauswirkung, Bedrohungskontext, Evidenzqualität und Behebbarkeit. Ein hoher technischer Wert allein entscheidet nicht über die Reihenfolge. Ein öffentlich erreichbarer Dienst in einem kritischen Prozess kann dringlicher sein als eine schwerere, aber isolierte Schwäche in einer Testumgebung.

Ein Security Rating kann mehrere externe Merkmale verdichten und Veränderungen vergleichbar machen. Der Wert dient als Indikator und Filter. Bewertungsmodell, Datenalter und Abdeckung beeinflussen das Ergebnis. Für eine Maßnahme müssen die Einzelbefunde und der Geschäftskontext nachvollziehbar bleiben.

Typische Handlungsoptionen sind Risikominderung, Vermeidung, Übertragung oder Akzeptanz. Die konkrete Maßnahme kann eine Konfigurationsänderung, Abschaltung, Zugriffsbeschränkung, zusätzliche Überwachung, ein Patch, eine Architekturänderung oder eine organisatorische Kontrolle sein. Eine Empfehlung sollte erwartete Wirkung, Aufwand, Nebenwirkungen und eine Möglichkeit zur Wirksamkeitsprüfung nennen.

Ordnen Sie jeder beschlossenen Behandlung einen verantwortlichen Owner und einen Termin zu. Eine zeitlich begrenzte Akzeptanz braucht Begründung, Genehmigung und Wiedervorlage. Wenn Informationen fehlen, kann die erste Maßnahme eine gezielte Validierung sein. So bleibt Unsicherheit sichtbar und wird nicht durch eine scheinbar präzise Zahl verdeckt.

Schritt 5: Ergebnis dokumentieren und aktuell halten

Ein guter Ergebnisbericht beginnt mit Scope, Stichtag, Methoden und Ausschlüssen. Danach folgen eine Managementsicht auf priorisierte Risiken und eine technische Evidenzebene. Jeder Eintrag sollte Asset, Beobachtung, Risikoszenario, Bewertung, Evidenzstufe, bestehende Kontrollen, Entscheidung, Owner und Termin enthalten. Quellen und Zeitpunkte machen spätere Änderungen nachvollziehbar.

Trennen Sie Befund, Risiko und Maßnahme. Diese Struktur erleichtert den Dialog zwischen IT, Informationssicherheit und Geschäftsleitung. Sie verhindert auch, dass ein technischer Hinweis unmittelbar als Geschäftsschaden behandelt wird. Für operative Teams müssen reproduzierbare Details vorhanden sein; das Management benötigt Priorität, Auswirkung, Entscheidung und offene Abhängigkeiten.

Nach der Umsetzung folgt die Nachprüfung. Eine externe Kontrolle kann zeigen, ob ein zuvor erreichbarer Dienst nicht mehr sichtbar ist oder ein Konfigurationsmerkmal geändert wurde. Sie beweist nicht jede interne Umsetzung. Je nach Maßnahme sind Konfigurationsnachweise, ein erneuter Scan, ein Penetrationstest oder ein Audit geeigneter.

Pflegen Sie die Risikoanalyse bei wesentlichen Änderungen. Neue Systeme, geänderte Datenflüsse, Vorfälle, Übernahmen und neue Schwachstelleninformationen können eine Neubewertung auslösen. Eine regelmäßige Außenperspektive ergänzt dieses Ereignismodell. Für einen ersten Ausgangswert kann ein kostenloses Rating Hinweise liefern, die Sie im beschriebenen Prozess validieren und priorisieren.

Praktischer Start für mittelständische Unternehmen

Wählen Sie zunächst einen geschäftsrelevanten, überschaubaren Scope. Benennen Sie den Service-Owner und erfassen Sie bekannte Domains, Anwendungen, Datenarten und Lieferanten. Ergänzen Sie eine externe Ausgangsmessung. Prüfen Sie gemeinsam, welche gefundenen Assets tatsächlich zum Scope gehören und welche internen Informationen für die Risikoeinordnung fehlen.

Bewerten Sie danach wenige priorisierte Szenarien mit einer einfachen, dokumentierten Skala. Vermeiden Sie umfangreiche Kataloge, wenn Verantwortliche und Folgeprozess noch fehlen. Der erste Zyklus sollte zeigen, wie ein Befund von der Beobachtung bis zur verifizierten Behandlung gelangt. Messen Sie Bearbeitungszeit, offene Zuordnungen und wiederkehrende Ursachen.

Erweitern Sie den Scope erst, wenn Rollen, Datenqualität und Eskalation funktionieren. Dadurch bleibt die Analyse handhabbar und liefert früh überprüfbare Entscheidungen. Ein wiederholbarer Prozess ist wichtiger als ein besonders umfangreicher Einmalbericht.

Häufige Fragen

---

Welche Schritte gehören zu einer IT-Risikoanalyse?

Definieren Sie Auftrag, Scope und Bewertungskriterien. Sammeln Sie interne und externe Daten, validieren Sie Befunde, formulieren Sie Risikoszenarien und priorisieren Sie Behandlungen. Dokumentieren Sie Entscheidung, Owner, Termin und Nachprüfung.

---

Welche Datenquellen benötigt eine IT-Risikoanalyse?

Typische Quellen sind Asset- und Service-Inventare, Architektur und Datenflüsse, Berechtigungen, Schwachstellenscans, Vorfälle, Kontrolldokumentation und externe Angriffsflächendaten. Die Auswahl folgt dem Scope und der Entscheidungsfrage.

---

Kann eine externe Analyse interne Risiken erkennen?

Nur begrenzt. Sie zeigt identifizierte beziehungsweise erreichbare Systeme und öffentlich beobachtbare Merkmale. Interne Identitäten, Prozesse, Kontrollen und nicht erreichbare Systeme benötigen andere Datenquellen.

---

Ist ein technischer Befund bereits ein Risiko?

Nein. Für eine Risikoeinordnung müssen Asset-Zuordnung, plausibles Ereignis, betroffenes Schutzgut, mögliche Auswirkung und vorhandene Kontrollen betrachtet werden. Unsicherheit und fehlende Evidenz sollten sichtbar bleiben.

---

Wie oft sollte eine IT-Risikoanalyse aktualisiert werden?

Legen Sie einen regelmäßigen Review und ereignisgesteuerte Auslöser fest. Neue Systeme, geänderte Datenflüsse, Vorfälle, Lieferantenwechsel oder neue Schwachstelleninformationen können eine frühere Neubewertung erfordern.

Sie möchten eine belastbare Außenperspektive als Teil Ihrer IT-Risikoanalyse nutzen? Vereinbaren Sie eine IT-Risikoanalyse mit LocateRisk und definieren Sie gemeinsam mit uns Scope und Auswertung.