Beispieldokument: Diese Regelung beschreibt den Sollprozess für die fiktive „Muster GmbH“. Reale Assets, Scanabdeckungen, Produktversionen, Schwachstellen, Patchstände, Wartungsfenster, Freigaben, Ausnahmen und Wirksamkeitsnachweise sind noch nicht vollständig erfasst oder bestätigt. Die Seite allein belegt kein wirksames Schwachstellen- oder Patchmanagement.
Bewertungsregel: Ein CVSS-Basiswert, ein Herstellerhinweis oder der Ticketstatus „erledigt“ genügt nicht als alleinige Risikobewertung oder als Wirksamkeitsnachweis. Aktive Ausnutzung, Exposition, Assetkritikalität, Geschäfts- und Sicherheitsauswirkungen, vorhandene Schutzmaßnahmen, Patchverträglichkeit und das technische Prüfergebnis werden gemeinsam betrachtet.
TISAX-Hinweis: Die Kontrollfragen zur Betriebssicherheit sind Bestandteil der 46 Informationssicherheitsfragen. Alle 46 Fragen werden umgesetzt und bewertet; eine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der Statement of Applicability ist nicht vorgesehen. Diese Spezialregelung unterstützt mehrere Kontrollfragen, ersetzt aber nicht deren einzelne Bewertung in der VDA-ISA-Selbsteinschätzung.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-05 |
| Dokumentenart | Regelung / Schwachstellen- und Patchmanagement |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Schwachstellen-und-Patchmanagement |
| Verantwortlich | IT-Leitung |
| Fachlich geprüft durch | ISMS-Beauftragte/r, IT-/OT-Betrieb, Entwicklung, betroffene System-, Application- und Service Owner |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Scanabdeckung, Patchfristen und Wirksamkeit nicht bestätigt |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe |
| Nächste Prüfung | Spätestens zwölf Monate nach Freigabe sowie anlassbezogen |
| Schutzklasse | Intern; technische Schwachstellen- und Systemdetails Vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.7, A 5.19 bis A 5.23, A 8.8, A 8.9, A 8.19 und A 8.32 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Kapitel 5.2 Betriebssicherheit; Schnittstellen zu 1.3, 1.4, 1.5, 1.6, 5.3 und 6.1 |
Diese Regelung legt fest, wie technische Schwachstellen und sicherheitsrelevante Aktualisierungen über ihren gesamten Bearbeitungszyklus erkannt, bewertet, priorisiert, behandelt, nachverfolgt und auf Wirksamkeit geprüft werden.
Sie soll insbesondere sicherstellen, dass:
Die Regelung gilt für:
Der tatsächliche Umfang wird mit Geltungsbereich und Standorte, Asset-Inventar, Lieferanten und Dienstleister sowie den freigegebenen Netz-, Service- und Komponentenübersichten abgeglichen.
| Begriff | Bedeutung in dieser Regelung |
|---|---|
| Schwachstelle | Technische oder konfigurationsbezogene Schwäche, die Schutzwerte beeinträchtigen kann |
| Sicherheitsmeldung | Hinweis eines Herstellers, CERT, Forschenden, Kunden, Dienstleisters oder internen Systems |
| CVE | Öffentliche Kennung für eine bekannte Schwachstelle, soweit vergeben |
| CVSS | Standardisierte Beschreibung technischer Merkmale und Schwere einer Schwachstelle |
| KEV | Nachweis, dass eine bekannte Schwachstelle tatsächlich aktiv ausgenutzt wird, beispielsweise über den CISA-KEV-Katalog |
| Patch | Vom Hersteller oder einer autorisierten Quelle bereitgestellte Fehler- oder Sicherheitskorrektur |
| Update/Upgrade | Aktualisierung oder Versionswechsel mit möglicher Sicherheitswirkung |
| Mitigation | Kompensierende oder eindämmende Maßnahme ohne vollständige Beseitigung der Ursache |
| Remediation | Dauerhafte Behandlung, beispielsweise Patch, sichere Konfiguration, Ersatz oder Außerbetriebnahme |
| False Positive | Technischer Befund, der nach nachvollziehbarer Prüfung für das Asset nicht zutrifft |
| Restrisiko | Nach Behandlung verbleibendes und ausdrücklich bewertetes Risiko |
| Zero-Day | Schwachstelle, für die zum Bewertungszeitpunkt keine ausreichende Herstellerkorrektur verfügbar ist oder die noch nicht allgemein behoben werden kann |
Patchmanagement umfasst neben Sicherheitskorrekturen auch Updates, die für einen sicheren und unterstützten Systemzustand notwendig sind. Funktionale Änderungen werden zusätzlich über IT-Betrieb und Änderungen gesteuert.
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Ressourcen, wesentliche Restrisiken, Eskalationen und nicht tolerierbare Dauerabweichungen entscheiden |
| IT-Leitung | Gesamtprozess, Werkzeuge, Patchzyklen, Ressourcen, Eskalationen und Berichterstattung verantworten |
| Informationssicherheitsfunktion | Bewertungsmethodik, Bedrohungslage, Risiko- und Ausnahmeprüfung sowie Wirksamkeitskontrollen unterstützen |
| Vulnerability-Management-Koordination | Meldungen konsolidieren, Betroffenheit koordinieren, Fristen überwachen und Status berichten |
| System-/Application Owner | Betroffenheit, Kritikalität, Wartungsfenster, Behandlung und Nachweise für das Asset verantworten |
| Service Owner | Geschäftsauswirkung, Kundenanforderungen, Verfügbarkeit und Dienstabhängigkeiten bewerten |
| IT-/OT-Betrieb | Bestände pflegen, Scans und technische Prüfungen durchführen, Patches testen und ausrollen |
| Entwicklung | Code-, Bibliotheks-, Container- und Abhängigkeitsschwachstellen bewerten und beheben |
| OT-/Produktionsverantwortliche/r | Anlagenrisiko, Herstellerfreigabe, Sicherheits- und Produktionsauswirkung koordinieren |
| Incident-Response-Team | Bei aktiver Ausnutzung, Kompromittierungsverdacht oder Sicherheitsvorfall übernehmen beziehungsweise mitwirken |
| Einkauf/Lieferantenmanagement | Melde-, Patch-, Support-, Reaktions- und Nachweispflichten vertraglich steuern |
| Datenschutz | Auswirkungen auf personenbezogene Daten und etwaige Meldepflichten beraten |
| BCM/Notfallmanagement | Kritische Dienste, Rückfall, Notbetrieb und Wiederanlauf berücksichtigen |
| Interne Revision/Audit | Prozess, Stichproben und Wirksamkeit angemessen unabhängig prüfen |
Die ausführende Person darf kritische Befunde nicht ohne dokumentierte Validierung, Genehmigung oder geeignete Kontrollinstanz selbst als „nicht betroffen“ oder „wirksam geschlossen“ deklarieren.
Für ein wirksames Verfahren werden mindestens benötigt:
| Prüffeld | Beispielstatus |
|---|---|
| Assets vollständig erfasst | Nicht bestätigt |
| Produkt- und Versionsdaten aktuell | Nicht bestätigt |
| Kritikalität und Owner zugeordnet | Teilweise im Entwurf |
| Internetexponierte Systeme gekennzeichnet | Nicht vollständig erhoben |
| OT-/Legacy-Systeme gekennzeichnet | Nicht vollständig erhoben |
| Cloud- und Lieferantenverantwortung geklärt | Nicht vollständig bestätigt |
| Scanabdeckung messbar | Nicht erhoben |
| Patchwerkzeug-Abdeckung messbar | Nicht erhoben |
Eine Abdeckungsquote wird nur ausgewiesen, wenn Zähler, Nenner, Ausschlüsse, Datenstand und Quelle nachvollziehbar sind.
Relevante Quellen werden risikobasiert festgelegt und auf Aktualität überwacht:
| Quellengruppe | Beispiele | Erwartete Verarbeitung |
|---|---|---|
| Hersteller und Anbieter | Security Advisories, Supportportale, Firmware- und Patchinformationen | Produkt- und Versionsabgleich |
| CERT und Behörden | CERT-Bund/BSI, nationale und branchenspezifische Warnungen | Lagebild, Warnung und Priorisierung |
| aktiv ausgenutzte Schwachstellen | CISA Known Exploited Vulnerabilities Catalog und verifizierte Herstellerhinweise | beschleunigte Prüfung und Behandlung |
| Schwachstellendaten | CVE-/NVD-Daten, CVSS-Vektoren und maschinenlesbare Advisories | technische Einordnung, nicht alleinige Priorität |
| interne Werkzeuge | Infrastruktur-, Web-, Cloud-, Container-, Code- und Abhängigkeitsscans | assetbezogene Befunde |
| Sicherheitsprüfungen | Penetrationstests, Red-Team-Übungen, Konfigurations- und Quellcodeprüfungen | validierte Feststellungen und Maßnahmen |
| Betrieb und Monitoring | EDR, SIEM, Logs, Fehler- und Inventardaten | Indikatoren, Exposition und Anomalien |
| Dritte | Kunden, Lieferanten, Forschende, Beschäftigte und koordinierte Meldestellen | vertrauliche Annahme und Triage |
| Vorfälle und Audits | Incident Reviews, interne und externe Audits | Ursachen, Wiederholungsbefunde und Verbesserungen |
Für jede wesentliche Quelle werden Owner, Abruf- oder Empfangsweg, Überwachungsintervall, Vertretung und Eskalation festgelegt.
Meldungen werden so entgegengenommen, dass:
| Eingangsfeld | Mindestinhalt |
|---|---|
| Meldungs-ID | Eindeutige Referenz |
| Eingangsdatum und Quelle | Zeitpunkt, Kanal und Herkunft |
| Produkt/System | Vermutlich betroffene Komponente |
| Beschreibung | Technische Beobachtung und mögliche Auswirkung |
| Belege | Logs, Screenshots, Request/Response, Version oder reproduzierbarer Hinweis |
| Vertraulichkeit | Schutz- und Weitergabebeschränkung |
| Erstzuweisung | Koordination und fachlicher Owner |
| Erstreaktion | Bestätigung, Rückfrage, Eindämmung oder Eskalation |
Jeder relevante Befund wird im führenden Register oder Ticketsystem nachvollziehbar geführt.
| Feld | Mindestinhalt |
|---|---|
| Schwachstellen-ID | Interne eindeutige Kennung |
| Externe Referenz | CVE, Advisory, Test- oder Auditreferenz |
| Quelle und Datum | Herkunft und Zeitpunkt |
| Produkt und Version | Betroffene technische Komponente |
| Asset-/Service-ID | Verbindung zu Inventar und Geschäftsdienst |
| Owner | Fachlich und technisch verantwortliche Rolle |
| Exposition | Internet, Partnernetz, intern, segmentiert oder isoliert |
| technische Bewertung | CVSS-Version, Score und Vektor, soweit verfügbar |
| Bedrohungslage | aktive Ausnutzung, Exploitverfügbarkeit und Angriffsaktivität |
| Auswirkung | Vertraulichkeit, Integrität, Verfügbarkeit, Sicherheit und Geschäft |
| interne Priorität | V1 bis V5 mit Begründung |
| Behandlung | Patch, Mitigation, Ersatz, Außerbetriebnahme oder Ausnahme |
| Frist | Genehmigter Zieltermin und gegebenenfalls Zwischenfristen |
| Change-/Incident-Referenz | Verknüpfte Bearbeitung |
| Prüfung | Test, Rescan oder andere Verifikation |
| Restrisiko | Bewertung und Genehmigung |
| Status | Neu, in Prüfung, geplant, in Umsetzung, verifiziert oder geschlossen |
| Nachweise | Ablageorte und verantwortliche Bestätigung |
| Schwachstellen-ID | Asset/Service | Quelle | Betroffenheit | Priorität | Behandlung | Frist | Status | Nachweis |
|---|---|---|---|---|---|---|---|---|
| VM-2026-001 | Noch zu erfassen | Beispiel-Advisory | Nicht geprüft | Nicht bewertet | Noch festzulegen | Nicht freigegeben | Neu | Nicht vorhanden |
Der Beispieleintrag ist kein realer Befund und kein Nachweis einer durchgeführten Prüfung.
Je nach Technologie und Risiko können eingesetzt werden:
Ein Scan gilt nur für die im Bericht nachweisbar erreichten Systeme, Ports, Konten, Prüftiefen und Zeitpunkte. Fehlgeschlagene Authentisierung, ausgeschlossene Netze, ausgeschaltete Geräte und abgebrochene Prüfungen werden als Abdeckungslücke ausgewiesen.
Vor technischen Prüfungen werden geklärt:
Produktive OT- oder Legacy-Systeme werden nicht ungeprüft mit aktiven oder belastenden Methoden gescannt. Herstellerbedingungen, passive Verfahren, Testumgebungen und alternative Nachweise werden berücksichtigt.
Für jede Meldung wird ermittelt:
Eine nicht gelungene Zuordnung wird nicht als „nicht betroffen“ geschlossen, sondern als Inventar- oder Abklärungslücke eskaliert.
Ein Befund darf als False Positive oder „nicht betroffen“ bewertet werden, wenn die Begründung reproduzierbar und prüfbar ist, beispielsweise durch:
Nicht ausreichend sind allein:
| Validierungsfeld | Dokumentation |
|---|---|
| Prüfer/in und Datum | Wer hat wann geprüft? |
| Asset, Version und Konfiguration | Was wurde konkret geprüft? |
| Prüfmethode | Wie wurde die Aussage validiert? |
| Ergebnis | Betroffen, nicht betroffen, unklar oder False Positive |
| Begründung | Technische und risikobezogene Herleitung |
| Gegenprüfung | Zweite Rolle oder automatisierter Kontrollnachweis bei kritischen Fällen |
| Wiedervorlage | Erforderlich bei vorläufiger oder zeitabhängiger Aussage |
Die interne Bewertung berücksichtigt mindestens:
| Faktor | Leitfrage |
|---|---|
| technische Schwere | Welche technischen Auswirkungen und Angriffsbedingungen beschreibt der CVSS-Vektor oder die Herstelleranalyse? |
| aktive Ausnutzung | Wird die Schwachstelle nachweislich oder glaubhaft in realen Angriffen verwendet? |
| Exploitverfügbarkeit | Existiert öffentliches, leicht nutzbares oder automatisierbares Angriffswerkzeug? |
| Exposition | Ist das System direkt oder indirekt aus dem Internet, Partnernetz oder anderen Vertrauenszonen erreichbar? |
| Berechtigungswirkung | Ermöglicht der Angriff privilegierten Zugriff, Identitätsmissbrauch oder Kontrollumgehung? |
| Assetkritikalität | Welche Schutzbedarfe, Prozesse, Kunden und Wiederanlaufziele sind betroffen? |
| Angriffskette | Erleichtert die Schwachstelle laterale Bewegung oder die Kombination mit anderen Lücken? |
| vorhandene Maßnahmen | Sind Segmentierung, MFA, EDR, WAF, Härtung oder Überwachung tatsächlich wirksam? |
| Patch-/Mitigationslage | Gibt es eine belastbare Korrektur, Workaround oder sichere Abschaltung? |
| Sicherheits- und Produktionswirkung | Kann Behandlung die physische Sicherheit, Qualität oder Anlagenverfügbarkeit gefährden? |
| Kunden-, Vertrags- und Rechtsanforderung | Gibt es kürzere Fristen, Meldewege oder besondere Genehmigungen? |
| Unsicherheit | Wie belastbar sind Asset-, Versions-, Expositions- und Bedrohungsdaten? |
CVSS wird mit Versionsangabe und möglichst vollständigem Vektor dokumentiert. Bei CVSS 4.0 werden neben dem Base Score soweit verfügbar Bedrohungs- und Umgebungsfaktoren einbezogen. Ein fremder Score wird nicht ungeprüft als organisationsspezifisches Risiko übernommen.
Die folgende Klassifizierung ist ein anpassbarer interner Entwurf:
| Klasse | Typische Kriterien | Reaktionsziel | Behandlungsziel im Entwurf |
|---|---|---|---|
| V1 Akut | aktive Ausnutzung oder glaubhafte unmittelbare Gefährdung eines exponierten/kritischen Systems | unverzüglich; Eindämmung möglichst am selben Arbeitstag | dauerhafte Behandlung nach dokumentierter Notfallentscheidung, fortlaufend überwacht |
| V2 Kritisch | sehr hohe Auswirkung, hohe Exposition, privilegierter Angriff oder kurzfristig nutzbarer Exploit | innerhalb eines Arbeitstags bewerten und Owner zuweisen | grundsätzlich innerhalb 7 Kalendertagen |
| V3 Hoch | erhebliche Auswirkung oder wahrscheinliche Ausnutzung bei relevanter Exposition | innerhalb 3 Arbeitstagen bewerten | grundsätzlich innerhalb 30 Kalendertagen |
| V4 Mittel | begrenzte Auswirkung, erschwerte Ausnutzung oder wirksame Schutzbarrieren | im regulären Triagezyklus | grundsätzlich innerhalb 90 Kalendertagen |
| V5 Niedrig | geringe konkrete Gefährdung oder nur unter besonderen Bedingungen relevant | geplant bewerten | im nächsten geeigneten Wartungs-/Releasezyklus |
Wichtiger Statushinweis: Diese Fristen sind fiktive interne Entwurfswerte und weder von der Muster GmbH freigegeben noch pauschale Fristen aus ISO/IEC 27001 oder TISAX. Reale Fristen müssen anhand von Risiko, Betriebsmodell, Kunden- und Vertragsanforderungen beschlossen werden. Eine niedrigere Priorität trotz aktiver Ausnutzung oder kritischer Exposition bedarf besonderer Begründung und Genehmigung.
Kürzere externe oder vertragliche Fristen gehen vor. Kann ein Ziel nicht eingehalten werden, beginnt vor Fristablauf das Ausnahme- und Eskalationsverfahren.
| Entscheidungsfeld | Eintrag |
|---|---|
| Schwachstellen-ID | [VM-...] |
| Asset-/Servicekritikalität | [Bewertung und Quelle] |
| CVSS | [Version, Score, Vektor] |
| aktive Ausnutzung/KEV | [Ja/Nein/Unklar, Quelle, Datum] |
| Exposition | [Internet/Partner/intern/isoliert] |
| mögliche Auswirkung | [Schutzwerte, Geschäft, Sicherheit] |
| vorhandene Kontrollen | [Kontrolle und geprüfte Wirksamkeit] |
| interne Priorität | [V1 bis V5] |
| Begründung | [Nachvollziehbare Herleitung] |
| Reaktions- und Behandlungsfrist | [Datum/Uhrzeit] |
| Entscheider/in | [Rolle] |
| nächste Neubewertung | [Datum oder Ereignis] |
In bevorzugter Reihenfolge werden geprüft:
Kompensierende Maßnahmen gelten nur, wenn:
Der reguläre Patchzyklus umfasst:
| Patchzyklus-Feld | Festlegung |
|---|---|
| Standardzyklus | Noch festzulegen |
| Kritische Systeme | Gesonderte risikobasierte Planung erforderlich |
| Wartungsfenster | Je Service zu bestätigen |
| Testgruppen/Pilotierung | Noch zu definieren |
| Abbruchkriterien | Noch zu definieren |
| Rückfallzeit und Verantwortliche | Je Change zu bestätigen |
| Erfolgskontrolle | Technischer Patchstand, Funktion und erneuter Schwachstellenabgleich |
Bei V1-Befunden oder Zero-Day-Lagen werden mindestens bewertet:
Ein Notfallpatch darf mit verkürztem Test umgesetzt werden, wenn:
Bei Kompromittierungsverdacht wird unverzüglich Incident Response aktiviert. Das Einspielen eines Patches beseitigt mögliche Angreiferspuren oder bereits erfolgte Manipulationen nicht.
Die Testtiefe richtet sich nach:
| Prüfaspekt | Erwarteter Nachweis |
|---|---|
| Paketquelle und Integrität | Herstellerquelle, Signatur, Hash oder vertrauenswürdiges Repository |
| Installierbarkeit | erfolgreiches Testprotokoll oder dokumentierte Herstellerfreigabe |
| Funktion | definierte technische und fachliche Abnahmekriterien |
| Sicherheit | Schwachstelle nicht mehr ausnutzbar beziehungsweise wirksam kompensiert |
| Schnittstellen | kritische Datenflüsse und Abhängigkeiten funktionieren |
| Leistung/Verfügbarkeit | keine unakzeptable Verschlechterung |
| Backup/Rückfall | Wiederherstellbarkeit und Abbruchweg nachvollziehbar |
| Monitoring | neue Version und relevante Ereignisse werden korrekt überwacht |
Eine Herstellerfreigabe kann die interne Prüfung unterstützen, ersetzt aber nicht automatisch die organisationsbezogene Risiko-, Funktions- und Betriebsbewertung.
Jede produktive Patch- oder Mitigationsmaßnahme wird angemessen über IT-Betrieb und Änderungen gesteuert.
Der Rollout berücksichtigt:
Massenrollouts werden so gesteuert, dass ein fehlerhafter Patch nicht unkontrolliert alle kritischen Systeme gleichzeitig beeinträchtigt.
Ein Befund wird erst geschlossen, wenn:
| Abschlussstatus | Bedeutung |
|---|---|
| Verifiziert behoben | Dauerhafte Maßnahme technisch und risikobezogen geprüft |
| Wirksam mitigiert | Ursache besteht, aber genehmigte Schutzmaßnahme reduziert das Risiko nachweisbar |
| Nicht betroffen | Technisch nachvollziehbar validiert |
| False Positive | Erkennungsfehler reproduzierbar bestätigt |
| Risiko akzeptiert | Befristete, autorisierte Risikoentscheidung mit Überwachung |
| Außer Betrieb | Asset nachweisbar entfernt, Zugänge und Daten sicher behandelt |
| Offen | Behandlung oder Wirksamkeitsprüfung noch nicht abgeschlossen |
Ein geschlossenes Ticket ohne technischen Soll-/Ist-Abgleich gilt nicht als ausreichender Abschlussnachweis.
Kann eine Schwachstelle nicht fristgerecht behandelt werden, wird vor Ablauf der Frist Ausnahmen und Risikoakzeptanzen angewendet.
Mindestens erforderlich sind:
V1- oder aktiv ausgenutzte Schwachstellen werden nicht allein aus Bequemlichkeit oder wegen eines fehlenden Wartungsfensters akzeptiert. Fortgesetzter Betrieb bedarf einer besonders belastbaren und hochrangigen Entscheidung.
| Eskalationsanlass | Mindestreaktion |
|---|---|
| V1-Befund oder Kompromittierungsverdacht | unverzügliche technische und Managementeskalation; Incident-Prüfung |
| drohende Fristüberschreitung | Owner, IT-Leitung und Informationssicherheit informieren; Ausnahme entscheiden |
| Frist überschritten | als Abweichung ausweisen; Risiko und kompensierende Maßnahmen neu bewerten |
| Asset oder Owner unbekannt | Inventar- und Verantwortlichkeitslücke eskalieren |
| Patch schlägt fehl | Eindämmung, Rückfall, Fehleranalyse und neue Planung |
| wiederkehrende Schwachstelle | Ursache, Baseline, Deployment und Prozesswirksamkeit prüfen |
| Lieferant reagiert nicht | Vertrags-, Exit-, Ersatz- und Risikoeskalation |
| Abdeckung unvollständig | Kennzahl nicht beschönigen; fehlende Systeme und Ursache offen ausweisen |
Überfällige Schwachstellen werden nicht durch Verschieben des Erfassungsdatums oder Eröffnen eines neuen Tickets verjüngt.
Für OT, Produktionsanlagen und nicht mehr regulär unterstützte Systeme gelten zusätzlich:
Eine Herstellerempfehlung, einen Patch nicht einzuspielen, beendet die Risikobehandlung nicht. Sie löst die Bewertung alternativer Schutzmaßnahmen, Einsatzbeschränkung, Ersatz oder Risikoentscheidung aus.
Für Komponenten ohne Sicherheitsunterstützung werden:
| EOL-Feld | Eintrag |
|---|---|
| Produkt/Version | Noch zu erfassen |
| betroffene Assets/Dienste | Noch zu erfassen |
| Supportende | Nicht bestätigt |
| Risiko/Exposition | Nicht bewertet |
| Übergangsmaßnahmen | Nicht festgelegt |
| Ablöseplan und Termin | Nicht freigegeben |
| Risikoentscheidung | Ausstehend |
Bei extern betriebenen Diensten wird geklärt:
Eine vertragliche Zuständigkeit des Anbieters entbindet den Service Owner nicht von Überwachung, Bewertung und angemessener Eskalation.
Für selbst entwickelte oder angepasste Software werden zusätzlich berücksichtigt:
Das bloße Aktualisieren einer Bibliotheksdatei im Repository belegt nicht, dass das korrigierte Artefakt gebaut, ausgeliefert und produktiv eingesetzt wurde.
Der vollständige Entwicklungs-, Build-, Test- und Releaseprozess wird in Sichere Entwicklung gesteuert.
Für sicherheitsrelevante Produkte und Leistungen werden risikobasiert vereinbart:
Die Steuerung erfolgt gemeinsam mit Lieferanten und Dienstleister.
Penetrationstests werden:
Ein Penetrationstest ersetzt weder kontinuierliche Schwachstellenbeobachtung noch Patchmanagement. Ein „bestanden“ gilt nur für geprüften Scope, Zeitpunkt und Prüftiefe.
Schwachstelleninformationen werden nach Informationsklassifizierung geschützt. Besonders zu begrenzen sind:
Zugriff erhalten nur Rollen mit berechtigtem Bedarf. Übermittlung, Export, Aufbewahrung und Löschung werden nachvollziehbar geregelt.
Eine Schwachstelle wird als möglicher Sicherheitsvorfall eskaliert, wenn beispielsweise:
Es gelten Meldeweg für Sicherheitsvorfälle und Incident Response.
Schwachstellenbehebung und Incident-Behandlung werden getrennt, aber miteinander verknüpft dokumentiert: Patchen schließt die Ursache, Incident Response klärt unter anderem Ausnutzung, Umfang, Beweise, Eindämmung, Wiederherstellung und Meldebedarf.
Schwachstellen werden in das Risikoregister beziehungsweise den Risikobehandlungsplan überführt, wenn:
Das Beispielrisiko RIS-2026-010 und die Beispielmaßnahme M-010 bleiben offen, bis Scanabdeckung, Priorisierung, Fristüberwachung, Behandlung und Wirksamkeit objektiv nachgewiesen sind.
Mindestens aufbewahrt werden, soweit relevant:
Aufbewahrungsfrist, Zugriff und Löschung richten sich nach Dokumentenlenkung, Rechts-/Vertragskataster, Datenschutz, Vorfallbeweissicherung und Kundenanforderungen.
Kennzahlen werden nur mit nachvollziehbarem Scope und belastbaren Quelldaten berichtet:
| Kennzahl | Berechnung/Interpretation |
|---|---|
| Asset-Inventarabdeckung | Assets mit ausreichenden Produkt-/Versionsdaten / relevante Assets im bestätigten Scope |
| Scanabdeckung | erfolgreich und mit vorgesehener Prüftiefe gescannte Assets / scanpflichtige Assets |
| Patchwerkzeug-Abdeckung | verwaltete Assets / hierfür vorgesehene Assets |
| offene V1/V2-Befunde | Anzahl nach validierter interner Priorität |
| fristgerechte Behandlung | innerhalb genehmigter Frist verifiziert behandelte Befunde / fällige Befunde |
| überfällige Befunde | offene Befunde nach Behandlungsfrist, getrennt nach Klasse und Alter |
| mittlere Behandlungszeit | Zeit vom validierten Eingang bis zur verifizierten Behandlung |
| Ausnahmequote | offene befristete Ausnahmen / offene relevante Befunde |
| Wiederholungsbefunde | erneut auftretende gleiche Ursache oder Schwachstelle |
| Verifikationsquote | behandelte Befunde mit erfolgreicher unabhängiger oder technischer Wirksamkeitsprüfung |
| EOL-Bestand | Assets mit abgelaufenem Support und ohne abgeschlossene Ablösung |
| Kennzahl | Stand Entwurf |
|---|---|
| bestätigte Assets im Nenner | Nicht vollständig erfasst |
| Scanabdeckung | Nicht berechenbar |
| Patchwerkzeug-Abdeckung | Nicht berechenbar |
| offene Schwachstellen nach Klasse | Nicht vollständig erhoben |
| fristgerechte Behandlung | Nicht berechenbar |
| überfällige Befunde | Nicht vollständig erhoben |
| verifizierte Behandlung | Nicht berechenbar |
| EOL-Bestand | Nicht vollständig erhoben |
Eine Quote von 100 Prozent ist unzulässig, wenn fehlende, nicht erreichbare oder nicht inventarisierte Systeme aus dem Nenner entfernt wurden, ohne dies offenzulegen.
Die IT-Leitung berichtet risikobasiert an die zuständigen Steuerungsrollen:
Die Berichte fließen in Kennzahlen und Zielerreichung und die Managementbewertung ein.
Geeignete Wirksamkeitsnachweise sind beispielsweise:
Nicht ausreichend sind allein:
Prozess- und Umsetzungsfehler werden über Abweichungen und Korrekturmaßnahmen behandelt.
Mögliche systemische Abweichungen sind:
Ursache und ähnliche Bereiche werden mitgeprüft; die Korrektur eines einzelnen Tickets allein schließt eine systemische Abweichung nicht.
Diese Seite unterstützt insbesondere die Steuerung technischer Schwachstellen, Patchstände, sichere Änderungen, Betriebssicherheit, externe Dienste und Nachweise.
Für TISAX gilt:
| TISAX-Prüfaspekt | Nachweisstatus |
|---|---|
| relevante Kontrollfragen einzeln bewertet | Nein; Kapitel 5.2: 0 von 9 |
| Schwachstellenquellen und Verantwortungen bestätigt | Nicht vollständig |
| Asset- und Scanabdeckung belegt | Nein |
| Priorisierung und Fristen freigegeben | Nein |
| Patches und Ausnahmen nachweisbar gesteuert | Nicht bestätigt |
| Wirksamkeit anhand von Stichproben belegt | Nein |
| Gesamtumfang Informationssicherheit | 0 von 46 Fragen bewertet |
Die Regelung unterstützt insbesondere Annex A 8.8 „Management technischer Schwachstellen“ sowie verbundene Controls zu Bedrohungsinformationen, Lieferanten, Konfiguration, Softwareinstallation und Änderungen.
Die Statement of Applicability dokumentiert die Anwendbarkeit der Annex-A-Controls mit Begründung und Umsetzungsstatus. Sie ersetzt weder das Schwachstellenregister noch den operativen Prozess.
Die SoA-Logik wird nicht auf TISAX-Informationssicherheitsfragen übertragen:
| Nachweis | Mindestanforderung | Status |
|---|---|---|
| bestätigter Asset-/Versionsbestand | Scope, Owner, Kritikalität, Produkt und Version | Nicht vollständig |
| Quellenregister | Hersteller, CERT, KEV, Werkzeuge, Zuständigkeit und Intervall | Nicht vorhanden |
| Scan- und Prüfplan | Scope, Methode, Frequenz, Autorisierung und Sicherheit | Nicht freigegeben |
| Schwachstellenregister | Befund, Asset, Bewertung, Frist, Behandlung und Status | Nicht vollständig |
| Priorisierungsentscheidung | CVSS, Bedrohung, Exposition, Auswirkung und Begründung | Nicht nachgewiesen |
| Patch-/Change-Nachweise | Quelle, Test, Freigabe, Rollout und Rückfall | Keine geprüfte Stichprobe |
| Ausnahmen | Risiko, Kompensationen, Genehmigung und Ablauf | Nicht vollständig erhoben |
| Verifikation | Rescan oder gleichwertiger technischer Wirksamkeitsnachweis | Nicht nachgewiesen |
| Kennzahlen | nachvollziehbarer Scope, Zähler, Nenner und Datenstand | Nicht berechenbar |
| TISAX-Bewertung | einzelne Kontrollfragen mit Reifegrad und Evidenz | 0 von 46 bewertet |
Schwachstellen- und Patchmanagement wird risikobasiert über das Auditprogramm und Interne Audits geprüft.
Geeignete Stichproben sind:
Ein positives Auditergebnis gilt nur für den dokumentierten Scope, Zeitraum und die geprüfte Stichprobe.
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| realen Asset-, Produkt- und Versionsbestand vervollständigen | IT-/OT-Betrieb / Asset Owner | Offen |
| Internet-, Partner-, OT- und kritische Exposition erfassen | IT-Sicherheit / Netzwerk / Produktion | Offen |
| Quellenregister und Vertretung festlegen | Vulnerability-Koordination | Offen |
| Scanarten, Frequenzen, Scope und sichere Durchführung freigeben | IT-Sicherheit / IT-/OT-Betrieb | Offen |
| Schwachstellenregister und eindeutige Statuslogik einrichten | IT-Leitung | Offen |
| interne Prioritätsklassen und Fristen genehmigen | Geschäftsführung / IT / ISMS | Offen |
| regulären Patchzyklus und Wartungsfenster bestätigen | IT-/OT-Betrieb / Service Owner | Offen |
| Notfallpatch- und Zero-Day-Verfahren erproben | IT / Incident / BCM | Offen |
| Test-, Rollout-, Rückfall- und Verifikationsnachweise operationalisieren | IT / Entwicklung | Offen |
| OT-, Legacy- und EOL-Bestand mit Ablöseplan erfassen | Produktion / IT / Einkauf | Offen |
| Cloud- und Lieferantenverantwortungen vertraglich bestätigen | Einkauf / Service Owner | Offen |
| Ausnahmenbestand und Ablaufkontrolle einrichten | ISMS / Risikoeigentümer | Offen |
| Kennzahlen mit belastbarem Nenner einführen | IT-Leitung / ISMS | Offen |
| RIS-2026-010 und M-010 mit realen Nachweisen bearbeiten | IT-Leitung | Offen |
| Kapitel 5.2 kontrollfragenbezogen bewerten | TISAX / IT / ISMS | Offen |
| Erstprüfung und Wirksamkeitsstichprobe durchführen | Interne Audits | Offen |
| Prüffrage | Status Entwurf |
|---|---|
| Sind alle relevanten Assets, Produkte, Versionen und Owner bekannt? | Nein |
| Ist die tatsächliche Scanabdeckung messbar? | Nein |
| Werden Hersteller-, CERT- und KEV-Informationen nach festem Verfahren verarbeitet? | Nicht nachgewiesen |
| Werden Betroffenheit und False Positives reproduzierbar validiert? | Keine Stichprobe vorhanden |
| Ergänzt die interne Bewertung den CVSS-Wert um Bedrohung, Exposition und Auswirkung? | Als Soll beschrieben; nicht belegt |
| Sind Prioritäten und Behandlungsfristen freigegeben? | Nein; nur Entwurfswerte |
| Sind Patchquelle, Test, Freigabe, Rollout und Rückfall nachvollziehbar? | Keine vollständige Stichprobe |
| Werden fehlgeschlagene und nicht erreichte Assets weiterverfolgt? | Nicht nachgewiesen |
| Sind Ausnahmen befristet und kompensierende Maßnahmen getestet? | Nicht vollständig erhoben |
| Wird die technische Wirksamkeit vor Abschluss geprüft? | Nicht nachgewiesen |
| Sind OT, Cloud, Entwicklung und Lieferanten einbezogen? | Teilweise als Soll beschrieben |
| Werden Scope und Nenner der Kennzahlen offengelegt? | Kennzahlen noch nicht berechenbar |
| Sind alle neun Kontrollfragen aus Kapitel 5.2 bewertet? | Nein; 0 von 9 |
| Sind alle 46 Informationssicherheitsfragen berücksichtigt? | Ja als Sollumfang; 0 von 46 bewertet |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Regelung für Quellen, Erkennung, Priorisierung, Patchsteuerung, Ausnahmen und Wirksamkeitsprüfung angelegt | IT-Leitung / ISMS | Ausstehend | – |
| Funktion | Name | Entscheidung | Datum |
|---|---|---|---|
| Geschäftsführung | – | Ausstehend | – |
| IT-Leitung | – | Fachliche Prüfung ausstehend | – |
| OT-/Produktionsverantwortliche/r | – | Schnittstellenprüfung ausstehend | – |
| ISMS-Beauftragte/r | – | Prüfung ausstehend | – |
| Entwicklung/Service Owner | – | Anwendungs- und Betriebsprüfung ausstehend | – |
Maßgeblich bleiben die lizenzierten Normtexte, die für das konkrete Assessment gültige offizielle ISA-Arbeitsmappe, der bestätigte TISAX Assessment Scope sowie die freigegebenen Rechts-, Vertrags-, Kunden-, Betriebs-, Hersteller- und Sicherheitsanforderungen.