Beispieldokument: Diese Regelung beschreibt den Sollprozess für die fiktive „Muster GmbH“. Reale Systeme, Konfigurationsbaselines, Betriebsverfahren, Wartungsfenster, Changes, Freigaben, Tests, Rückfallnachweise, Protokolle und Wirksamkeitsnachweise sind noch nicht vollständig erfasst oder bestätigt. Die Seite allein belegt keinen sicheren oder stabilen IT-/OT-Betrieb.
Nachweisregel: Ein Change-Ticket, eine Herstellerfreigabe oder der Status „erfolgreich“ belegt nicht automatisch, dass eine Änderung vollständig getestet, sicher umgesetzt und wirksam ist. Scope, Genehmigung, Test, Implementierung, Rückfall und Ergebnis müssen nachvollziehbar sein.
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.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-04 |
| Dokumentenart | Regelung / IT-/OT-Betrieb und technische Änderungen |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/IT-Betrieb-und-Aenderungen |
| Verantwortlich | IT-Leitung |
| Fachlich geprüft durch | ISMS-Beauftragte/r, IT-/OT-Betrieb, Entwicklung, BCM und betroffene Service Owner |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Betriebs- und Changenachweise 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 Detail- und Sicherheitsunterlagen Vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.37, A 7.13, A 8.1, A 8.6, A 8.7, A 8.9, A 8.19 und A 8.32 |
| VDA-ISA-Bezug | ISA 6.0.3, Kapitel 5.2 Betriebssicherheit |
Diese Regelung legt fest, wie IT-, OT- und informationsverarbeitende Dienste sicher, stabil, nachvollziehbar und kontrolliert betrieben und geändert werden.
Sie soll insbesondere sicherstellen, dass:
Die Regelung gilt für:
Der konkrete Betriebsumfang wird mit Geltungsbereich und Standorte, Asset-Inventar und der Prozesslandkarte abgeglichen.
| Ziel | Betriebsbeitrag |
|---|---|
| Vertraulichkeit | Berechtigter, kontrollierter Zugriff und Schutz technischer Daten |
| Integrität | Freigegebene Konfigurationen, kontrollierte Änderungen und nachvollziehbare Verarbeitung |
| Verfügbarkeit | Kapazität, Wartung, Redundanz, Wiederherstellung und Störungsbehandlung |
| Authentizität | Vertrauenswürdige Software, Systeme, Quellen und administrative Identitäten |
| Nachvollziehbarkeit | Dokumentierte Entscheidungen, Changes, Protokolle und Übergaben |
| Sicherheit | Härtung, Schadsoftwareschutz, Schwachstellenbehandlung und Überwachung |
| Betriebsfähigkeit | Geordnete Verfahren, Vertretung, Notfallbetrieb und Rückfall |
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Ressourcen, wesentliche Betriebsrisiken, Ausnahmen und Eskalationen entscheiden |
| IT-Leitung | Betriebsmodell, Verfahren, Rollen, Werkzeuge und Kontrollen verantworten |
| OT-/Produktionsverantwortliche/r | Betriebssicherheit, Anlagenverfügbarkeit und Produktionsfenster koordinieren |
| Service Owner | Leistung, Kritikalität, Anforderungen, Abhängigkeiten und Änderungsgenehmigung verantworten |
| System-/Application Owner | Systembaselines, Lebenszyklus, technische Änderungen und Nachweise steuern |
| Change Owner | Änderung planen, Risiken bewerten, Beteiligte koordinieren und Abschluss nachweisen |
| Change Manager/koordinierende Rolle | Verfahren, Kalender, Gremien, Status und Qualität überwachen |
| Administration/Betrieb | Freigegebene Tätigkeiten umsetzen und Ergebnisse dokumentieren |
| Entwicklung | Änderungen, Pakete, Tests und technische Dokumentation bereitstellen |
| Informationssicherheitsfunktion | Sicherheitsauswirkungen, Ausnahmen, Kontrollen und Nachweise prüfen |
| BCM/Notfallmanagement | Kritische Abhängigkeiten, Rückfall, Wiederanlauf und Notfalländerungen abstimmen |
| Datenschutz | Auswirkungen auf personenbezogene Daten und Überwachung beraten |
| Einkauf/Lieferantenmanagement | Externe Betriebs- und Änderungsleistungen vertraglich steuern |
| Anwendervertretung/Fachbereich | Geschäftsanforderung, Abnahmekriterien und Funktionsprüfung bestätigen |
| Prüfer/in | Stichproben und Wirksamkeit angemessen unabhängig prüfen |
Die technische Umsetzung einer Änderung und ihre fachliche oder sicherheitsbezogene Freigabe werden bei kritischen Änderungen angemessen getrennt.
Für jeden relevanten Dienst werden mindestens geführt:
| Feld | Mindestinhalt |
|---|---|
| Service-ID und Titel | Eindeutige Referenz |
| Service Owner | Verantwortliche Rolle |
| Technische Owner | Systeme, Anwendungen und Plattformen |
| Kritikalität | Schutzbedarf und Geschäftsrelevanz |
| Nutzer/Kunden | Interne und externe Leistungsbezieher |
| Komponenten | Assets, Software, Datenbanken und Netzwerke |
| Abhängigkeiten | Identität, DNS, Zeit, Netzwerk, Cloud, Lieferanten und Versorgung |
| Betriebszeiten | Servicezeit, Supportzeit und Wartungsfenster |
| Betriebsverfahren | Eindeutige Dokumentenreferenzen |
| Überwachung | Kennzahlen, Schwellen und Alarmwege |
| Backup/Recovery | Sicherung, RTO/RPO und Wiederanlaufreferenzen |
| Änderungen | Zuständige Change-Klasse und Genehmigungsweg |
| Lebenszyklus | Einführung, Betrieb, Ablösung und Ende |
| Service-ID | Dienst | Kritikalität | Owner | Betriebsstatus | Verfahren | Monitoring | Letzter Review |
|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch zu bewerten | Noch zu benennen | Nicht bestätigt | Nicht vorgelegt | Nicht bestätigt | Nicht durchgeführt |
Betriebsverfahren werden für kritische und wiederkehrende Tätigkeiten erstellt, beispielsweise:
| Verfahrensfeld | Mindestinhalt |
|---|---|
| Zweck und Scope | Systeme, Tätigkeiten und Grenzen |
| Voraussetzungen | Zugriffe, Werkzeuge, Wartungsfenster und Abhängigkeiten |
| Verantwortliche Rollen | Durchführung, Freigabe, Kontrolle und Vertretung |
| Arbeitsschritte | Eindeutige, prüfbare Reihenfolge |
| Sicherheitskontrollen | Schutz, Funktionstrennung und Protokollierung |
| Fehlerfälle | Abbruch, Eskalation und Rückfall |
| Ergebnis/Nachweis | Erwartetes Ergebnis und Ablage |
| Version/Freigabe | Gültiger Stand und Owner |
Neue oder wesentlich geänderte Systeme werden erst in den Regelbetrieb übernommen, wenn:
| Übergabefeld | Status |
|---|---|
| Service-/Assetregister vollständig | Nicht geprüft |
| Sicherheits- und Konfigurationsbaseline | Nicht geprüft |
| Betriebsverfahren | Nicht vorgelegt |
| Monitoring und Alarmierung | Nicht bestätigt |
| Backup und Recovery | Nicht getestet |
| Support und Eskalation | Nicht bestätigt |
| Offene Risiken und Ausnahmen | Nicht vollständig erfasst |
| Betriebsfreigabe | Ausstehend |
Wenn Betriebszeiten, Kritikalität oder Schichtmodelle dies erfordern, werden geregelt:
Kontakt- und Rufbereitschaftsdaten werden geschützt und regelmäßig getestet.
Konfigurationen werden über ihren Lebenszyklus gesteuert:
| Konfigurationselement | System/Service | Owner | Baseline | Iststand | Abweichung | Letzte Prüfung | Status |
|---|---|---|---|---|---|---|---|
| Noch zu erfassen | Noch zu erfassen | Noch zu benennen | Nicht freigegeben | Nicht erhoben | Nicht bewertet | Nicht durchgeführt | Offen |
Baselines berücksichtigen risikobasiert:
Baselines erhalten Version, Scope, Owner, Quelle, Ausnahmen, Test und Freigabe.
Konfigurationsabweichungen werden:
Eine bekannte Abweichung wird nicht allein durch Dokumentation zum akzeptierten Zustand.
Für kritische Dienste werden:
| Kapazitätsobjekt | Messgröße | Schwelle | Datenquelle | Owner | Trend | Maßnahme | Status |
|---|---|---|---|---|---|---|---|
| Noch zu erfassen | Noch festzulegen | Nicht freigegeben | Noch zu bestimmen | Noch zu benennen | Nicht erhoben | Noch zu bewerten | Offen |
Ein Dashboard ohne freigegebene Schwellen und Reaktionsprozess gilt nicht als wirksame Kapazitätssteuerung.
Schadsoftware wird durch mehrschichtige Maßnahmen verhindert, erkannt und behandelt:
Für technisch eingeschränkte OT- oder Altsysteme werden Risiken und kompensierende Kontrollen dokumentiert.
Software wird auf produktiven Systemen nur installiert, wenn:
Unkontrollierte Paketquellen, private Software und ungeprüfte Administrationswerkzeuge sind nicht zulässig.
Werkzeuge, die Kontrollen umgehen, Systeme verändern oder besonders weitreichend zugreifen können, werden:
Die Berechtigungssteuerung erfolgt über Zugriff und Berechtigungen.
Der Betrieb:
Die vertiefte Steuerung erfolgt in Schwachstellen- und Patchmanagement. Bis zur Freigabe beider Regelungen bleiben deren Inhalte Sollvorgaben ohne bestätigten Umsetzungs- oder Wirksamkeitsnachweis.
Der Betrieb stellt sicher, dass:
Die vertiefte Steuerung wird in Protokollierung und Überwachung geführt. Beide Seiten bleiben Entwürfe; der Verweis bestätigt weder Quellenabdeckung noch wirksame Alarmbearbeitung.
Für relevante Systeme und Informationen werden:
Die vertiefte Steuerung erfolgt in Datensicherung und Wiederherstellung sowie in der Wiederanlaufplanung. Bis zur Freigabe und praktischen Prüfung bleiben Sicherungs- und Wiederherstellungsangaben Sollvorgaben ohne bestätigten Wirksamkeitsnachweis.
Der Betrieb steuert:
Die vertiefte Steuerung wird in Netzwerke und Kommunikation geführt. Beide Seiten bleiben Entwürfe; der Verweis bestätigt keine tatsächliche Netzarchitektur oder wirksame Konfiguration.
Kryptografische Verfahren, Schlüssel, Zertifikate, Laufzeiten und Vertrauensanker werden nach Kryptografie und Schlüssel betrieben.
Auslaufende Zertifikate, fehlgeschlagene Erneuerungen oder kompromittierte Schlüssel werden als Betriebs- und Sicherheitsereignis behandelt.
Entwicklungs-, Test-, Abnahme- und Produktivumgebungen werden angemessen getrennt:
Produktivdaten werden nicht automatisch für Test- oder Entwicklungszwecke freigegeben.
Sicherheitsanforderungen, Entwicklungsumgebungen, Code-, Komponenten-, Build-, Test- und Releasekontrollen werden in Sichere Entwicklung vertieft.
Für OT- und produktionskritische Systeme werden zusätzlich berücksichtigt:
Produktionsdruck rechtfertigt keine undokumentierte Änderung.
Freigabe, Verantwortungsgrenzen, mobile Nutzung, kundenseitige Cloud-Konfiguration, Notbetrieb und Exit werden in Mobile Arbeit und Cloud vertieft.
Für externe Betriebsleistungen werden festgelegt:
Die Steuerung wird mit Lieferanten und Dienstleister abgestimmt.
Wartungen an IT-, OT- und Informationsverarbeitungseinrichtungen werden:
Physische Anforderungen werden mit Physische Sicherheit abgestimmt.
Automatisierte Verarbeitungen erhalten:
Fehlgeschlagene oder dauerhaft deaktivierte Jobs werden nicht ohne Bewertung ignoriert.
| Change-Art | Bedeutung | Mindeststeuerung |
|---|---|---|
| Standardänderung | Wiederholbar, risikoarm und vorab genehmigt | Freigegebenes Modell, dokumentierte Durchführung und regelmäßiger Review |
| Normale Änderung | Einzelfall mit regulärer Bewertung und Genehmigung | Vollständiger Antrag, Risiko, Test, Freigabe und Rückfall |
| Dringende Änderung | Verkürzte Planung wegen hoher Dringlichkeit | Begründung, beschleunigte Bewertung, befugte Freigabe und Nachprüfung |
| Notfalländerung | Sofortmaßnahme zur Gefahrenabwehr oder Wiederherstellung | Mindestdokumentation, Notfallfreigabe, Protokoll und zwingende Nachbearbeitung |
| Unautorisierte Änderung | Außerhalb des freigegebenen Verfahrens | Eindämmen, untersuchen, als Abweichung/Vorfall behandeln |
Eine häufig ausgeführte Änderung wird erst nach dokumentierter Bewertung und Freigabe zum Standard-Change.
| Feld | Mindestinhalt |
|---|---|
| Change-ID und Titel | Eindeutige Referenz |
| Antragsteller/in und Change Owner | Rollen und Verantwortung |
| Anlass und Ziel | Geschäfts-, Sicherheits- oder Betriebsbedarf |
| Betroffene Services/Assets | Vollständiger Scope |
| Change-Art und Priorität | Standard, normal, dringend oder Notfall |
| Beschreibung | Technische und organisatorische Änderung |
| Risiko und Auswirkung | Sicherheit, Betrieb, Daten, Kunde, Datenschutz und Compliance |
| Abhängigkeiten | Systeme, Lieferanten, Prozesse und parallele Changes |
| Testplan und Kriterien | Vorab festgelegte Soll- und Negativtests |
| Implementierungsplan | Schritte, Rollen und Zeitfenster |
| Rückfallplan | Auslöser, Schritte, Zeit und Verantwortung |
| Kommunikation | Betroffene, Support, Kunde und Management |
| Genehmigungen | Fachlich, technisch, Sicherheit und Betrieb |
| Nachprüfung | Ergebnis, Abweichungen und Wirksamkeit |
| Change-ID | Service/Asset | Art | Risiko | Termin | Owner | Freigabe | Ergebnis | Status |
|---|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch zu bestimmen | Noch zu bewerten | Noch festzulegen | Noch zu benennen | Ausstehend | Nicht durchgeführt | Entwurf |
Vor Freigabe werden mindestens bewertet:
Hohe Unsicherheit oder fehlende Testbarkeit wird als Risiko und nicht als positiver Befund dokumentiert.
Eine vertiefte Sicherheitsprüfung ist insbesondere erforderlich bei:
Die prüfende Rolle dokumentiert Anforderungen, Auflagen, offene Risiken und Entscheidung.
Tests werden vor Produktivsetzung soweit möglich in geeigneter Umgebung durchgeführt.
Mindestens werden geprüft:
| Test-ID | Change-ID | Testfall | Soll | Ist | Ergebnis | Abweichung | Freigabe |
|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zuzuordnen | Noch festzulegen | Noch festzulegen | Nicht getestet | Offen | Noch zu bewerten | Ausstehend |
Eine Herstellerbeschreibung oder erfolgreich gestartete Anwendung ersetzt keinen risikobasierten Test.
Der Rückfallplan enthält:
Ist ein Rückfall technisch nicht möglich, wird dies vor Freigabe als erhöhtes Risiko behandelt und eine alternative Wiederherstellung geplant.
Die Freigabe richtet sich nach Risiko und Kritikalität:
| Change-Klasse | Erforderliche Freigaben im Entwurf |
|---|---|
| Standardänderung | Vorab genehmigtes Modell und autorisierte Durchführung |
| Normale Änderung | Service/System Owner und fachlich verantwortliche Rolle |
| Sicherheitsrelevante Änderung | Zusätzlich Informationssicherheitsprüfung |
| Personenbezogene Daten | Zusätzlich Datenschutzprüfung nach Auswirkung |
| Kritischer Produktions-/OT-Change | Zusätzlich Produktions-/OT-Verantwortung |
| Externer/Kunden-Change | Vertraglich festgelegte interne oder externe Zustimmung |
| Notfalländerung | Befugte Notfallrolle; nachgelagerte reguläre Prüfung |
Umsetzende Personen genehmigen eigene kritische Changes nicht allein.
Geplante Änderungen werden in einem gemeinsamen Kalender koordiniert. Berücksichtigt werden:
Konflikte werden vor Umsetzung entschieden und dokumentiert.
Während der Umsetzung werden:
Eine wesentliche Abweichung vom Plan führt zur Unterbrechung, erneuten Bewertung oder Notfallentscheidung.
Nach Umsetzung werden:
Der Status „Abgeschlossen“ wird erst nach nachvollziehbarer Validierung vergeben.
Ein vertiefter Review wird insbesondere durchgeführt bei:
Der Review bewertet Planung, Risiko, Test, Umsetzung, Wirkung, Rückfall, Kommunikation und Verbesserungsbedarf.
Bei unmittelbarer Gefährdung von Personen, Informationen oder Betrieb darf das Verfahren verkürzt werden.
Mindestens werden dokumentiert:
Eine Notfalländerung wird nicht dauerhaft ohne nachgelagerte Lenkung betrieben.
Unautorisierte Änderungen werden:
Eine nachträgliche Ticketerstellung macht eine unautorisierte Änderung nicht automatisch ordnungsgemäß.
Lieferantenänderungen werden so gesteuert, dass:
Änderungen im Incident-, Krisen- oder Recoverybetrieb werden:
Die Abstimmung erfolgt mit Incident Response und Notfallvorsorge und BCM.
Vor Außerbetriebnahme werden:
Abweichungen von Betriebs- oder Changevorgaben werden über Ausnahmen und Risikoakzeptanzen gesteuert.
Mindestens erforderlich sind:
Eine fehlende Wartungsmöglichkeit, ein Altsystem oder Produktionsbedarf führt nicht automatisch zu einer unbefristeten Ausnahme.
| ISA-Kapitel | Themengebiet | Kontrollfragen ISA 6.0.3 | Inhalt dieser Regelung | Status |
|---|---|---|---|---|
| 5.2 | Betriebssicherheit | 9 | Betriebsverfahren, sichere Konfiguration, Schutz, Monitoring, Backup, Schwachstellen und Änderungen | 0 von 9 bewertet |
Für jede Kontrollfrage werden in der VDA-ISA-Selbsteinschätzung tatsächliche Umsetzung, Scope, Referenzen, Nachweise, Reifegrad, Lücken und Maßnahmen dokumentiert.
Die neun Kontrollfragen sind Bestandteil der 46 Informationssicherheitsfragen und werden nicht individuell ausgeschlossen.
| Annex-A-Control | Behandlung in dieser Regelung | Aktueller Status |
|---|---|---|
| A.5.37 Dokumentierte Betriebsverfahren | Betriebs-, Übergabe-, Störungs- und Notfallverfahren | Geplant; Verfahren nicht vollständig vorgelegt |
| A.7.13 Instandhaltung von Betriebsmitteln | Autorisierung, Wartung, Begleitung und Abnahme | Geplant; Wartungsnachweise fehlen |
| A.8.1 Benutzerendgeräte | Betriebs-, Schutz-, Update- und Außerbetriebnahmegrundsätze | Geplant; Bestand und Umsetzung offen |
| A.8.6 Kapazitätssteuerung | Messgrößen, Schwellen, Trends und Maßnahmen | Geplant; keine belastbare Messung |
| A.8.7 Schutz vor Schadsoftware | Mehrschichtiger Schutz, Überwachung und Reaktion | Geplant; Abdeckung nicht bestätigt |
| A.8.9 Konfigurationsmanagement | Baselines, Soll-/Ist-Abgleich und Abweichungen | Geplant; Baselines nicht freigegeben |
| A.8.19 Softwareinstallation | Quellen, Freigabe, Rechte, Tests und Nachweise | Geplant; Verfahren nicht geprüft |
| A.8.32 Änderungssteuerung | Antrag, Risiko, Test, Freigabe, Rückfall und Review | Geplant; keine Changes nachgewiesen |
Die Anwendbarkeit und Umsetzung der ISO-Maßnahmen wird in der Statement of Applicability freigegeben. Diese Regelung ersetzt keine SoA-Entscheidung.
| Steuerungsobjekt | Nachweisbarer Stand |
|---|---|
| Service- und Betriebsregister | Nicht vollständig vorgelegt |
| Betriebsrollen und Vertretungen | Nicht vollständig bestätigt |
| Dokumentierte Betriebsverfahren | Nicht vollständig vorgelegt |
| Betriebsübergaben | Nicht nachgewiesen |
| Sichere Konfigurationsbaselines | Nicht vollständig freigegeben |
| Soll-/Ist-Konfigurationsprüfung | Nicht durchgeführt |
| Kapazitäts- und Leistungsschwellen | Nicht bestätigt |
| Schadsoftware-Schutzabdeckung | Nicht erhoben |
| Autorisierte Softwareinstallation | Nicht geprüft |
| Monitoring und Alarmwege | Nicht vollständig bestätigt |
| Backup- und Recoverytests | Nicht vollständig nachgewiesen |
| Change-Register und Klassifizierung | Nicht vorgelegt |
| Normale Changes mit vollständigem Nachweis | 0 erfasst |
| Notfalländerungen mit Nachprüfung | 0 erfasst |
| Rückfall- und Post-Implementation-Reviews | Nicht nachgewiesen |
| TISAX-Kapitel 5.2 | 0 von 9 Kontrollfragen bewertet |
Bewertung: Die Regelungsstruktur ist vorhanden. Eine Aussage zur tatsächlichen Betriebsstabilität, Änderungskontrolle, ISO-Konformität oder TISAX-Reife ist nicht zulässig.
Mindestens erforderlich sind:
Technische Detailnachweise werden geschützt abgelegt und im Wiki nur eindeutig referenziert.
| Kontrolle | Prüfgegenstand | Entwurfsturnus | Nachweisstatus |
|---|---|---|---|
| Betriebsverfahrensreview | Vollständigkeit, Aktualität, Rollen und Fehlerfälle | Mindestens jährlich/anlassbezogen | Nicht durchgeführt |
| Baselineprüfung | Soll-/Ist-Konfiguration kritischer Systeme | Noch festzulegen | Nicht durchgeführt |
| Kapazitätsreview | Schwellen, Trends, Engpässe und Maßnahmen | Regelmäßig | Nicht nachgewiesen |
| Malware-Schutzabdeckung | Systeme, Status, Alarme und Ausnahmen | Regelmäßig | Nicht erhoben |
| Softwareinstallationsstichprobe | Quelle, Freigabe, Rechte und Ergebnis | Regelmäßig | Nicht durchgeführt |
| Change-Stichprobe | Antrag, Risiko, Test, Freigabe, Rückfall und Abschluss | Regelmäßig | Nicht durchgeführt |
| Notfallchange-Review | Nachbearbeitung, Test, Risiko und Rückbau | Für jeden Fall | Keine Fälle erfasst |
| Wartungsstichprobe | Autorisierung, Fremdzugriff, Änderung und Abnahme | Regelmäßig | Nicht durchgeführt |
| Recoverytest | Wiederherstellung, Abhängigkeiten und Betrieb | Nach BCM-Testplan | Nicht vollständig nachgewiesen |
| Betriebsübergabetest | Vollständigkeit vor Produktivbetrieb | Für jede wesentliche Einführung | Nicht durchgeführt |
Entwurfsturnusse werden vor Freigabe risikobasiert bestätigt.
| Kennzahl | Berechnung | Entwurfsziel | Aktueller Stand |
|---|---|---|---|
| Aktuelle Betriebsverfahren | Fristgerecht geprüfte / erforderliche Verfahren | 100 % | Nicht messbar |
| Baselinekonforme Systeme | Konforme / geprüfte Systeme | 100 % oder freigegebene Ausnahme | Nicht erhoben |
| Kapazitätsüberschreitungen | Ungeklärte Überschreitungen je Zeitraum | 0 kritisch ohne Maßnahme | Nicht erhoben |
| Schutzabdeckung | Geschützte / relevante Systeme | 100 % im bestätigten Scope | Nicht erhoben |
| Erfolgreiche Changes | Erfolgreiche / abgeschlossene Changes | Zielwert vor Freigabe festlegen | Nicht messbar |
| Fehlgeschlagene Changes | Fehlgeschlagene / abgeschlossene Changes | Trend sinkend | Nicht messbar |
| Changes mit vollständigem Rückfallplan | Vollständige / rückfallpflichtige Changes | 100 % | Nicht messbar |
| Notfallchanges mit fristgerechtem Review | Geprüfte / Notfallchanges | 100 % | Keine Fälle erfasst |
| Unautorisierte Änderungen | Bestätigte Fälle | 0 | Nicht erhoben |
| TISAX-Kontrollfragen 5.2 | Bewertete / 9 | 9 von 9 | 0 von 9 |
Kennzahlen dürfen kritische fehlgeschlagene Changes, unautorisierte Änderungen oder unbekannte Grundgesamtheiten nicht durch Durchschnittswerte verdecken.
Geeignete Wirksamkeitsnachweise sind beispielsweise:
Ein Ticketstatus oder eine Checkliste ohne technische und fachliche Ergebnisprüfung genügt nicht.
Feststellungen werden über Abweichungen und Korrekturmaßnahmen behandelt.
IT-Betrieb und technische Sicherheit werden im Auditprogramm als hoch priorisiertes Auditfeld geführt.
Mögliche Stichproben über Interne Audits:
Ein positives Auditergebnis gilt nur für Scope und Stichprobe.
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| Services, Systeme und Betriebsverantwortungen vollständig erfassen | IT / OT / Service Owner | Offen |
| Kritische Betriebsverfahren erstellen und freigeben | IT-/OT-Betrieb | Offen |
| Betriebsübergabe- und Abnahmekriterien operationalisieren | IT / Entwicklung / Fachbereiche | Offen |
| Sichere Konfigurationsbaselines erstellen | IT-Sicherheit / System-Owner | Offen |
| Soll-/Ist-Konfigurationsprüfung einführen | IT-Betrieb / ISMS | Offen |
| Kapazitätsmetriken, Schwellen und Eskalationen festlegen | Service Owner / IT-Betrieb | Offen |
| Schadsoftware-Schutzabdeckung erheben | IT-Sicherheit | Offen |
| Softwareinstallations- und Administrationswerkzeuge steuern | IT-Leitung | Offen |
| Change-Kategorien und Genehmigungsmatrix freigeben | IT-Leitung / Fachbereiche | Offen |
| Change-Register und Kalender einrichten | Change-Koordination | Offen |
| Test-, Rückfall- und Abschlussvorlagen operationalisieren | IT / Entwicklung / BCM | Offen |
| Notfallchange-Verfahren testen | IT / Incident / BCM | Offen |
| Lieferanten- und OT-Changes integrieren | Einkauf / Produktion / IT | Offen |
| TISAX-Kapitel 5.2 kontrollfragenbezogen bewerten | TISAX / IT-Betrieb | Offen |
| Prüffrage | Status Entwurf |
|---|---|
| Sind Services, Assets, Owner und Abhängigkeiten vollständig? | Nein |
| Sind kritische Betriebsverfahren freigegeben und nutzbar? | Nicht nachgewiesen |
| Sind sichere Konfigurationsbaselines vorhanden? | Nicht vollständig |
| Werden Soll-/Ist-Abweichungen erkannt und behandelt? | Nicht nachgewiesen |
| Sind Kapazität, Malware-Schutz und Betriebszustände überwacht? | Nicht vollständig bestätigt |
| Ist Softwareinstallation angemessen beschränkt? | Nicht geprüft |
| Sind Logging, Backup, Netzwerk und Schwachstellenprozesse angebunden? | Teilweise als Entwurf |
| Sind Change-Arten und Freigaben operationalisiert? | Nein |
| Enthalten Changes Risiko, Test, Rückfall und Abschluss? | Keine Stichprobe vorhanden |
| Werden Notfalländerungen nachgeprüft und zurückgebaut? | Nicht getestet |
| Sind Lieferanten- und OT-Änderungen einbezogen? | Nicht nachgewiesen |
| Sind alle neun Kontrollfragen aus Kapitel 5.2 bewertet? | Nein; 0 von 9 |
| Sind die zugehörigen 46 Informationssicherheitsfragen vollständig 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 IT-/OT-Betrieb, Konfiguration, Kapazität, Schadsoftwareschutz, Changes, Rückfall und Nachweise 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/BCM/Datenschutz | – | Sicherheits- und Notfallprüfung ausstehend | – |
Maßgeblich bleiben die lizenzierten Normtexte, die offizielle ISA-Arbeitsmappe, der bestätigte Assessment Scope sowie die freigegebenen Rechts-, Vertrags-, Kunden-, Betriebs- und Sicherheitsanforderungen.