Richtlinien-Update: 316 Anforderungen/45 Controls + Schutzbedarf-/TISAX-Schalter
Delta-Update des VDA-ISA-2027-Vorlagenpakets eingepflegt: - Aktualisiertes Seed-Paket (ersetzt bisherigen Stand): 316 Anforderungen (122 MUSS · 132 SOLL · 43 HOCH · 19 SEHR HOCH) über 45 Controls; VA-01/VA-05 jetzt enthalten (13 Verfahren vollständig). Beschädigte RACI-Tokens (VA-05/08/09/ 10/12/13) repariert. Importer: Umsetzungstext aus den .md-IMPL-Ankern extrahiert (mapping.json führt ihn nicht mehr), neue Obligation-Typen HOCH/SEHR HOCH. - Neue Schutzbedarf-Flags (variables.schema): FLAG_HIGH_PROTECTION, FLAG_VERY_HIGH_PROTECTION, FLAG_ELEVATED_PROTECTION (abgeleitet). Render-Helper applyProtection: HIGH stets an, VERY_HIGH aus Global/Override, ELEVATED = HIGH||VH (nie manuell) — angewandt in Lese-, Bearbeiten-, Handbuch- und Coverage-Rendering. - TISAX-Level-Schalter (AL2/AL3) zentral auf der Bibliothek (setGlobalTisaxLevel); AL2 = MUSS/SOLL/HOCH, AL3 = zusätzlich SEHR HOCH. Override je Richtlinie im Bearbeitungsmodus (setProtectionOverride, Feld protection_override); effektiver Wert = Dokument-Override sonst global. - KPIs zeigen 316 Anforderungen mit Aufschlüsselung; Coverage/Badges für HOCH/SEHR HOCH; Control-Titel-Fallback. Verifiziert: Import 316/45; Rendering rückstandsfrei über AL2/AL3 × Flag-Kombis; Override R04→AL3 zeigt SEHR-HOCH-Inhalt, R02 (global AL2) nicht; global bleibt AL2. Architektur-Hinweis: applyProtection kapselt das Level→Flags-Mapping, sodass die globale Ebene später ohne Umbau zur TISAX-AL2/AL3-Auswahl wird (bereits so gebaut). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.8
+198
-53
@@ -14,7 +14,7 @@
|
||||
|
||||
## 1. Zweck
|
||||
|
||||
Diese Richtlinie regelt Meldung und Behandlung von Sicherheitsereignissen, das Krisenmanagement sowie die Notfall- und Kontinuitätsplanung für IT-Dienste. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
|
||||
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
|
||||
|
||||
@@ -22,106 +22,252 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
|
||||
|
||||
## 3. Anforderungen und Umsetzung
|
||||
|
||||
> Aufbau je Abschnitt: **Anforderung** (normativ, aus VDA ISA; [MUSS]/[SOLL]) und **Umsetzung bei {{ORG_NAME}}** (tatsächliche Ausgestaltung, anzupassen wo erforderlich).
|
||||
|
||||
### 3.1 Meldung von Ereignissen (ISA 1.6.1)
|
||||
> 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]** Sicherheitsrelevante Ereignisse und Beobachtungen können über einen definierten Meldeweg gemeldet werden.
|
||||
- **[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]** Der Meldeweg ist bekannt gemacht und niedrigschwellig erreichbar.
|
||||
- **[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]** Meldungen werden zentral erfasst und kategorisiert.
|
||||
- **[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-M1 -->
|
||||
Sicherheitsereignisse können über einen definierten Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool sowie per E-Mail an {{ROLE_ISB}}) gemeldet werden.
|
||||
<!-- IMPL 1.6.1-M2 -->
|
||||
Der Meldeweg ist allen Beschäftigten über Onboarding und Awareness (BL-HR-01) bekannt und niedrigschwellig, auch anonym, erreichbar.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- IMPL 1.6.1-S1 -->
|
||||
Meldungen werden zentral im ISMS-Tool erfasst, kategorisiert und einem Schweregrad zugeordnet.
|
||||
<!-- 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.
|
||||
|
||||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||||
<!-- IMPL 1.6.1-elev -->
|
||||
Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelmäßig durchgeführt.
|
||||
{{/if}}
|
||||
|
||||
### 3.2 Behandlung von Sicherheitsereignissen (ISA 1.6.2)
|
||||
|
||||
|
||||
**Anforderung**
|
||||
|
||||
<!-- REQ 1.6.2-M1 -->
|
||||
- **[MUSS]** Gemeldete Sicherheitsereignisse werden bewertet, priorisiert, behandelt und dokumentiert.
|
||||
- **[MUSS]** Gemeldete Ereignisse werden ohne unangemessene Verzögerung bearbeitet.
|
||||
<!-- REQ 1.6.2-M2 -->
|
||||
- **[MUSS]** Verantwortlichkeiten und Eskalationswege für die Vorfallsbehandlung sind definiert.
|
||||
- **[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]** Erkenntnisse aus Vorfällen werden ausgewertet (Lessons Learned) und führen zu Verbesserungen.
|
||||
- **[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]** Meldepflichten (z. B. an Kunden/OEM, Behörden) sind berücksichtigt.
|
||||
- **[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-M1 -->
|
||||
Ereignisse werden nach einem definierten Incident-Verfahren bewertet, priorisiert, eingedämmt, behoben und dokumentiert; die Bearbeitung erfolgt im {{TOOL_TICKET}}.
|
||||
<!-- IMPL 1.6.2-M2 -->
|
||||
Verantwortlichkeiten und Eskalationsstufen sind definiert; {{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt technische Maßnahmen um.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- IMPL 1.6.2-S1 -->
|
||||
Nach relevanten Vorfällen erfolgt eine Nachbereitung (Lessons Learned) mit Ableitung und Nachverfolgung von Verbesserungsmaßnahmen.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- IMPL 1.6.2-S2 -->
|
||||
Vertragliche und gesetzliche Meldepflichten (Kunden/OEM, Aufsichtsbehörden, bei personenbezogenen Daten binnen 72 Stunden) sind im Verfahren berücksichtigt.
|
||||
<!-- IMPL 1.6.2 -->
|
||||
Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren 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. Bei sehr hohem Schutzbedarf wird die Ereignisbehandlung regelmäßig getestet.
|
||||
{{/if}}
|
||||
|
||||
### 3.3 Krisenmanagement (ISA 1.6.3)
|
||||
|
||||
|
||||
**Anforderung**
|
||||
|
||||
<!-- REQ 1.6.3-M1 -->
|
||||
- **[MUSS]** Die Organisation ist auf die Bewältigung von Krisensituationen vorbereitet (Rollen, Kommunikation, Entscheidungswege).
|
||||
- **[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]** Krisen-/Notfallpläne werden regelmäßig geübt und aktualisiert.
|
||||
- **[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-M1 -->
|
||||
Ein Krisenmanagement mit Krisenstab, Rollen, Kommunikations- und Entscheidungswegen ist definiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- IMPL 1.6.3-S1 -->
|
||||
Krisen- und Notfallpläne werden mindestens {{REVIEW_CYCLE}} geübt (z. B. Tabletop-Übung) und aktualisiert.
|
||||
<!-- IMPL 1.6.3 -->
|
||||
Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert; 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). Bei sehr hohem Schutzbedarf werden regelmäßig Krisenübungen mit allen relevanten Personen inkl. Entscheidungsträgern durchgeführt.
|
||||
{{/if}}
|
||||
|
||||
### 3.4 Kontinuitätsplanung IT (ISA 5.2.8)
|
||||
|
||||
### 3.4 Kontinuitätsplanung für IT-Dienste (ISA 5.2.8)
|
||||
|
||||
**Anforderung**
|
||||
|
||||
<!-- REQ 5.2.8-M1 -->
|
||||
- **[MUSS]** Für kritische IT-Dienste besteht eine Kontinuitätsplanung (Wiederanlaufziele, Verantwortliche, Maßnahmen).
|
||||
- **[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]** Wiederanlaufmaßnahmen werden regelmäßig getestet; Ergebnisse werden dokumentiert.
|
||||
- **[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-M1 -->
|
||||
Für kritische IT-Dienste bestehen Wiederanlaufziele (RTO/RPO), Verantwortliche und Maßnahmen; {{ROLE_IT_LEAD}} verantwortet die Kontinuitätsplanung.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- IMPL 5.2.8-S1 -->
|
||||
Wiederanlaufmaßnahmen werden mindestens {{BACKUP_TEST_FREQ}} getestet (BL-OPS-06); Ergebnisse werden dokumentiert.
|
||||
<!-- 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. 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}}
|
||||
|
||||
## 4. Verbindlichkeit
|
||||
@@ -132,9 +278,9 @@ Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich
|
||||
|
||||
| Rolle | Verantwortung in dieser Richtlinie |
|
||||
|-------|-------------------------------------|
|
||||
| {{ROLE_ISB}} | Koordination der Vorfallsbehandlung |
|
||||
| {{ROLE_IT_LEAD}} | IT-Notfall- und Wiederanlaufplanung |
|
||||
| {{ROLE_MANAGEMENT}} | Einberufung Krisenstab |
|
||||
| {{ROLE_ISB}} | Vorfallskoordination |
|
||||
| {{ROLE_IT_LEAD}} | Notfall-/Wiederanlaufplanung |
|
||||
| {{ROLE_MANAGEMENT}} | Krisenstab |
|
||||
|
||||
## 6. Überprüfung und Aktualisierung
|
||||
|
||||
@@ -142,15 +288,14 @@ Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{RO
|
||||
|
||||
## 7. Nachweise
|
||||
|
||||
Die Nachweise zur Umsetzung dieser Richtlinie 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}}).
|
||||
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
|
||||
|
||||
- Informationssicherheitsleitlinie: {{LINK:L00}}
|
||||
- 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}}
|
||||
|
||||
<!-- Das Mapping der Anforderungen (REQ/IMPL) zu VDA-ISA-Controls ist in mapping.json hinterlegt und wird vom Tool über die Hidden-Anker aufgelöst. Im Lesemodus nicht sichtbar. -->
|
||||
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
|
||||
|
||||
Reference in New Issue
Block a user