Beispieldokument: Diese Regelung beschreibt den Sollprozess für die fiktive „Muster GmbH“. Reale Quellen, Abonnements, Branchenzugänge, Assets, Warnmeldungen, Bedrohungsbewertungen, Erkennungsregeln, Maßnahmen, Freigaben und Wirksamkeitsnachweise sind nicht bestätigt.
Nachweisregel: Ein abonnierter Feed, ein Newsletter, eine Herstellerwarnung oder eine Sammlung von Indicators of Compromise belegt allein keine wirksame Threat Intelligence. Informationen müssen verlässlich entgegengenommen, bewertet, auf eigene Assets und Prozesse bezogen, zielgruppengerecht verteilt, in Maßnahmen überführt und nachverfolgt werden.
TISAX-Hinweis: Die betreffenden Anforderungen sind Teil der vollständigen Bewertung aller 46 Kontrollfragen des ISA-Reiters „Informationssicherheit“. Eine individuelle Auswahl „anwendbar/nicht anwendbar“ wie bei einzelnen Maßnahmen der Statement of Applicability ist nicht vorgesehen.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-09 |
| Dokumentenart | Regelung / Bedrohungsinformationen und Threat Intelligence |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Bedrohungsinformationen |
| Verantwortlich | Informationssicherheitsfunktion |
| Fachlich geprüft durch | ISMS, IT-/OT-Betrieb, Incident Management, Entwicklung, Risikomanagement und betroffene Asset-/Service-Owner |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Quellen, Überwachung, Bewertungen, Verteilung und Wirksamkeit nicht bestätigt |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe und Inbetriebnahme des Prozesses |
| Nächste Prüfung | Mindestens jährlich sowie bei wesentlicher Bedrohungs-, Technologie-, Scope- oder Quellenänderung |
| Schutzklasse | Intern; operative Bedrohungsdaten, Schwachstellen und Erkennungsinformationen häufig Vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.6 und 5.7 sowie Schnittstellen zu 5.9, 5.24 bis 5.28, 8.8 und 8.15 bis 8.16 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Kapitel 1.2, 1.4, 1.6 und 5.2 |
Diese Regelung legt fest, wie Informationen über aktuelle und mögliche Bedrohungen beschafft, bewertet, auf die Organisation bezogen, verteilt und in Entscheidungen oder Maßnahmen überführt werden.
Sie soll sicherstellen, dass:
Die Regelung gilt für Bedrohungsinformationen mit möglichem Bezug zu:
Die Quellen- und Assetabdeckung wird mit dem ISMS-Geltungsbereich und dem Asset-Inventar abgeglichen.
| Prozess | Abgrenzung zu Bedrohungsinformationen |
|---|---|
| Risikomanagement | Bewertet konkrete Risiken aus Asset, Bedrohung, Schwachstelle und Auswirkung; Threat Intelligence liefert aktuelle Eingaben |
| Schwachstellenmanagement | Steuert technische Schwachstellen und Behebung; Threat Intelligence ergänzt aktive Ausnutzung, Kampagnen, TTPs und Priorität |
| Incident Response | Bearbeitet tatsächliche oder vermutete Vorfälle; Erkenntnisse aus Vorfällen werden wiederum Threat-Intelligence-Quelle |
| Protokollierung und Überwachung | Erzeugt und bewertet Ereignisse; Threat Intelligence liefert Hypothesen, Indicators und Erkennungsbedarf |
| Bedrohungsmodellierung | Analysiert Bedrohungen eines konkreten Designs; Threat Intelligence aktualisiert Annahmen und Angriffsmuster |
| Sicherheits-Awareness | Vermittelt zielgruppengerechtes Verhalten; Threat Intelligence liefert aktuelle Angriffsmethoden und Beispiele |
Bedrohungsinformationen ersetzen keinen dieser Prozesse und werden erst durch die Verbindung mit eigenen Schutzobjekten handlungsrelevant.
| Begriff | Bedeutung |
|---|---|
| Bedrohungsinformation | Information, die beim Erkennen, Bewerten, Überwachen oder Behandeln einer Informationssicherheitsbedrohung unterstützt |
| Threat Intelligence | Analysierte und kontextualisierte Bedrohungsinformation mit Relevanz, Bewertung und Handlungsbezug |
| Indicator of Compromise – IoC | Beobachtbares technisches Merkmal, das auf mögliche schädliche Aktivität hinweisen kann |
| Tactic, Technique and Procedure – TTP | Ziel, Vorgehensweise und konkrete Ausführungsmuster eines Angreifers |
| Observable | Beobachtbarer technischer Wert oder Zustand ohne zwingende Bewertung als Kompromittierungsindikator |
| Kampagne | Zusammenhängende Aktivitäten mit gemeinsamen Zielen, Infrastruktur, Vorgehensweisen oder Akteuren |
| Bedrohungsakteur | Person, Gruppe, Organisation oder sonstige Quelle einer absichtlichen Bedrohung |
| Confidence | Einschätzung, wie belastbar Information und analytische Schlussfolgerung sind |
| Relevanz | Grad des Bezugs zu eigenen Assets, Technologien, Prozessen, Regionen, Kunden oder Lieferanten |
| Intelligence Requirement | Konkrete Fragestellung, die durch Bedrohungsinformationen beantwortet werden soll |
| TLP | Traffic Light Protocol zur Kennzeichnung zulässiger Weitergabegrenzen |
| Intelligence-Lebenszyklus | Anforderungen, Sammlung, Verarbeitung, Analyse, Verteilung, Handlung und Rückmeldung |
| Ebene | Zeithorizont | Typische Inhalte | Zielgruppe |
|---|---|---|---|
| Strategisch | Monate bis Jahre | Bedrohungstrends, Akteursziele, Geopolitik, Branche, Lieferketten und Technologieentwicklung | Geschäftsführung, ISMS, Risikomanagement |
| Taktisch | Wochen bis Monate | Angriffsmuster, TTPs, Kampagnen und typische Verteidigungsdefizite | Security, Architektur, IT/OT, Entwicklung |
| Operativ | Stunden bis Wochen | Konkrete Kampagnen, Ziele, Zeitfenster, Akteure und erwartete Aktivitäten | Incident Management, Security Operations, Owner |
| Technisch | Minuten bis Tage | Indicators, Schwachstellen, Domains, IPs, Hashes, Signaturen und Erkennungslogik | Security Operations, IT/OT-Betrieb, Vulnerability Management |
Eine Informationsquelle kann mehrere Ebenen bedienen. Technische Indicators verlieren häufig schneller ihre Aussagekraft als strategische Erkenntnisse und benötigen daher kurze Prüf- und Ablaufzyklen.
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Strategische Bedrohungslage, Ressourcen, wesentliche Risiken und Eskalationen entscheiden |
| Informationssicherheitsfunktion | Prozess, Quellenkatalog, Anforderungen, Analysen, Verteilung und Berichterstattung steuern |
| Threat-Intelligence-Koordination | Eingang, Triage, Kontextualisierung, Datensätze, Fristen und Feedback koordinieren |
| IT-/OT-Security Operations | Technische Relevanz, Suche, Erkennung, Sperrung und Überwachung umsetzen |
| Vulnerability Management | Bedrohungsinformationen in Schwachstellenpriorisierung und Behandlung übernehmen |
| Incident Management | Akute Verdachtsmomente bearbeiten und Incident-Erkenntnisse zurückführen |
| Risikomanagement / ISMS | Bedrohungsänderungen in Risikoregister, SoA, Ziele und Managementbewertung einfließen lassen |
| Asset-/Service-Owner | Betroffenheit, Geschäftsauswirkung und fachliche Maßnahme für eigene Assets bewerten |
| Entwicklung / Architektur | TTPs und Bedrohungstrends in Threat Models, Anforderungen und Sicherheitsarchitektur übernehmen |
| Lieferantenmanagement | Externe Abhängigkeiten, Anbieterwarnungen und Supply-Chain-Risiken steuern |
| Datenschutz / Recht | Personenbezug, Weitergabe, Quellenbedingungen und rechtliche Grenzen prüfen |
| Kommunikation / Awareness | Freigegebene zielgruppengerechte Hinweise und Warnungen bereitstellen |
Vor Auswahl von Quellen werden Prior Intelligence Requirements – PIR – beziehungsweise interne Informationsbedarfe festgelegt.
| Requirement-ID | Fragestellung | Schutzobjekt / Scope | Empfänger | Dringlichkeit | Review |
|---|---|---|---|---|---|
| PIR-EX-001 | Welche aktiv ausgenutzten Schwachstellen betreffen internetexponierte kritische Assets? | [Assetgruppen] |
Vulnerability Management / Owner | Hoch | [Turnus] |
| PIR-EX-002 | Welche Angriffsmuster gefährden Produktions- und OT-Umgebungen? | [OT-Scope] |
OT / Produktion / ISMS | Hoch | [Turnus] |
| PIR-EX-003 | Welche Lieferkettenkampagnen betreffen eingesetzte Anbieter oder Komponenten? | [Lieferanten/Technologien] |
Einkauf / IT / Entwicklung | Mittel | [Turnus] |
| PIR-EX-004 | Welche Social-Engineering-Themen betreffen Branche und Funktionen? | [Zielgruppen] |
Personal / Awareness / Incident | Mittel | [Turnus] |
Die Beispiele sind keine bestätigten Anforderungen. Anforderungen werden mit Risiko, Schutzbedarf, Geschäftsmodell und verfügbaren Ressourcen abgestimmt.
| Kategorie | Beispiele | Typischer Nutzen |
|---|---|---|
| Behörden / nationale CERTs | BSI-BITS, CERT- und Warninformationen | Lage, Schwachstellen, Gefährdungen, Vorfälle und Handlungshinweise |
| Europäische Stellen | ENISA Threat Landscape und Fachpublikationen | strategische und sektorale Lage |
| Hersteller / Anbieter | Security Advisories, Release Notes, Incident- und Statusmeldungen | Produkt-, Versions- und Servicebezug |
| Schwachstellenquellen | CVE-/NVD-Informationen, CISA KEV, Herstellerhinweise | Schwachstelle und aktive Ausnutzung |
| Branchen- und Austauschgruppen | ISACs, Verbände, Fach- und Interessengruppen | sektorale Erfahrungen und Frühwarnungen |
| Kunden / Partner | Sicherheitsmitteilungen, Vertrags- und Projektwarnungen | kundenspezifische Bedrohungen und Pflichten |
| Kommerzielle Dienste | Threat-Intelligence-Plattformen und kuratierte Feeds | angereicherte operative und technische Daten |
| Interne Quellen | Incidents, Logs, Alarme, Schwachstellen, Audits, Helpdesk und Betrugsfälle | organisationsspezifische Beobachtungen |
| Forschung / Community | Fachpublikationen, koordinierte Disclosure und vertrauenswürdige Forschung | neue Methoden, Kampagnen und technische Details |
Ein Quellenname allein belegt weder Qualität noch Berechtigung zur Weitergabe.
| Feld | Mindestinhalt |
|---|---|
| Quellen-ID | Eindeutige Kennung |
| Herausgeber / Betreiber | Organisation und Kontakt |
| Quelle / Kanal | Portal, Feed, E-Mail, API, Austauschgruppe oder Bericht |
| Themen / Scope | Technologien, Regionen, Branchen, Bedrohungsarten |
| Zielgruppe / Nutzen | Beantwortete Intelligence Requirements |
| Aktualisierung | Echtzeit, täglich, wöchentlich, monatlich oder anlassbezogen |
| Vertrauenswürdigkeit | Bewertete Historie, Kompetenz und Transparenz |
| Bedingungen | Lizenz, Vertrag, Vertraulichkeit und Weitergabe |
| TLP / Schutz | erwartete und zulässige Kennzeichnung |
| Authentisierung | Schutz und Prüfung des Bezugswegs |
| Owner / Stellvertretung | Empfang und Pflege |
| Letzte Prüfung | Datum und Ergebnis |
| Status | Vorgeschlagen, pilotiert, freigegeben, eingeschränkt oder beendet |
Quellen werden mindestens anhand folgender Kriterien geprüft:
Quellen werden bei Qualitätsverlust, Kompromittierung, Vertragsänderung oder fehlendem Nutzen neu bewertet.
Kontakte zu geeigneten Fach- und Interessengruppen unterstützen den Erfahrungsaustausch und die Frühwarnung.
Vor Teilnahme werden festgelegt:
Eine Mitgliedschaft ohne aktive Auswertung und interne Nutzung gilt nicht als wirksame Maßnahme.
Bedrohungsinformationen werden in einem führenden Register oder Werkzeug erfasst.
| Feld | Mindestinhalt |
|---|---|
| Intelligence-ID | Eindeutige Kennung |
| Eingangszeit | Datum, Uhrzeit und Zeitzone |
| Quellen-ID | Referenz zum Quellenregister |
| Originalreferenz | Version, Link, Message-ID oder Dokumenten-ID |
| TLP / Klassifizierung | Übernommene und interne Schutzkennzeichnung |
| Typ | Strategisch, taktisch, operativ oder technisch |
| Kurzbeschreibung | Wesentliche Aussage ohne unzulässige Weitergabe |
| Observables / Referenzen | IoCs, CVEs, TTPs, Kampagnen oder Akteure, soweit zulässig |
| Aktualität / Gültigkeit | Veröffentlichungszeit, Beobachtungszeitraum und Ablauf |
| erste Dringlichkeit | Noch unbestätigte Triage |
| Bearbeitungsrolle | Owner und Vertretung |
| Status | Neu, in Prüfung, relevant, nicht relevant, umgesetzt, überwacht oder archiviert |
Beim Empfang werden berücksichtigt:
Malware-Samples, Exploitcode und hochsensitive Indicators werden nur in dafür freigegebenen Umgebungen verarbeitet.
Die Erstbewertung beantwortet:
Akute Hinweise werden nicht bis zum nächsten Regeltermin zurückgestellt.
| Stufe | Typische Merkmale | Mindestaktion | Zielzeit |
|---|---|---|---|
| TI-1 – Kritisch | Laufende oder unmittelbar erwartete Aktivität mit Bezug zu kritischen eigenen Assets | Incident-/Krisenprüfung, sofortige Suche und Eindämmungsentscheidung | Unverzüglich; konkrete Zeit festzulegen |
| TI-2 – Hoch | Aktive Ausnutzung, relevante Kampagne oder hohe Exposition ohne bestätigten eigenen Vorfall | priorisierte Betroffenheits- und Schutzprüfung | Zielzeit festzulegen |
| TI-3 – Mittel | Plausible Relevanz, aber keine unmittelbare Aktivität oder begrenzte Exposition | geplante Analyse und gegebenenfalls Maßnahme | Zielzeit festzulegen |
| TI-4 – Beobachtung | Strategische Information oder derzeit kein konkreter eigener Bezug | Trendbeobachtung, Dokumentation oder begründeter Abschluss | Turnus festzulegen |
Die Stufe wird aus Dringlichkeit und möglicher Wirkung abgeleitet und ersetzt keine vollständige Risikobewertung.
Quelle und Information werden getrennt bewertet:
| Dimension | Beispielhafte Skala |
|---|---|
| Quellenvertrauen | Hoch, Mittel, Niedrig oder Unbekannt |
| Informationsgüte | Bestätigt, wahrscheinlich, möglich, unbestätigt oder widerlegt |
| Aktualität | Aktuell, noch gültig, veraltet oder unbekannt |
| Relevanz | Direkt, wahrscheinlich, indirekt oder kein Bezug |
| Vollständigkeit | Ausreichend, teilweise oder unzureichend |
Analytische Einschätzungen enthalten:
Die Relevanzprüfung gleicht Informationen ab mit:
Unvollständige Inventare werden als Unsicherheit dokumentiert und nicht als Beleg fehlender Betroffenheit verwendet.
| Faktor | Leitfrage |
|---|---|
| Betroffenheit | Wird eine eingesetzte Technologie, Region, Branche, Rolle oder Abhängigkeit adressiert? |
| Exposition | Ist das Schutzobjekt erreichbar, sichtbar oder anderweitig angreifbar? |
| Ausnutzbarkeit | Existieren aktive Ausnutzung, Exploit, Kampagne oder leicht nutzbare Technik? |
| Kritikalität | Welche Prozesse, Kunden und Sicherheitsziele hängen vom Asset ab? |
| vorhandene Kontrollen | Welche Prävention, Erkennung, Segmentierung oder Wiederherstellung besteht tatsächlich? |
| Reichweite | Ist ein Einzelasset, ein Standort, die Lieferkette oder die gesamte Organisation betroffen? |
| Zeit | Wie schnell kann sich Bedrohung, Indicator oder Schutzoption ändern? |
| Unsicherheit | Welche Bestands-, Quellen- oder Analyseinformationen fehlen? |
Soweit zulässig und erforderlich werden Informationen angereichert mit:
Fremde Zuordnungen und Scores werden nicht ungeprüft als interne Wahrheit übernommen.
Für Indicators werden mindestens geführt:
Abgelaufene Indicators werden aus produktiven Regeln entfernt oder neu bestätigt. Ein Treffer wird fachlich untersucht und nicht automatisch als bestätigter Vorfall kommuniziert.
TTPs und Kampagnen werden genutzt, um über kurzlebige Indicators hinaus zu prüfen:
ATT&CK-Referenzen unterstützen eine einheitliche Sprache, ersetzen aber keine eigene Analyse oder vollständige Kontrollabdeckung.
Relevante Erkenntnisse werden in prüfbare Erkennungsanforderungen überführt:
| Feld | Mindestinhalt |
|---|---|
| Detection-ID | Eindeutige Kennung |
| Intelligence-/Threat-Bezug | Quelle, TTP, Kampagne oder Indicator |
| Schutzziel / Hypothese | Was soll erkannt werden? |
| Datenquellen | Erforderliche Logs, Telemetrie und Kontextdaten |
| Logik | Regel, Abfrage oder Analyseverfahren |
| Scope | Systeme, Identitäten, Standorte und Zeitbereich |
| Test | Positiv-, Negativ- und Fehlalarmprüfung |
| Owner | Entwicklung, Betrieb und Review |
| Produktivstatus | Entwurf, Test, aktiv, eingeschränkt oder außer Betrieb |
| Wirksamkeit | Treffer, Abdeckung, Lücke und letzter Test |
Eine aktivierte Regel ohne Test, Datenabdeckung und Reaktionsweg ist kein ausreichender Wirksamkeitsnachweis.
Ein Threat Hunt wird erwogen, wenn:
Ein Hunt enthält Hypothese, Scope, Datenquellen, Zeitraum, Methode, Ergebnis, Grenzen, Befunde und Folgemaßnahmen.
Bedrohungsinformationen ergänzen die Bewertung im Schwachstellen- und Patchmanagement insbesondere durch:
Ein KEV-Eintrag ist ein wichtiges Priorisierungssignal, aber keine vollständige organisationsspezifische Risikobewertung.
Eine Bedrohungsinformation wird an Incident Response übergeben, wenn:
Incident-Erkenntnisse fließen zurück, soweit rechtlich und vertraglich zulässig:
Bedrohungsänderungen führen zur Prüfung von:
Die formale Bewertung erfolgt nach Methodik der Risikobewertung und wird im Risikoregister geführt.
Relevante Erkenntnisse aktualisieren:
Die Umsetzung folgt Sichere Entwicklung.
Bei externen Abhängigkeiten werden geprüft:
Ein Providerstatus „nicht betroffen“ wird anhand Scope, Begründung und eigener Exposition plausibilisiert.
Der Prozess berücksichtigt neben Cyberbedrohungen auch:
Die Fachbewertung erfolgt durch die jeweils zuständigen Rollen und wird nicht allein von der IT vorgenommen.
| Empfängergruppe | Typische Information | Form |
|---|---|---|
| Geschäftsführung | strategische Lage, Auswirkungen, Entscheidungen und Ressourcen | Lagebericht / Managementbewertung |
| ISMS / Risiko | Szenarien, Trends, Kontroll- und Restrisikoänderungen | Risiko- und Maßnahmenreferenz |
| IT-/OT-Betrieb | betroffene Technologien, Maßnahmen und Fristen | priorisierte technische Warnung |
| Security Operations | Indicators, TTPs, Detection und Hunting | geschützter technischer Datensatz |
| Entwicklung / Architektur | Angriffsmuster, Komponenten und Designfolgen | Security-Anforderung / Threat-Model-Update |
| Lieferantenmanagement | Anbieter-, Supply-Chain- und Vertragsbezug | Lieferantenaktion |
| Beschäftigte | konkrete, freigegebene Verhaltenswarnung | Awareness-Hinweis |
| Incident-/Krisenteam | akute Lage, Betroffenheit und Entscheidungsbedarf | Alarmierung / Lagebild |
Empfänger erhalten nur die für Aufgabe und Schutzfreigabe erforderlichen Informationen.
Für TLP wird die aktuelle FIRST-Fassung verwendet. TLP 2.0 kennt vier Grundkennzeichnungen; TLP:AMBER kann durch +STRICT enger auf die eigene Organisation begrenzt werden:
| Kennzeichnung | Weitergabegrundsatz |
|---|---|
| TLP:RED | Nur an die konkret benannten Empfänger; keine weitere Weitergabe |
| TLP:AMBER | Begrenzte Weitergabe innerhalb der Organisation und an erforderliche Kunden nach Vorgabe der Quelle |
| TLP:AMBER+STRICT | Weitergabe auf die eigene Organisation beschränkt |
| TLP:GREEN | Begrenzte Weitergabe innerhalb der Community, nicht über öffentlich zugängliche Kanäle |
| TLP:CLEAR | Weitergabe ohne TLP-bedingte Einschränkung |
Dabei gilt:
Vor ausgehender Weitergabe werden geprüft:
Indicators oder Incident-Daten werden vor Weitergabe erforderlichenfalls minimiert, pseudonymisiert oder aggregiert.
Bedrohungsinformationen können personenbezogene Daten enthalten, beispielsweise:
Vor Verarbeitung oder Weitergabe werden Zweck, Rechtsgrundlage, Erforderlichkeit, Datenminimierung, Empfänger, Aufbewahrung und Schutz geprüft. Unbestätigte Verdächtigungen werden besonders vorsichtig behandelt.
Für jeden Datensatz werden festgelegt:
Ein historischer Analysewert rechtfertigt nicht automatisch die unbegrenzte operative Nutzung personenbezogener oder technisch riskanter Daten.
| Feld | Mindestinhalt |
|---|---|
| Maßnahme-ID | Eindeutige Kennung |
| Intelligence-/Threat-ID | Auslösende Information |
| betroffener Scope | Assets, Prozesse, Standorte, Lieferanten oder Zielgruppen |
| Aktion | Suche, Blockierung, Patch, Konfiguration, Kommunikation, Risiko- oder Architekturänderung |
| Priorität und Termin | Begründet aus Dringlichkeit und Wirkung |
| Owner / Vertretung | Verantwortliche Rollen |
| Erfolgs- und Wirksamkeitskriterium | Erwartetes prüfbares Ergebnis |
| Umsetzungsnachweis | Ticket, Konfiguration, Suchergebnis oder andere Referenz |
| Restrisiko / Ausnahme | Entscheidung und Ablaufdatum |
| Abschlussprüfung | Ergebnis, Prüferrolle und Datum |
Empfänger geben zurück:
Feedback wird in Quellenbewertung, Automatisierung, Priorisierung und Berichtsform übernommen.
Mindestens periodisch werden zusammengeführt:
Die Bewertung nennt Zeitraum, Quellen, Confidence, eigene Relevanz, offene Fragen und empfohlene Entscheidungen.
Für die Managementbewertung werden mindestens bereitgestellt:
Ein allgemeiner Lagebericht ohne Bezug zur eigenen Organisation ist kein ausreichender Managementinput.
Geeignete Nachweise sind:
Sicherheitskritische Inhalte werden geschützt referenziert und nicht unkontrolliert in Audit- oder Wiki-Seiten kopiert.
| Kontrolle | Mindestinhalt | Frequenz / Anlass | Nachweis |
|---|---|---|---|
| Quellenreview | Nutzen, Qualität, Abdeckung, Bedingungen und Verfügbarkeit | Mindestens jährlich | Quellenbewertung |
| Eingangsüberwachung | Vollständigkeit und zeitgerechte Bearbeitung | Regelmäßig | Queue-/Registerprüfung |
| TI-1/TI-2-Stichprobe | Zeit, Assetbezug, Maßnahme und Eskalation | Quartalsweise oder anlassbezogen | Prüfprotokoll |
| Indicator-Review | Gültigkeit, False Positives und Entfernung | Nach Ablauf-/Reviewdatum | Regel-/Datensatzprüfung |
| Asset-Matching-Test | Technologien, Versionen und Owner korrekt zuordenbar | Risikobasiert | Testbericht |
| Detection-Test | Daten, Logik, Alarmierung und Reaktion | Vor Aktivierung und regelmäßig | Testergebnis |
| Weitergabeprüfung | TLP, Empfänger, Datenschutz und Vertrag | Stichprobenbasiert | Freigabe-/Versandnachweis |
| Risikoschnittstelle | Relevante Änderungen in Risiken übernommen | Mindestens jährlich und anlassbezogen | Risikoabgleich |
| Managementbericht | Eigener Bezug, Trends und Entscheidungen | Nach festgelegtem Turnus | Lagebericht / Beschluss |
Mindestens betrachtet werden:
Hohe Meldungsmengen oder Feedvolumen sind keine Erfolgskennzahl.
Abweichungen sind beispielsweise:
Eine Abweichung gilt erst als wirksam geschlossen, wenn Ursache, vergleichbarer Scope, Umsetzung und praktische Wirkung geprüft wurden.
Geeignete Auditstichproben sind:
Für den ISA-Reiter „Informationssicherheit“ gilt:
Die Detailbewertung erfolgt in der VDA-ISA-Selbsteinschätzung.
| Annex-A-Control | Beitrag dieser Regelung | Aktueller Status |
|---|---|---|
| A.5.6 Kontakte zu Fach- und Interessengruppen | Auswahl, Teilnahme, Austausch, Schutz und Nutzenprüfung | Geplant; Kontakte und Mitgliedschaften nicht bestätigt |
| A.5.7 Auswertung von Bedrohungsinformationen | Anforderungen, Quellen, Analyse, Verteilung, Maßnahmen und Feedback | Geplant; Prozess nicht in Betrieb |
| A.5.9 Inventar von Informationen und anderen zugehörigen Assets | Grundlage für Relevanz- und Betroffenheitsabgleich | Assetbestand unvollständig |
| A.5.24 bis A.5.28 Incident Management | Eskalation akuter Erkenntnisse und Rückfluss aus Incidents | Schnittstelle beschrieben; nicht getestet |
| A.8.8 Management technischer Schwachstellen | aktive Ausnutzung und Priorisierung | Schnittstelle beschrieben; nicht belegt |
| A.8.15 und A.8.16 Protokollierung und Überwachung | Detection, Hunting und interne Beobachtungen | Spezialregelung/Umsetzung noch unvollständig |
Die Anwendbarkeit der Annex-A-Controls wird im Statement of Applicability begründet. Dieses Vorgehen wird nicht als individuelle N/A-Auswahl auf die TISAX-Informationssicherheitsfragen übertragen.
| Element | Regelung/Planung | Reale Umsetzung | Wirksamkeit | Status |
|---|---|---|---|---|
| Intelligence Requirements | Vorlage vorhanden | Nicht bestätigt | Nicht geprüft | Offen |
| Quellenregister | Pflichtfelder definiert | Nicht befüllt | Nicht geprüft | Offen |
| Fach-/Interessengruppen | Auswahlverfahren beschrieben | Nicht bestätigt | Nicht geprüft | Offen |
| Eingang und Triage | Sollprozess beschrieben | Kein Werkzeug/Queue bestätigt | Nicht geprüft | Offen |
| Asset- und Technologieabgleich | Verfahren beschrieben | Inventarabdeckung nicht bestätigt | Nicht geprüft | Offen |
| Indicators / TTPs | Lebenszyklus beschrieben | Keine produktiven Datensätze bestätigt | Nicht geprüft | Offen |
| Detection / Hunting | Anforderungen beschrieben | Daten- und Regelabdeckung offen | Nicht geprüft | Offen |
| Maßnahmen / Feedback | Pflichtfelder beschrieben | Nicht nachgewiesen | Nicht geprüft | Offen |
| Lagebericht | Mindestinhalt definiert | Nicht erstellt | Nicht geprüft | Offen |
| TISAX-Bewertung | Zuordnung beschrieben | 0 von 46 Fragen bewertet | Nicht geprüft | Offen |
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| Prozess-Owner und operative Vertretung benennen | Geschäftsführung / ISMS | Offen |
| Intelligence Requirements aus Risiken und Geschäftsmodell bestätigen | ISMS / Owner | Offen |
| Quellen auswählen, bewerten und vertraglich freigeben | ISMS / IT / Einkauf | Offen |
| Fach- und Interessengruppen sowie Austauschregeln bestimmen | ISMS / Recht | Offen |
| Führendes Register beziehungsweise Werkzeug und Queue einrichten | IT / ISMS | Offen |
| Triage-, Dringlichkeits- und Eskalationszeiten freigeben | ISMS / Incident / Geschäftsführung | Offen |
| Asset-, Technologie-, Komponenten- und Lieferantenabgleich herstellen | Asset Owner / IT / Einkauf | Offen |
| TLP-, Klassifizierungs-, Datenschutz- und Weitergaberegeln operationalisieren | ISMS / Datenschutz / Recht | Offen |
| Indicator-Lebenszyklus und Ablaufsteuerung technisch umsetzen | Security Operations | Offen |
| Detection- und Hunting-Prozess mit Datenquellen und Tests aufbauen | Security Operations / IT | Offen |
| Schnittstellen zu Schwachstellen, Incident, Risiko und Entwicklung testen | jeweilige Prozess-Owner | Offen |
| Strategische Lagebewertung und Managementturnus festlegen | ISMS / Geschäftsführung | Offen |
| Kennzahlen, Prüfplan und Wirksamkeitskriterien freigeben | ISMS / Audit | Offen |
| Erste End-to-End-Stichprobe durchführen | Interne Audits / ISMS | Offen |
| Formale fachliche Prüfung und Freigabe dokumentieren | Geschäftsführung | Offen |
| Prüffrage | Ergebnis | Nachweis/Kommentar |
|---|---|---|
| Sind Intelligence Requirements bestätigt? | Nein | Fachliche Festlegung fehlt |
| Decken die Quellen Scope, Technologien und Abhängigkeiten ab? | Nicht prüfbar | Quellenregister fehlt |
| Sind Empfang, Vertretung und zeitnahe Triage sichergestellt? | Nein | Betriebsmodell fehlt |
| Sind TLP, Klassifizierung und Weitergabe operationalisiert? | Nein | Verfahren nicht getestet |
| Ist der Asset- und Technologieabgleich belastbar? | Offen | Inventarprüfung erforderlich |
| Werden akute Erkenntnisse an Incident und Vulnerability Management übergeben? | Nicht nachgewiesen | End-to-End-Test fehlt |
| Werden Indicators kontrolliert getestet und befristet? | Nicht nachgewiesen | Technik und Datensätze fehlen |
| Fließen Trends in Risiken und Managemententscheidungen ein? | Nicht nachgewiesen | Lagebericht fehlt |
| Sind Maßnahmen mit Owner, Termin und Wirksamkeit geführt? | Nicht nachgewiesen | Maßnahmenregister fehlt |
| Wurde der Prozess intern auditiert? | Nein | Erstprüfung ausstehend |
| Liegt eine formale Freigabe vor? | Nein | Entwurfsstatus |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Regelung für Anforderungen, Quellen, Triage, Analyse, Assetabgleich, Indicators, TTPs, Detection, Verteilung, Maßnahmen und Wirksamkeit angelegt | ISMS / Informationssicherheit | Ausstehend | – |
| Funktion | Name | Entscheidung | Datum |
|---|---|---|---|
| Geschäftsführung | – | Ausstehend | – |
| Informationssicherheitsfunktion | – | Fachliche Prüfung ausstehend | – |
| IT-/OT-Security und Betrieb | – | Technische Prüfung ausstehend | – |
| Incident- und Risikomanagement | – | Schnittstellenprüfung ausstehend | – |
| Datenschutz / Recht / Einkauf | – | Quellen- und Weitergabeprüfung ausstehend | – |
Maßgeblich bleiben die lizenzierten Normtexte, die für das Assessment verbindliche ISA-Version, die Bedingungen der jeweiligen Informationsquelle sowie die freigegebenen internen Risiko-, Asset-, Incident- und Schutzanforderungen.