msolarczekandClaude Opus 4.8
b7d5df41d4
WP2.2 — Rendering-Doppelartikel (Variante B, Report §6):
- Variablen-Defaults ohne führenden Artikel: TOOL_TICKET „Ticketsystem",
TOOL_NAME „ISMS-Tool", TOOL_IAM „Entra ID / Active Directory".
- Fließtext angepasst: „im/in {{VAR}}" rendert nun korrekt („im Ticketsystem");
„über {{TOOL_TICKET}}" → „über das {{TOOL_TICKET}}"; TOOL_IAM (Adjektiv) mit
korrekter Deklination ausgeschrieben („über das zentrale Verzeichnis (…)",
„im zentralen Verzeichnis (…)"). Doppeldeutige Orte „bzw. ISMS-Tool" bereits in WP1 aufgelöst.
- Wert-Migration (Prisma-Migration, idempotent): strippt den führenden Artikel aus
bestehenden, nicht angepassten Variablenwerten — auch für Bestandsmandanten/Deploy.
WP4 — Feinschliff:
- F16 (R06 2.1.4): „mobiles Arbeiten" konkret verortet (Regelung, hinterlegt im ISMS-Tool).
- F21 (VA-10): abgeschnittene RACI-Spaltentexte vervollständigt.
- F18: 13 SEHR-HOCH-Sätze in den -elev-Blöcken in {{#if FLAG_VERY_HIGH_PROTECTION}}
ausgelagert → bei AL2 kein „Bei sehr hohem Schutzbedarf …" mehr.
Verifiziert: _verify.py Render 0 / Mapping sauber; Render-Gegenprobe mit echten
Defaults ohne „im das …"; AL2/AL3-Flag-Gegenprobe rückstandsfrei (SEHR-HOCH nur bei AL3);
Browser: R08 rendert „im Ticketsystem" und „über das zentrale Verzeichnis (Entra ID / Active Directory)".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
302 lines
15 KiB
Markdown
302 lines
15 KiB
Markdown
# Richtlinie Incident-, Notfall- und Kontinuitätsrichtlinie
|
||
|
||
| Dokumenteninformation | Wert |
|
||
|-----------------------|------|
|
||
| Dokumententyp | Richtlinie |
|
||
| Geltungsbereich | {{ISMS_SCOPE}} |
|
||
| Organisation | {{ORG_NAME}} |
|
||
| Verantwortlich | {{ROLE_ISB}} |
|
||
| Freigabe durch | {{ROLE_MANAGEMENT}} |
|
||
| Version | {{DOC_VERSION}} |
|
||
| Datum | {{DOC_DATE}} |
|
||
| Status | {{DOC_STATUS}} |
|
||
|
||
|
||
## 1. Zweck
|
||
|
||
Diese Richtlinie regelt Meldung und Behandlung von Sicherheitsereignissen, Krisenmanagement sowie Notfall- und Kontinuitätsplanung. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
|
||
|
||
## 2. Geltungsbereich
|
||
|
||
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
|
||
|
||
## 3. Anforderungen und Umsetzung
|
||
|
||
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
|
||
|
||
### 3.1 Meldung von Sicherheitsereignissen (ISA 1.6.1)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 1.6.1-M1 -->
|
||
- **[MUSS]** Eine Definition für ein meldepflichtiges Sicherheitsereignis oder eine Beobachtung existiert und ist Beschäftigten und relevanten Stakeholdern bekannt.
|
||
<!-- REQ 1.6.1-M2 -->
|
||
- **[MUSS]** Angemessene, risikoorientierte Mechanismen zur Meldung von Sicherheitsereignissen sind definiert, umgesetzt und allen relevanten Meldenden bekannt.
|
||
<!-- REQ 1.6.1-M3 -->
|
||
- **[MUSS]** Angemessene Kanäle zur Kommunikation mit Meldenden existieren.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.1-S1 -->
|
||
- **[SOLL]** Eine gemeinsame Anlaufstelle für die Ereignismeldung existiert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.1-S2 -->
|
||
- **[SOLL]** Verschiedene Meldekanäle je nach wahrgenommener Schwere (Echtzeit für gravierende Ereignisse/Notfälle sowie asynchrone Mechanismen wie Tickets oder E-Mail) sind verfügbar.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.1-S3 -->
|
||
- **[SOLL]** Beschäftigte sind verpflichtet und geschult, relevante Ereignisse zu melden.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.1-S4 -->
|
||
- **[SOLL]** Sicherheitsereignisse können auch durch Externe gemeldet werden; die einschlägigen Aspekte werden berücksichtigt.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.1-S5 -->
|
||
- **[SOLL]** Der Mechanismus und die Information, wie Vorfälle gemeldet werden, sind für alle relevanten Meldenden zugänglich.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.1-S6 -->
|
||
- **[SOLL]** Ein Rückmeldeverfahren an die Meldenden ist etabliert.
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.1-V1 -->
|
||
- **[SEHR HOCH]** Tests und Übungen der Ereignis- und Beobachtungsmeldung werden regelmäßig durchgeführt. (C, I, A)
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 1.6.1 -->
|
||
Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool, E-Mail an {{ROLE_ISB}}, für gravierende Fälle Echtzeitkanal) stehen allen Beschäftigten und Externen zur Verfügung; der Meldeweg ist über Onboarding/Awareness (BL-HR-01) bekannt, ein Rückmeldeverfahren ist etabliert (siehe {{LINK:VA-01}}).
|
||
|
||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||
<!-- IMPL 1.6.1-elev -->
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelmäßig durchgeführt.{{/if}}
|
||
{{/if}}
|
||
|
||
### 3.2 Behandlung von Sicherheitsereignissen (ISA 1.6.2)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 1.6.2-M1 -->
|
||
- **[MUSS]** Gemeldete Ereignisse werden ohne unangemessene Verzögerung bearbeitet.
|
||
<!-- REQ 1.6.2-M2 -->
|
||
- **[MUSS]** Eine angemessene Reaktion auf gemeldete Sicherheitsereignisse ist sichergestellt.
|
||
<!-- REQ 1.6.2-M3 -->
|
||
- **[MUSS]** Lessons Learned fließen in die kontinuierliche Verbesserung ein.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.2-S1 -->
|
||
- **[SOLL]** Gemeldete Ereignisse werden bei der Bearbeitung kategorisiert (z. B. Personal, physisch, Cyber), qualifiziert (z. B. nicht sicherheitsrelevant, Beobachtung, Verbesserungsvorschlag, Schwachstelle, Vorfall) und priorisiert (z. B. gering, mittel, schwer, kritisch).
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.2-S2 -->
|
||
- **[SOLL]** Verantwortlichkeiten für die Behandlung von Ereignissen je Kategorie sind definiert und zugewiesen.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.2-S3 -->
|
||
- **[SOLL]** Eine Strategie zur Meldung potenziell strafrechtlich relevanter Aspekte an zuständige Behörden, sofern erforderlich, existiert. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.2-H1 -->
|
||
- **[HOCH]** Maximale Reaktionszeiten je Klasse, Kategorie und Schwere sind definiert. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.2-H2 -->
|
||
- **[HOCH]** Nicht prioritätsgerecht bearbeitete Ereignisse werden eskaliert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.2-H3 -->
|
||
- **[HOCH]** Gesetzliche, regulatorische und vertragliche Meldepflichten sowie zugehörige Kontaktinformationen sind bekannt. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.2-H4 -->
|
||
- **[HOCH]** Eine Kommunikationsstrategie für sicherheitsrelevante Ereignisse existiert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.2-H5 -->
|
||
- **[HOCH]** Verfahren zur Reaktion auf Sicherheitsvorfälle bei Lieferanten sind etabliert; die einschlägigen Aspekte werden berücksichtigt. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.2-V1 -->
|
||
- **[SEHR HOCH]** Die Behandlung von Ereignissen unterschiedlicher Kategorien und Prioritäten wird regelmäßig getestet; die einschlägigen Aspekte werden berücksichtigt. (A)
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 1.6.2 -->
|
||
Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren (siehe {{LINK:VA-01}}) im {{TOOL_TICKET}} kategorisiert, qualifiziert, priorisiert, behandelt und dokumentiert; Verantwortlichkeiten und Eskalationswege sind zugewiesen ({{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt um). Lessons Learned fließen in die Verbesserung ein; eine Strategie zur Behörden-/Strafverfolgungsmeldung besteht.
|
||
|
||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||
<!-- IMPL 1.6.2-elev -->
|
||
Bei hohem Schutzbedarf sind maximale Reaktionszeiten je Schwere definiert, Eskalationen für nicht prioritätsgerecht bearbeitete Ereignisse geregelt, Meldepflichten und Kontakte bekannt, eine Kommunikationsstrategie sowie ein Verfahren für Lieferantenvorfälle etabliert. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf wird die Ereignisbehandlung regelmäßig getestet.{{/if}}
|
||
{{/if}}
|
||
|
||
### 3.3 Krisenmanagement (ISA 1.6.3)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 1.6.3-M1 -->
|
||
- **[MUSS]** Ein angemessener Plan zur Reaktion auf und Bewältigung von Krisensituationen existiert und die erforderlichen Ressourcen sind verfügbar.
|
||
<!-- REQ 1.6.3-M2 -->
|
||
- **[MUSS]** Verantwortlichkeiten und Befugnisse für das Krisenmanagement sind definiert, dokumentiert und zugewiesen.
|
||
<!-- REQ 1.6.3-M3 -->
|
||
- **[MUSS]** Die verantwortlichen Beschäftigten sind definiert und für ihre Aufgabe qualifiziert.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.3-S1 -->
|
||
- **[SOLL]** Methoden zur Erkennung von Krisensituationen sind etabliert; allgemeine Anzeichen und spezifische vorhersehbare Krisen sind identifiziert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.3-S2 -->
|
||
- **[SOLL]** Ein Verfahren zur Auslösung und/oder Eskalation des Krisenmanagements ist vorhanden.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.3-S3 -->
|
||
- **[SOLL]** Strategische Ziele und ihre Priorität in Krisensituationen sind definiert und relevantem Personal bekannt.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.3-S4 -->
|
||
- **[SOLL]** Ein Krisenstab ist definiert und genehmigt.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.3-S5 -->
|
||
- **[SOLL]** Krisenrichtlinien und -verfahren sind definiert und genehmigt.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 1.6.3-S6 -->
|
||
- **[SOLL]** Die Krisenplanung wird regelmäßig überprüft und aktualisiert.
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.3-H1 -->
|
||
- **[HOCH]** Relevante unterschiedliche potenzielle Krisenszenarien sind identifiziert.
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.3-H2 -->
|
||
- **[HOCH]** Notwendige Ressourcen und Informationen zur Krisenbewältigung (z. B. Kommunikationsinfrastruktur, Verfügbarkeit von Kontakt- und Risikoinformationen) sind identifiziert; angemessene Maßnahmen zur Sicherstellung der Verfügbarkeit bzw. Ausfallplanung sind vorhanden. (A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.3-H3 -->
|
||
- **[HOCH]** Eine Kommunikationsstrategie für Krisensituationen existiert. (A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.3-H4 -->
|
||
- **[HOCH]** Effizienz, Durchführbarkeit und Angemessenheit der Krisenplanung werden regelmäßig bewertet. (A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.3-H5 -->
|
||
- **[HOCH]** Stichprobenbasierte Tests der Krisenplanung werden durchgeführt (z. B. Simulation, Tabletop-Übungen mit Schlüsselpersonal). (A)
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 1.6.3-V1 -->
|
||
- **[SEHR HOCH]** Krisenübungen und Simulationen unter Einbindung aller relevanten Personen, einschließlich Entscheidungsträger, werden regelmäßig durchgeführt. (A)
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 1.6.3 -->
|
||
Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert (Auslösung/Wiederanlauf siehe {{LINK:VA-02}}); erforderliche Ressourcen sind verfügbar, Verantwortliche qualifiziert. Erkennungsmethoden bestehen, die Krisenplanung wird regelmäßig überprüft und aktualisiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.
|
||
|
||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||
<!-- IMPL 1.6.3-elev -->
|
||
Bei hohem Schutzbedarf sind relevante Krisenszenarien identifiziert, notwendige Ressourcen/Informationen und eine Kommunikationsstrategie sichergestellt, die Planung wird regelmäßig bewertet und stichprobenartig getestet (Tabletop). {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden regelmäßig Krisenübungen mit allen relevanten Personen inkl. Entscheidungsträgern durchgeführt.{{/if}}
|
||
{{/if}}
|
||
|
||
### 3.4 Kontinuitätsplanung für IT-Dienste (ISA 5.2.8)
|
||
|
||
**Anforderung**
|
||
|
||
<!-- REQ 5.2.8-M1 -->
|
||
- **[MUSS]** Kritische IT-Dienste sind identifiziert und die Geschäftsauswirkung wird berücksichtigt.
|
||
<!-- REQ 5.2.8-M2 -->
|
||
- **[MUSS]** Anforderungen und Verantwortlichkeiten für Kontinuität und Wiederherstellung dieser IT-Dienste sind relevanten Stakeholdern bekannt und erfüllt.
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 5.2.8-S1 -->
|
||
- **[SOLL]** Kritische IT-Systeme sind identifiziert; dabei werden die einschlägigen Aspekte berücksichtigt.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 5.2.8-S2 -->
|
||
- **[SOLL]** Eine Kontinuitätsplanung existiert und wird regelmäßig überprüft und aktualisiert.
|
||
{{/if}}
|
||
{{#if FLAG_INCLUDE_SHOULD}}
|
||
<!-- REQ 5.2.8-S3 -->
|
||
- **[SOLL]** Die Kontinuitätsplanung umfasst mindestens (D)DoS-Angriffe, erfolgreiche Ransomware-Angriffe und andere Sabotage, Systemausfallszenarien sowie Naturkatastrophen, die kritische IT-Systeme betreffen.
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-H1 -->
|
||
- **[HOCH]** Die Kontinuitätsplanung enthält vordefinierte Zeitrahmen (Recovery Time Objective) für die Wiederaufnahme des Betriebs. (A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-H2 -->
|
||
- **[HOCH]** Angemessene SLAs mit externen Dienstleistern entsprechend der Kontinuitätsplanung bestehen. (A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-H3 -->
|
||
- **[HOCH]** Die Kontinuitätspläne umfassen die Koordination vertraglich vereinbarter Kommunikation mit Geschäftspartnern. (A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-H4 -->
|
||
- **[HOCH]** Die Kontinuitätsplanung wird regelmäßig getestet, inkl. vollständiger Wiederherstellung in einen bekannten Zustand und Einhaltung definierter Zielzeiten. (A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-H5 -->
|
||
- **[HOCH]** Eine Backup- und Wiederherstellungsstrategie für kritische IT-Dienste und Informationen ist definiert und umgesetzt. (C, I, A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-H6 -->
|
||
- **[HOCH]** Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugte Veränderung/Löschung durch Schadsoftware geschützt. (I, A)
|
||
{{/if}}
|
||
{{#if FLAG_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-H7 -->
|
||
- **[HOCH]** Backups kritischer IT-Dienste und Informationen sind ausreichend gegen unbefugten Zugriff durch Schadsoftware oder Betreiber geschützt. (C, I)
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-V1 -->
|
||
- **[SEHR HOCH]** Die Kontinuitätsplanung ist mit den Kontinuitätsplänen relevanter externer Dienstleister abgestimmt. (A)
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-V2 -->
|
||
- **[SEHR HOCH]** Die Fortführung wesentlicher Kern- und Geschäftsfunktionen mit minimalem oder keinem Verlust an Betriebskontinuität ist möglich; dabei werden die einschlägigen Aspekte berücksichtigt.
|
||
{{/if}}
|
||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||
<!-- REQ 5.2.8-V3 -->
|
||
- **[SEHR HOCH]** Die Kontinuitätsplanung wird regelmäßig getestet. Testszenarien, Ergebnisse und Lessons Learned werden aufgezeichnet. (I, A)
|
||
{{/if}}
|
||
|
||
**Umsetzung bei {{ORG_NAME}}**
|
||
|
||
<!-- IMPL 5.2.8 -->
|
||
Kritische IT-Dienste sind mit Geschäftsauswirkung identifiziert; Anforderungen und Verantwortlichkeiten für Kontinuität/Wiederherstellung sind bekannt und erfüllt. Eine Kontinuitätsplanung (inkl. (D)DoS, Ransomware, Ausfall, Naturkatastrophen) besteht, wird regelmäßig überprüft und über das IT-Notfallverfahren umgesetzt (siehe {{LINK:VA-02}}).
|
||
|
||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||
<!-- IMPL 5.2.8-elev -->
|
||
Bei hohem Schutzbedarf sind RTO/RPO, SLAs mit Dienstleistern, Partnerkommunikation, regelmäßige Volltests sowie eine geschützte Backup-/Recovery-Strategie (immutable/isoliert) etabliert. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf ist die Planung mit externen Dienstleistern abgestimmt, die Fortführung wesentlicher Funktionen sichergestellt und Tests inkl. Lessons Learned werden aufgezeichnet.{{/if}}
|
||
{{/if}}
|
||
|
||
## 4. Verbindlichkeit
|
||
|
||
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_ISB}} überwacht.
|
||
|
||
## 5. Rollen und Verantwortlichkeiten
|
||
|
||
| Rolle | Verantwortung in dieser Richtlinie |
|
||
|-------|-------------------------------------|
|
||
| {{ROLE_ISB}} | Vorfallskoordination |
|
||
| {{ROLE_IT_LEAD}} | Notfall-/Wiederanlaufplanung |
|
||
| {{ROLE_MANAGEMENT}} | Krisenstab |
|
||
|
||
## 6. Überprüfung und Aktualisierung
|
||
|
||
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_ISB}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
|
||
|
||
## 7. Nachweise
|
||
|
||
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
|
||
|
||
## 8. Verwandte Dokumente
|
||
|
||
- Zugehörige Verfahren: {{LINK:VA-01}}, {{LINK:VA-02}}
|
||
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
|
||
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
|
||
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
|
||
- Weitere: {{LINK:R03}}, {{LINK:R10}}
|
||
|
||
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
|